A tcpdump Tutorial and Primer

As a sysadmin, I find it's great for problem localization. Usually an application has a pile of services behind it. Where is it going wrong? Appserver? Backend database? Name resolution? network contention? misrouted? blocked by a firewall?

You can cut away huge swaths of troubleshooting areas just by watching what is on the wire. There are problems you just won't find without knowing how to use a sniffer. I once had a core router dropping packets because of a flawed ACL implementation (It would treat fragmented packets as if they had port numbers at the matching payload offset).

Knowing how to use a packet sniffer makes hard problems so easy it feels like cheating.

It's even useful for answering bland user questions like "Hm... is this hanging process just not honoring my proxy settings? Yup."

I used it several months ago to reverse engineer the data our POSes (point of sale devices) send to our licensed ERP app (bundled together by vendor) so we can use a superior POS, as they would rather force us to use their crap than publish an API.

The power of a ring buffered capture should not be underestimated. Having an intermittent problem that you can't seem to catch while it's happening? Just let the capture run saving the last 2hrs of traffic. When the problem happens, pull the capture files.

Personally I prefer dumpcap and wireshark for this, but it's similar.

If I'm only a few key presses away from the solution when using a terminal to some small box, I certainly don't want to play with a big who-knows-dependent-on-which-libraries who-knows-how-much-time-to-install Wireshark.

I use Wireshark when I need to. I prefer to type a few characters in the command line if that's enough to get the right answer.

People are obsessed with command line tools because they offer the most basic interface, which is not likely to change. One of the commonly cited programming aphorisms is to "Program to an 'interface', not an implementation." Learning a GUI tool is usually easier in the short term, but becomes less flexible in the long run. As you become an increasingly skilled developer you realized that you gain order of magnitude more productivity by working at increasingly higher levels of automation and abstraction. This can be very difficult with a graphical interface since it would likely take much more work to create an adapter which will allow your code to work with the GUI interface than a command line one. GUIs are also likely to be complex and thus have the potential for bugs and performance costs.

Wireshark solves another problem, when you need it, you have a problem where you want to analyze the packet content, or drill and cut through a historical capture. That's not always what you need, and it's often cumbersome to run on a remote server that isn't supposed to have GUI stuff installed anyhow.

Sometimes you just need to know if DNS resolution is working.

Or if the right DNS server is queried.

Or if some server backend is actually firing off packets to the proper place when you hit a button on the frontend.

Or you just need to verify that data are coming in when the guy on the phone says "check again now".

For these sort or problems, tcpdump is great, as it easily allows you to experiment with different filters on the command line, which will take you an order of magnitude more time click through in wireshark or wait for reparsing if you use a display filter.

Sometimes (most times?) you want to do the analysis in real-time in which case it helps to be fluent in tcpdump. Also, whether you're looking at the wireshark gui or tcpdump in a terminal, you're essentially looking at text. So a high res (retina) display is going to be nice to have in either case.

Since when is "displaying stuff" synonymous with "analysis?" If you're "analyzing" your data by staring at it, you're almost certainly doing it wrong. Real questions with real (i.e. non-ambiguous) answers have small representations, more or less by defintion. The point of analysis is coming up wiht ideas and testing them. That's a programming problem (whether or not it's done in a "programming language") and is naturally well suited to a text stream.

I mean, I'm all for having nice GUI tools. And I've even been known to stare at giant data dumps when stumped (though I'll note that a maximized terminal window with grep-over-tcpdump-output content works just as well as wireshark for that purpose). But that argument is just silly.

Wireshark is really useful, but it's also had security problems (I think I'm not being unfair here) continuously over its entire existence. I started using it over 10 years ago back when it was called Ethereal, and I feel like I've seen probably hundreds of Ethereal/Wireshark security advisories in that time.

Or the best of both worlds, tshark! http://www.wireshark.org/docs/man-pages/tshark.html

All the filter stuff will be applicable for Wireshark as well though.

Generally you're already there on the command line, a few keystrokes away from the desired result.

Also people are lazy.

I use tcpdump on embedded systems, some of them with very limited ram disks. In that case tcpdump fits the bill nicely.

If you're going to be loading the capture in to Wireshark anyway, not just use Wireshark to do the capture to begin with?