[mythtv-users] Time Warner Junking STB's

[Dean Collins]

Thanks Simon, some of this I knew, some of this I didn't but ALL was appreciated.

I'm curious how does port mirroring work - I'm assuming from the name (and googling) I can tell the switch that anything that goes to port 12.....also send to port 20 which I have wireshark setup on.

So basically what I can do is anytime I put a new piece of equipment on the network fire up wireshark and watch it for an hour to make sure its not doing something it shouldn't. Is that close enough?


So the question is what sort of switches do this? High end cisco only or can consumer home switches do this as well?

 
Cheers,
Dean
 

-----Original Message-----
From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-bounces at mythtv.org] On Behalf Of Simon Hobson
Sent: Monday, November 25, 2013 9:33 AM
To: Discussion about MythTV
Subject: Re: [mythtv-users] Time Warner Junking STB's

Dean Collins wrote:
> Mike, care to take 5 mins to explain how you do it? What kind of switch btw? What software?

> Appreciate its OT but I think more than a few people might be interested if you can document a 10 step overview etc.

I'll jump in as it's something I do this quite often in the day job.

First, a quite ouline of what & why.

"Packet Sniffing" is a generic term for various techniques where you capture network traffic off the cable and analyse it - looking for problems, looking at what traffic there is, diagnosing known issues, and so on.
So you have a problem wher "A" can't connect to a service on "B". By sniffing packets at various points (as well as monitoring logs), you should be able to determine where the problem lies : Do the packets make it out of device A ? Do they arrive at B ? Does B reply at all ? Do the reply packets make it out of B ? Do they arrive at A ?

There are three parts involved : 1) getting access to the packets, and 2) capturing them, and 3) display the packets for the user.


1) Getting access to the packets

In "the old days" it was simple - your network was either a long bit of coax or you had one of those new fangled hubs (aka multiport repeater). Sniffing was simple as all traffic was visible everywhere - and I still keep an old hub around just for this. Just unplug the device, put the hub between it and it's switch port, and then you can see all the traffic (both ways) by plugging into any other port on the hub - but note that this does change the network, eg by changing the connection from a full duplex 1Gbps link to a half duplex 100Mbps link, which could potentially have an effect on network operations.
As a variation on this, if you have a system with two NICs, you can bridge them and put your system inline with the device you are monitoring. You can then sniff packets on either NIC (what goes in on one should come out of the other).

Then came switches. Apart from broadcast and multicast traffic, the only traffic you will see one a port is traffic addressed to your MAC - everything else just doesn't show up. With a basic unmanaged switch, this is not fixable - so in a typical home or small business network with basic switches you cannot sniff traffic this way - hence why I keep an old hub around !
With managed switches, there is usually a facility to mirror traffic on one port to another port. Capabilities vary, but as a minimum is should allow you to copy all traffic to/from one port (the monitored port) to the monitoring port. You can now plug yourself into this monitoring port and see all the traffic on the monitored port.

Another method I haven't used myself is to physically tap the cable - basically splitting one pair out and connecting it to the receive pair of your NIC. This will only get you one side of the traffic, and it won't work on interfaces (eg 1000baseT) which use more than one pair.

And lastly, if one of the items of equipment in the path taken by the packets is something you have full control over (eg a GNU/Linux box acting as a router/firewall) then you can directly sniff traffic going through it without any hardware help. This is particularly easy to use as it needs no special hardware or setup. One thing to be aware of is that your packet sniffer will get to see packets coming off the wire *before* iptables gets to filter or mangle them - thus you may see the packet arrive, but that doesn't mean the service gets them. For outbound traffic, you'll see the packets after iptables has finished with them.


2) Capturing the packets
For this you need a sniffer. There are several, my personal preferred choice is Wireshark (or more normally as I usually work on headless machines, the text only Tshark), another that comes to mind is Pcap.
With tshark, you can apply capture filters and either dump the packets to a file for later analysis, or display them in real time (either as a 1 line summary, or a verbose decode). Eg, you could specify "host 192.168.1.123 and host 192.168.1.1 and port 80" to limit the capture to only port 80 (HTTP) traffic between those two machines. "port 67 or port 68" will get you DHCP traffic. "not ether host aa:bb:cc:dd:ee:ff" will exclude traffic from a specific device - I use this to avoid getting traffic from my own laptop (you shoudl see how chatty OS X is !) if the filters I'm using won't exclude it anyway.

AIUI not all network cards are capable of this as it needs them to support promiscuous mode - though I've not met this limitation myself (including capturing from a VM hosted under Xen - most of my systems are virtual now).

And for completeness, there are hardware devices with such capabilities. I believe some of the higher end Fluke network testing kit can do this, but I'm not likely to ever have access to such stuff !


3) Displaying the results
With Wireshark, you can display the results as you capture packets, or you can load a file you captured separately - so it's possible to capture packets from a remote system, copy the file to your local machine, and then analyse them. Wireshark is much more useful (in some respects) than Tshark as you can select which parts of packets to display, sort them, select conversations (ie related packets from one connection) and so on.



Something that's related is if you want to do accounting - ie see how much traffic there is and what sort. Do sniffing/packet capture will give you a snapshot, but for long term monitoring you need different tools. If you get the traffic to go through your device (it doesn't work if you "stand to one side" and look at what goes past as is the case when using a hub or switch with port mirroring) then you can apply iptables filters and simply read the packet and/or byte counters from iptables. Add some storage and graphing (RRD Tool is good for this) and you can get pretty graphs that even managers can understand :) _______________________________________________
mythtv-users mailing list
mythtv-users at mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users