A tcpdump tutorial and primer(danielmiessler.com)
danielmiessler.com
A tcpdump tutorial and primer
http://www.danielmiessler.com/study/tcpdump
32 comments
Which one came first? Tcpdump or pcap?
[deleted]
[deleted]
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! ;)
For those who want a functional(ish?) and strongly typed interface to tcpdump, hackage has the answer:
http://hackage.haskell.org/package/pcap-0.2/docs/Network-Pca...
http://hackage.haskell.org/package/pcap-0.2/docs/Network-Pca...
Correct me if I'm wrong, but hasn't tcpdump had several buffer overflows in the past?
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.
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.
One of my favs:
tcpdump -i int -n -w - -l -s 1500 | strings
tcpdump -i int -n -w - -l -s 1500 | strings
Previous discussion: https://news.ycombinator.com/item?id=4744427
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.
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:
You can then open this file in wireshark on your desktop for easier analysis if you wish.
-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... .
Hmm, how about display TCP payload only, capture SSL without ssldump, filter packets by process id?
It feels like ssldump has been abandoned and is horribly out-of-date. Is anybody maintaining it these days?
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.
[1] Wireshark might have that, but I haven't checked. I like to keep diversity in the tools I use.
tcpdump is one of my pet responses when people ask me why I still use terminal-based tooling.
tcpdump for the win!
I use this tutorial all the time when I'm trying to debug MTA issues.
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.
Command-line alternative to wireshark is tshark. tshark is much more capable, since you can use all the well-made Wireshark protocol dissectors.
tshark also has a fabulous ring buffer feature that lets you run captures continuously while chunking the files up into manageable sizes.
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. -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.
If you are on a system that doesn't have tshark, tcpdump provides the same functionality via the -C <file_size_in_MB> -W <num_files> flags.
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.
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.
It's a great ad-hoc solution for monitoring types of traffic. I've used it too. :-)
Who else remembers when tcpdump kept on refusing to put a "see raw packet" option because you might use it to steal passwords?
Those were the days. Now all I can complain about is that you need root permissions on OpenBSD merely to read a capture file.
Those were the days. Now all I can complain about is that you need root permissions on OpenBSD merely to read a capture file.
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.
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.
It's in the binary. You can bring your own /usr/sbin/tcpdump if you wish. If this seems like an incredibly low bar to you, I agree.
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.
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.
This is a great tool for getting free wi-fi if you know what you're doing and can change your MAC address.
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.