tcpdump isn’t just a packet sniffer; it’s a time machine for your network, letting you rewind and replay exactly what happened between two points.
Let’s watch it in action. Imagine a web server (IP 192.168.1.100) that’s suddenly slow to respond to requests from a client (IP 192.168.1.50).
First, on the server, we start capturing traffic destined for or originating from the client:
sudo tcpdump -i eth0 -w /tmp/server_capture.pcap host 192.168.1.50 and port 80
-i eth0: Specifies the network interface to listen on. Replaceeth0with your server’s actual interface name.-w /tmp/server_capture.pcap: Writes the captured packets to a file namedserver_capture.pcapin the/tmpdirectory. This is crucial for later analysis.host 192.168.1.50: Filters traffic to only include packets coming from or going to the client’s IP address.and port 80: Further refines the filter to only look at HTTP traffic (port 80).
While tcpdump is running on the server, the client makes a request:
curl http://192.168.1.100
Now, we stop the tcpdump on the server (Ctrl+C) and transfer server_capture.pcap to our analysis machine. On the analysis machine, we use tcpdump again, this time to read the file and filter for specific conversations:
tcpdump -r /tmp/server_capture.pcap -n 'host 192.168.1.50 and host 192.168.1.100'
-r /tmp/server_capture.pcap: Reads packets from the specified.pcapfile.-n: Preventstcpdumpfrom resolving IP addresses to hostnames and port numbers to service names, making the output faster and cleaner.'host 192.168.1.50 and host 192.168.1.100': This filter ensures we only see packets exchanged between our client and server.
The output might look something like this (simplified):
14:05:01.123456 IP 192.168.1.50.12345 > 192.168.1.100.80: Flags [S], seq 123456789, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 12345 ecr 0], length 0
14:05:01.123500 IP 192.168.1.100.80 > 192.168.1.50.12345: Flags [S.], seq 987654321, ack 123456790, win 28960, options [mss 1460,nop,wscale 7,sackOK,TS val 56789 ecr 12345], length 0
14:05:01.123550 IP 192.168.1.50.12345 > 192.168.1.100.80: Flags [.], ack 987654322, win 1024, options [TS val 12350 ecr 56789], length 0
14:05:01.123600 IP 192.168.1.50.12345 > 192.168.1.100.80: Flags [P.], seq 123456790:123457130, ack 987654322, win 1024, options [TS val 12355 ecr 56789], length 340: HTTP: GET / HTTP/1.1
14:05:05.500000 IP 192.168.1.100.80 > 192.168.1.50.12345: Flags [.], ack 123457130, win 28960, options [TS val 61234 ecr 12355], length 0
14:05:10.500000 IP 192.168.1.100.80 > 192.168.1.50.12345: Flags [P.], seq 987654322:987684322, ack 123457130, win 28960, options [TS val 66234 ecr 12355], length 30000: HTTP: (chunk size 29992)
14:05:10.500050 IP 192.168.1.50.12345 > 192.168.1.100.80: Flags [.], ack 987684322, win 1024, options [TS val 12400 ecr 66234], length 0
14:05:15.500000 IP 192.168.1.100.80 > 192.168.1.50.12345: Flags [P.], seq 987684322:987690322, ack 123457130, win 28960, options [TS val 71234 ecr 12355], length 6000: HTTP: (chunk size 5992)
14:05:15.500100 IP 192.168.1.50.12345 > 192.168.1.100.80: Flags [.], ack 987690322, win 1024, options [TS val 12450 ecr 71234], length 0
14:05:16.000000 IP 192.168.1.100.80 > 192.168.1.50.12345: Flags [F.], seq 987690322, ack 123457130, win 28960, options [TS val 71734 ecr 12355], length 0
14:05:16.000050 IP 192.168.1.50.12345 > 192.168.1.100.80: Flags [R.], seq 0, ack 0, win 0, length 0
We can see the TCP handshake (SYN, SYN-ACK, ACK), the client sending a GET request, and the server responding with data. Notice the timestamps. The GET request is sent at 14:05:01.123600. The first chunk of data from the server arrives at 14:05:05.500000. That’s a four-second gap – the "slowness" we’re investigating.
The problem is that tcpdump itself is a passive observer. It doesn’t do anything; it just records. To understand what’s happening, you need to interpret the data. This means understanding TCP flags ([S] for SYN, [P] for PUSH, [F] for FIN, [R] for RST, [.] for ACK), sequence numbers (seq), acknowledgment numbers (ack), window sizes (win), and TCP options (like mss for Maximum Segment Size, wscale for window scaling, and TS for Timestamps).
The "slowness" we observed (the 4-second gap) is a critical clue. We’d then use this capture to investigate why that gap exists. Is the server processing slowly? Is there network congestion? Is a firewall dropping packets? The capture itself doesn’t tell you the root cause, but it tells you where to look.
The true power comes from combining tcpdump with other tools. For instance, you could run wireshark on the .pcap file to get a graphical view and even more detailed protocol dissection. Or, you could use tshark (the command-line version of Wireshark) for more advanced filtering and analysis directly from the command line.
The next step after analyzing a single conversation is often to broaden the scope, perhaps looking at traffic on the server’s default gateway or examining upstream network devices.