Wireshark Reviews

Wireshark is hands down one of the best analysis tools on the planet. It is intuitive, simple to use, and gives the depth needed to find problems in today's network and application environments. Sometimes it can be tough to remember some of the filtering commands though, so here is a list of some of my favorites:

1. !(ip.addr==10.0.0.1) [displays everything except IP traffic to or from 10.0.0.1]

2. ip.addr==10.0.0.1 && ip.addr==10.0.0.2 [sets a conversation filter between the two defined IP addresses]




3. http or dns [sets a filter to display all http and dns]




4. tcp.port==4000 [sets a filter for any TCP packet with 4000 as a source or dest port]




5. tcp.flags.reset==1 [displays all TCP resets]




6. http.request [displays all HTTP GET requests]




7. tcp contains traffic [displays all TCP packets that contain the word ‘traffic’. Excellent when searching on a specific string or user ID]




8. !(arp or icmp or dns) [masks out arp, icmp, dns, or whatever other protocols may be background noise. Allowing you to focus on the traffic of interest]




9. udp contains 2069999999 [sets a filter for the number string, great when trying to locate a specific caller ID in a VoIP capture]




10. tcp.analysis.retransmission [displays all retransmissions in the trace. Helps when tracking down slow application performance and packet loss]

The most daunting problem to troubleshoot is when the application spits out a generic error that could mean anything. Here’s the analogy; how helpful is the ‘Check Engine’ light on your car dashboard.

The worst part is when the customer tries to take the cryptic, generic application error message and tries to make sense of it in an attempt to assist the analyst. Don’t get me wrong, any information is helpful while troubleshooting, but you have to be selective in what you pursue.

In this example FTP works one moment and fails the next. Of course the customer immediately called the help desk, who pings the ftp server and comments that is up and no outages have been recorded by the network management system. Then the ticket goes to the server dept who ftp’s without an issue, unfortunately by now so can the customer. The server department says the connection error must be a ‘network thing’.

I captured some packets and have recreated what I found and how the application, Chrome in this example, failed to pass on the FTP server connection limit error. The only way I was able to get real meaningful data is from the wire.

This isn’t a Chrome ‘bash’ session since I have seen many applications not report what was on the wire or reinterpret what was reported by the server.
In summary, the ftp server ran out of connections or had a limit on the number of connections an IP address could have. The administrator was told about this and the FTP server configuration was adjusted to allow more connections.

http://www.youtube.com/watch?v=zJoeYugcvTA

A customer called me and wanted some help troubleshooting some wireless problems. Their users have been reporting intermittent wireless performance issues and getting ‘dropped’. To top it all off, their WLAN controller has also been reporting ‘containment’ error messages that weren’t to descriptive or helpful.

I showed up on site and did all the basic RF checks with my AirMagnet Spectrum XT to make sure there wasn’t an RF issue like an interferer or channel planning issues. Like I always say, “Start at Layer 1”.

Then I moved up a layer using my Fluke Networks AirCheck and AirMagnet WiFi Analyzer. Everything looked pretty quiet and nothing jumped up at me, so I saved some trace files to review later.

Then I thought I would take the trace file and open it with Wireshark since I have more experience with packet analysis than I do using the AirMagnet/AirCheck tools.

In this video I show you some of the filters I used, what they mean and what I found.

I always enjoy getting to the packet level since packets don’t lie, but would also like to spend more time with the other tools now that I know what issues are to see how, or what, they report.

In closing there are a few points I want to make sure aren’t lost throughout the video;

1. Just because I used Wireshark to find some clues does not mean that the other tools were less effective, I just have more experience with protocol analysis/Wireshark.

2. If you deploy any kind of wireless intrusion system, make sure you don’t just turn it on without proper network due diligence.

http://www.youtube.com/watch?v=rpL5irIj_Qo