Hacker News Reader

Comment by revelation | Hacker News Reader

Yes, please use tcpdump. To capture stuff. Then you put it into Wireshark for analysis.

What is peoples obsession with stretching command line tools? Wake up! We have retina displays now. To display stuff.

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.

Not all of them were just in wireshark. Sometimes the root of the issue was in libpcap which is common code between wireshark and tcpdump.

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.

Whats stopping you from recording it and then analyzing on a beefy machine? Akin to remote debugging, which is clearly the harder problem.

I usually see no need to bother. Why add another step if I don't need it?

The recording part is cumbersome. On these systems there's hardly any writable disk space and I'm not sure if NFS or SMB client is built in. tcpdump is often a quick alternative to capture just the packets I'm interested in in clear text. That requires knowing a little bit about the filter syntax.

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

Maybe you're capturing on a device that doesn't have the grunt or environment to run wireshark?

Reply on news.ycombinator.com