Ethernet monitor - What is needed to do it?

[highwire]

I am curious how this might be done, so I thought I'd ask...

I would like to passively monitor traffic between a device and my router or modem.

Could I somehow use a computer and a couple of extra NICs (in and out) to bridge? This computer could be running Ethereal/Wireshark or some such, and record anomalies, etc.

Or, maybe somehow using a switch or hub in a similar way? Or is it only possible with special hardware?

I'm sure this has to be a somewhat basic operation for testing/troubleshooting equipment. I need a clue, some links, maybe a short tutoring on the subject.

thx

 

[sonoma1993]

you could use some kind of network system management software to monitor the traffic and more. Look up like solorwinds, zenoss, python or any other nms software. As long your devices support snmp or have a proxy( for devices that don't support snmp).

 

[nweaver]

Originally posted by: sonoma1993
you could use some kind of network system management software to monitor the traffic and more. Look up like solorwinds, zenoss, python or any other nms software. As long your devices support snmp or have a proxy( for devices that don't support snmp).

I don't think that is what he was looking for...he is looking to passively sniff packets the device is sending out.

OP, there are 3 options. I'll list them in order of ease/expense.

1. Go old school, get yourself a hub and jack the device, an uplink to the network, and the sniffer.

2. Managed switch with port mon enabled: better option, but if you don't happen to have a managed switch, it's a bit more of an expense. This is what I normally do myself.

3. Network tap: Can be spendy, and not really worth it imho, but you could do it...



also, as a suggestion, you didn't mention OS, but if you are using *nix (better captures imho) then don't run wireshark live, use tcpdump from the cli to dump the packets to disk, and then do offline analysis. Realize that wireshark is a very insecure app, so be carefull if you don't trust the network or trust the device. Wireshark can crash in an instant, and then you loose your trace if you are doing it live. Also, use a pc with LOTS of memory to do analysis, if you are getting a decent sized sniff. I won't do analysis with less then 2GB of memory, because it takes too long to apply filters and parse packets and such. Also always make sure you are using the most recent stable version of wireshark, and DON'T use ethereal.

 

[futuristicmonkey]

Originally posted by: nweaver
DON'T use ethereal.

Why not?

 

[highwire]

Originally posted by: futuristicmonkey

Originally posted by: nweaver
DON'T use ethereal.

Why not?

Ethereal=Wireshark.
The name Ethereal was changed to Wireshark last year because of infringment issues. If the sniffer is called Ethereal, it means it is an old version. That is what I get from their website and others.

Originally posted by: nweaver

Originally posted by: sonoma1993
you could use some kind of network system management software to monitor the traffic and more. Look up like solorwinds, zenoss, python or any other nms software. As long your devices support snmp or have a proxy( for devices that don't support snmp).

I don't think that is what he was looking for...he is looking to passively sniff packets the device is sending out.

OP, there are 3 options. I'll list them in order of ease/expense.

1. Go old school, get yourself a hub and jack the device, an uplink to the network, and the sniffer.
2. Managed switch with port mon enabled: better option, but if you don't happen to have a managed switch, it's a bit more of an expense. This is what I normally do myself.

3. Network tap: Can be spendy, and not really worth it imho, but you could do it...

also, as a suggestion, you didn't mention OS, but if you are using *nix (better captures imho) then don't run wireshark live, use tcpdump from the cli to dump the packets to disk, and then do offline analysis. Realize that wireshark is a very insecure app, so be carefull if you don't trust the network or trust the device. Wireshark can crash in an instant, and then you loose your trace if you are doing it live. Also, use a pc with LOTS of memory to do analysis, if you are getting a decent sized sniff. I won't do analysis with less then 2GB of memory, because it takes too long to apply filters and parse packets and such. Also always make sure you are using the most recent stable version of wireshark, and DON'T use ethereal.

Thanks sonoma1993, but I am not a network guy. I want to look at traffic to/from my router or modem to an ethernet device on my bench. I do not want to interact with anything, just see what is going on without causing any change at all in the normal activity - passive. Sadly, all of that network jargon is over my head for now, maybe later I'll get into some of this stuff a little deeper.

nweaver Thanks for defining my options. If I had the hardware for (1.) or (2.) I would go that way. I located a diagram for a simple tap at http://www.snort.org/docs/tap/. Since I am a circuit design guy, I see right away what they are doing and how I can kluge-up a tap by twisting a couple of patch cables together. This is slow 10base traffic and short runs, so it should work. I will give it a try. The main disadvantage doing this over buying some box or other is that the traffic sources/directions are not combined.

What I will now have (thanks), is an monitored A to B cable tapped with two receive only cables going to extra NICs on my winBox. The box will have to run two instances of Wireshark to monitor or record both directions of traffic.

Since I have been learning more about this stuff, I found that sniffer programs like Wireshark can adjust the operation of a NIC to promiscuous mode. ( Sounds lewd, doesn't it?) This lets the nic receive ALL traffic on the pair, not just traffic that is addressed to it. This is the key thing that makes it work.
An improvement, other than buying a REAL hub$, forget a managed switch$$$, would be some additional piece of software that could route traffic unconditionally from one nic to the other in the computer and out, retaining original nic addresses. Besides making a cleaner hook-up, this would allow a single sniffer to pick up both directions of traffic to a single file or display. If this is not possible hardware-wise, and I suspect it is not, then what I have may be as good as can be had without buying an actual real (not switch) hub.

BTW, I like Wireshark. It is easy to get going, and interesting to watch it work. The following might be just a little over the top, but this app IS a neat thing. Here is a blurb from the Wireshark website:

May 2, 2007
eWEEK Labs has declared Wireshark one of The Most Important Open-Source Apps of All Time. According to eWEEK, we are one of "the applications that have moved open-source technologies from corporate curiosities to integral enterprise tools."

There are Apple and linux flavors, too.

 

[robmurphy]

You can run wireshark on XP Pro with 512M memory. I do this most of the time at work.

If you are doing long runs you can tell it to split the capture into multiple files. I use 10M. It does not crash, or at least it has not in 6 months, if you turn of the real time display. That way its just capturing. Wireshark puts the date and time in the filename so you can see which file to open if you know the time something happend. One slight problem is that wireshark does not add .pcap extension if you use multiple files.

If you keep the capture files to about 10M then they open on a PC with 512M memory fine. One thing to be aware of is that wireshark does leak memory like a seive. Every time you change the filters it uses more memory. If you have been playing with the filters its often simpler to exit wireshark and start it again. This releases the memory wireshark has lost.

There are html help files for wireshark and the other utilities it comes with in same directory as the executable file.

Have a look at the help files. You may find tshark of interest, its the command line version of wireshark.

Rob Murphy

 

[robmurphy]

I forgot to mention mergecap. Its part of the wireshark download so you should have it. Mergecap will allow you to merge the captures from the 2 NICs into 1 capture file so you can analyse both directions at once. This makes things much easier.

 

[nweaver]

Originally posted by: robmurphy
You can run wireshark on XP Pro with 512M memory. I do this most of the time at work.

If you are doing long runs you can tell it to split the capture into multiple files. I use 10M. It does not crash, or at least it has not in 6 months, if you turn of the real time display. That way its just capturing. Wireshark puts the date and time in the filename so you can see which file to open if you know the time something happend. One slight problem is that wireshark does not add .pcap extension if you use multiple files.

If you keep the capture files to about 10M then they open on a PC with 512M memory fine. One thing to be aware of is that wireshark does leak memory like a seive. Every time you change the filters it uses more memory. If you have been playing with the filters its often simpler to exit wireshark and start it again. This releases the memory wireshark has lost.

There are html help files for wireshark and the other utilities it comes with in same directory as the executable file.

Have a look at the help files. You may find tshark of interest, its the command line version of wireshark.

Rob Murphy

if you are using 10MB ring buffers, then you aren't capturing any huge amounts

I have run multiple sniffers, capturing a very busy network (7 discreet locations in one flat L2 network) for 23x7 for about 3 weeks. Our ring buffers were just under 2GB, and it was only 23 hours so we had an hour to turn them off and move the files to a central server. Mergecap a few of those files and you get a mess on your hands real quick. This project is what drove me to linux, as Ethereal (not wireshark yet) kept dropping packets. Running tcpdump is much more reliable. Capturing that many packets, it's easy to hit one that the parser pukes on and crashes the program.

 

[nweaver]

op, look around, it's not too hard to find a "Hub" (predessor to the swtich) and that works great to see all the traffic.

 

[RebateMonger]

Originally posted by: nweaver
op, look around, it's not too hard to find a "Hub" (predessor to the swtich..)

I've got some great hubs, speedy 10mbps, that I'll be glad to give away for a couple of hundred apiece. (Hey, they are collectors' items)

 

[highwire]

Originally posted by: RebateMonger

Originally posted by: nweaver
op, look around, it's not too hard to find a "Hub" (predessor to the swtich..)

I've got some great hubs, speedy 10mbps, that I'll be glad to give away for a couple of hundred apiece. (Hey, they are collectors' items)

RebateMonger, you are too late, sorry. Just got my own relic hub!

And nweaver, you are right. Just picked one up at BestBuy - yup, it is a real hub. I tested it against a switch I've had for awhile and unlike the switch, the BB unit will forward everything. I was going to do the simple tap I mentioned - basically 2 loads in parallel - lotsa mismatch that way, though. Then I thought I would refine it with some extra circuitry. I calculated resistive networks to keep things spec, pi and delta. Then I saw a cheap unit mentioned in the wireshark wiki and that made it the obvious answer to my sniffer interface problem. Thanks.

It is only 10base-t, but that is all I need for now. It's model DX-EHB4 for 20 bux. If anyone else needs to do any packet sniffing, this unit might be a good choice because most "hubs" sold now in the consumer realm are really switches - better for most apps - but useless for packet sniffing.

 

[robmurphy]

We are capturing from a mirror port on a CISCO 6500 series switch. I am not sure of the exact model. We are capturing arround 30 Gig in a weekend run.

This has been going on for months without any crashes. We are using wireshark, not ethereal. The important bit is as I said to turn off the display, then it just captures. I do not think it will parse the packets in this situation. The PC used is an old P4 ~2.9G and 512M memory. The only problem we have is diskspace, but using a compressed folder helps this by a factor of about 2.5, i.e. 2.5 Gig of capture takes up 1 Gig on disk. I set it to use 10 Meg files, and this means they can be read on a normal PC/laptop with 512M memory. One of the Laptops only had 256M and it would still work on that only slowly.

The ability to split the capture into multiple files without loosing any packets is a great advantage. I do not know if tcpdump can do that. Dumpcap which comes with wireshark allows the option of splitting the capture into multiple files. Again this is command line utility. I maybe could have used dumpcap instead of wireshark, or indeed tshark but the people who use this would then just start a wireshark session. The fact that they can see wireshark running, and a window showing its is capturing is enough of a "comfort" message for them to not do this.

Mergecap is great if you have been capturing of 2 streams with different protocols, or if you want to combine the transmit and receive halfs. Again I keep the capture files at about 10 meg, and at this size it works fine. This makes the analysis of problems with hardware and software much easier as you can see the message coming in one 1 stream, and the output, or lack of on the other stream.

Rob Murphy

 

[nweaver]

Originally posted by: robmurphy
We are capturing from a mirror port on a CISCO 6500 series switch. I am not sure of the exact model. We are capturing arround 30 Gig in a weekend run.

This has been going on for months without any crashes. We are using wireshark, not ethereal. The important bit is as I said to turn off the display, then it just captures. I do not think it will parse the packets in this situation. The PC used is an old P4 ~2.9G and 512M memory. The only problem we have is diskspace, but using a compressed folder helps this by a factor of about 2.5, i.e. 2.5 Gig of capture takes up 1 Gig on disk. I set it to use 10 Meg files, and this means they can be read on a normal PC/laptop with 512M memory. One of the Laptops only had 256M and it would still work on that only slowly.

The ability to split the capture into multiple files without loosing any packets is a great advantage. I do not know if tcpdump can do that. Dumpcap which comes with wireshark allows the option of splitting the capture into multiple files. Again this is command line utility. I maybe could have used dumpcap instead of wireshark, or indeed tshark but the people who use this would then just start a wireshark session. The fact that they can see wireshark running, and a window showing its is capturing is enough of a "comfort" message for them to not do this.

Mergecap is great if you have been capturing of 2 streams with different protocols, or if you want to combine the transmit and receive halfs. Again I keep the capture files at about 10 meg, and at this size it works fine. This makes the analysis of problems with hardware and software much easier as you can see the message coming in one 1 stream, and the output, or lack of on the other stream.

Rob Murphy

it sounds like the "don't display" would work well. I haven't used wireshark on windows in a while, and when I do, it's just normally a quick sniff for something simple. The problem I have with 10MB files is that when you have someone transfer a 2 gig ISO across the link, it gets huge. THe multipoint sniff I mentioned above were large MFP printers, and they were sending 200+ page PDF attachments via email, and so it would have sucked. Looking back though, I do remember using ethereal without capture mode on (so it didn't display the packets) and ring buffers, without crashes, so you are right. Either way, if it's going to be a large capture, don't display packets . You just helped all the windows users to figure out how.

 

[robmurphy]

Were are monitoring VoIP protocols, so were more concered about loosing packets as you can bet the lost one has the details for a call with an error.

We do not have to worry about large PDFs or ISO images so would not have the same problem. Just a case of using the tools available that suit the problem.

I have worked on a few VoIP projects now, and 1 thing is common:

You have to use what is available free and the machines that are there. As soon as you suggest a beter spec machine running Unix/Linux or XP it may be agreed, but it will never turn up, and the project will still expect to carry on.

If kit arrives its usualy after the project needs it, a bit like any training.

 

[spidey07]

If you want to look into industrial analysis look at Network Instruments. Full line rate, multiple gig ports, terabytes of storage. They're used to monitor and record data centers.

Fluke/Acterna make good voice analyzers. The techs love them.

 

[nweaver]

Solera networks has a few "professional" grade network sniffers, and have claims to stream network to disk at insane speeds (I don't know if it does, haven't used them). They are in the same building as me, thats why I know.

 

[robmurphy]

As said we could ask for them, but they would never arrive or at least not until after we needed them.

Its a common problem when working on a project. If you are not in the department responsible for the network, servers and laptops/PCs they are very slow to approve new kit, and agree to order it. Thats life and you just have to make the best of what you have available.

I have ended up using my own laptop on jobs that should have been done using the clients supplied laptop many times. A simple thing like a new hard disk because the present one has failed 3 times in 1 week and it takes 2 - 3 weeks to get a new hard disk (2.5" 40 - 120 MB, really difficult to find). Another cracker was the client supplied the desktop machines needed, but they did not have the accounts and password to login to them "No one mentioned that you need to login to them". This make demonstrating things to the client's customer interesting to say the least.

Thats just life when working for the big companies. The bigger the more of a problem they prove to be.

Rob Murphy