Tools · Network tools · 01 / 24
tcpdump: what a capture file actually holds
tcpdump records frames from an interface you are allowed to listen on, or reads a pcap you already have. The file is evidence: who talked, when, and how much, plus any bytes the protocol left in the clear.
The question the tool is for
tcpdump answers a narrow question: what frames did this interface see? You name an interface on a lab machine, or you point -r at a pcap or pcapng someone already saved under the engagement rules. The output is one line per frame, or a raw file you can open later in tshark or Zeek.
A capture is a copy of other people's traffic the moment the interface can see them. On a host-only lab NIC you see the lab. On a shared office segment, promiscuous mode can see machines that are not yours. The scope names the interface and the addresses. If it does not, you do not start a capture.
What gets stored
With -w, tcpdump writes the raw frames. It does not store your display options. -nn, -tttt, and -A change the printed lines when you read the file back. They do not rewrite the evidence. A later reader with permission to open the file sees the same frames you saved.
The snapshot length is how many bytes of each frame are kept. Current tcpdump defaults to 262144 bytes, which covers a normal Ethernet frame. -s 0 selects that default, which is why older notes say -s 0 to avoid a short snapshot. If a printed line ends in [|proto], the snapshot was too short and the rest of that frame is gone. Recapture with a larger -s if the scope still allows it.
- -i names the interface. List links first and pick the lab NIC the scope allows.
- -w writes a pcap. -r reads one. Reading does not need root when the file is readable by you.
- -c stops after a count, so a first look stays small.
- -p skips promiscuous mode when the scope says you may record only this host's own traffic.
A worked defensive case
A lab ticket says the files VM stopped answering the web tier at 10:14. You are allowed to record on the web tier's host-only NIC, eth0, and the only addresses in scope are 10.8.0.20 and 10.8.0.40. You capture 200 frames of their TCP/443 conversation and stop. The file is a few hundred kilobytes, time-stamped, and stored next to the ticket.
You do not open the file on a laptop that also holds production SSH keys, and you do not mail it. The next lessons read it. The change from this step alone is already useful: the ticket now has a bounded artifact instead of a guess that the network was down.
Where this is documented
The tcpdump manual describes -i, -w, -r, -c, -s, and -p. pcap-filter(7) is the language of the expression at the end of the command. When those pages and an old blog disagree, trust the manual for the version you are running.
Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.
Commands
sudo tcpdump -i eth0 -s 0 -U -w /lab/evidence.pcap -c 200 'host 10.8.0.20 and tcp port 443'
tcpdump -nn -tttt -r /lab/evidence.pcap -c 1
Diagram
From an allowed interface to a file you can hand off
- Scope
The ticket names the lab NIC and the two addresses. That is the whole capture.
- Interface
tcpdump listens on that NIC. -c stops the file from growing past the question.
- File
-w stores frames. -U flushes each frame so a short run is still a valid pcap.
- Read
Later commands use -r. Display flags change the printout, not the file.
Check yourself
1. You saved a lab capture with -w. A teammate asks you to add -nn to the file so the addresses stay numeric on disk. What is true?
2. A printed line ends in [|http]. What happened?
3. The scope says you may record the lab web tier's own traffic, and the NIC is on a shared segment. Which flag matches that limit?