
A tcpdump Tutorial and Primer - danielrm26
http://danielmiessler.com/study/tcpdump
======
praptak
It is not only useful for security professionals. Anybody doing any kind of
network programming should have it under their belt. Application level
debugging only goes so far. Sooner or later you'll hit a problem like a
network card sometimes sending super jumbo frames which the switch cannot
handle or some weird performance problems. Packet level debugging is a must in
such cases.

~~~
johngalt
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.

~~~
spydum
Exactly the points I was coming to make. People I work with think I am some
sort of addict when my default answer when someone asks me about a problem is
to fire up a packet capture. Between tcpdump, nc, and burpsuite, seems like
few network gremlins can hide.

------
adulau
A good tutorial but there some missing options or remarks that are very handy
like:

\- -A is equivalent to -X displaying the payload of the packet in ASCII
format. If you want to do some scripting based on a payload, that's very handy
for matching specific pattern (don't forget offset notation '[a:b]' is limited
to 4 bytes block in the bpf filter)

\- -tttt if you want to print the complete time-stamp per packet

\- Don't forget that TCP offloading might have an impact when doing packet
capture (and analysis) [http://sandilands.info/sgordon/segmentation-
offloading-with-...](http://sandilands.info/sgordon/segmentation-offloading-
with-wireshark-and-ethtool)

\- When capturing on a long period of time, the -G or -C helps to rotate
capture files while capturing. tcpdump -i en1 -s 0 -G 60 -w
tst%y%m%d%H%M%S.cap (if you want to rotate the file every 60 secs) or -C to do
the rotation based of the size of the capture file.

\- There are many tcpdump forks (OpenBSD tcpdump is slightly different than
the tcpdump on Debian)

~~~
johngalt
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.

------
peterwwillis
Also remember if you're filtering ip/port you may need to add the _vlan_
filter to see packets that are vlan-tagged.

------
revelation
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.

~~~
b6
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.

~~~
stusmall
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.

------
zwieback
Nice, bookmarked.

This might be a useful addition to the links at the bottom of your page:

<http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf>

