I. Love. Tcpdump. Once in a blue moon I'll boot up Wireshark, but it's pretty rare that there's a protocol question I need to answer that I can't answer faster with tcpdump -A.
I use ssldump all the time; I don't think it's actively maintained, but it's not like it's broken. (The author of ssldump is one of the chairs of the TLS WG).
Last time I used it (quite a few months ago) it wasn't recognizing about half the fields in the SSL negotiation. It wasn't useless, but aside from its decryption-capabilities[1] wireshark had it beat because it could recognize and parse nearly all the fields.
[1] Wireshark might have that, but I haven't checked. I like to keep diversity in the tools I use.
If you're on a server that doesn't have an X environment set up for wireshark, you can use tcpdump to spit to a file:
-w Write the raw packets to file rather than parsing and printing them out. They can later be printed with the -r option. Standard output is used if file is ``-''. See pcap-savefile(5) for a description of the file format.
--
You can then open this file in wireshark on your desktop for easier analysis if you wish.
Yeah, I do this all the time also with -s0 (saves all data traffic as well). You need some kind of filter because of all the traffic, but you can see everything afterwards. Easy to use wireshark to show TCP streams reconstructed: http://www.wireshark.org/docs/wsug_html_chunked/ChAdvFollowT... .
Awesome! I always wanted a command-line alternative to wireshark. I learned about tcpdump about a year ago, but the amount of options is a little off putting. I'm glad this guide came along.
Also for node programmers there is https://github.com/mranney/node_pcap I remember doing some pcap C programming some years ago but node with its streaming nature and powerful js derived abstractions is just so much more satisfying to me, simply less boilerplate and tons of fun - don't fall too far down the well.. then again it's Saturday tomorrow! ;)
Just what I needed. Been writing an SSDP stack with the aid of wireshark and it's been painful. I'm on OSX so it's been a case of frigging around with XQuartz as much as anything else. tcpdump is just pleasure and power compared to wireshark.
I guess it depends what you are trying to do. As someone who uses packet captures almost every day to solve other people's problems, all I want to see is an unfiltered binary capture file on the right interface, which I'll then go thru with tshark or Wireshark.
I think learning to build effective display filters in those tools is more useful than learning to use a capture tool in complex ways.
This can apply to troubleshooting your own problems too, as you can then inspect things in your own time and gather evidence to present later, and even use a capture file to replay traffic.
32 comments
[ 7.2 ms ] story [ 92.4 ms ] thread[1] Wireshark might have that, but I haven't checked. I like to keep diversity in the tools I use.
You can then open this file in wireshark on your desktop for easier analysis if you wish.
ssh -c arcfour root@myserver tcpdump -nn -U -s0 -w - 'not port 22' | wireshark -k -i -
e.g. -b filesize:100000 -b files:200 -w somefile
This will make a ring buffer of 200 * 100MB files.
After typing this, I realized this may have limited use cases, but I use it almost every day.
e.g. -C 100 -W 200 -w somefile will get you the same circular ring of 200 100MB files.
Also, don't forget to add the -s 0 flag if you want to get the entire payload.
Those were the days. Now all I can complain about is that you need root permissions on OpenBSD merely to read a capture file.
How does that even work? It seems like if you can read the file there is nothing stoping you from trying to parse its contents.
http://www.tcpdump.org/pcap.html
Lately I have been playing with a Go interface to it, https://github.com/miekg/pcap
Great tool, and lots of fun.
http://hackage.haskell.org/package/pcap-0.2/docs/Network-Pca...
I think learning to build effective display filters in those tools is more useful than learning to use a capture tool in complex ways.
This can apply to troubleshooting your own problems too, as you can then inspect things in your own time and gather evidence to present later, and even use a capture file to replay traffic.
Personally I prefer multilog + pflogd + some other tool to examine the pcap file.
My old favorite is nc-data -d. The entire program fits on one page.
od or xxd -c1 |cut -d: -f2 will work too.
ngrep is fussy about interface types but I use that too.
Filters for nc-data output can be written in lex, sed, awk, lua, whatever.
I've even experimented with snobol4 and spitbol on packets since the output format of nc-data is so simple.
tcpdump -i int -n -w - -l -s 1500 | strings