On a Linux server, how do you use tcpdump to choose the right interface and save traffic for later analysis in Wireshark?
answer
- list devices before listening
- default interface is a guess
- raw packets, not printed text
- the any device is cooked
basics
~20 sList capture devices with tcpdump -D, capture with tcpdump -i eth0 -w /var/tmp/web.pcap and a filter, stop with -c or Ctrl-C, then read the file with -r or Wireshark. Use -i any only to find the interface.
solid answer
~40 s`tcpdump -D` lists every device libpcap can capture on, numbered, and `-i` takes the name or the number. Without `-i`, tcpdump 4.99 picks the lowest-numbered interface that is up, excluding loopback, which on a multi-homed host can be the wrong NIC. `-w /var/tmp/web.pcap` saves the raw packets in pcap format instead of printing them; redirecting printed output with `>` only saves text that Wireshark cannot open. Stop with `-c 5000` or Ctrl-C, put the filter expression last, and read the file back with `tcpdump -r` (no root needed) or Wireshark. `-i any` captures all regular interfaces on Linux, but with a cooked pseudo-header instead of the Ethernet header and never in promiscuous mode.
code
bash · 3 linestcpdump -D
sudo tcpdump -i eth0 -c 5000 -w /var/tmp/web-443.pcap 'tcp port 443'
tcpdump -n -r /var/tmp/web-443.pcap | head -20go deeper
Recall the four moves: -D to list devices, -i to choose one, -w to save raw packets, -r to read them back. Say clearly that redirected text is not a capture file.
Explain how tcpdump picks an interface when -i is missing and what the any pseudo-interface changes: a cooked header, no promiscuous mode, possible duplicates across interfaces.
Show the production habits: name the interface on multi-homed hosts, bound the capture with -c or a filter, check the drop counters before trusting the file, and treat captures as sensitive data.
Discuss who may capture on production hosts, where capture files may live and for how long, and how a team standardises a capture runbook so evidence is consistent across incidents.
## What a first capture has to decide A packet capture with **tcpdump** settles three things before it starts: which **capture device** to listen on, where the packets go (decoded and printed to the terminal, or saved raw to a **savefile**), and when to stop. Getting one of them wrong gives the classic first-capture failures: a file Wireshark refuses to open, a capture of the wrong network card, or a capture that runs until the disk is full. ## Choosing the interface - `tcpdump -D` (long form `--list-interfaces`) prints every device libpcap can capture on, each with a number, a name and often a description. Either the number or the name can be passed to `-i`. - Without `-i`, tcpdump 4.99 searches the interface list for the **lowest-numbered interface that is up, excluding loopback**. On a host with a management NIC, a bond, VLAN sub-interfaces or container bridges, that guess is easily the wrong one, so name the interface. - `-i any` is a **pseudo-interface** on Linux (and recent macOS and Solaris) that captures from all regular network interfaces at once. It is the right first move when you do not know which interface carries a flow, because each printed line names the interface it was seen on. - `-Q in`, `-Q out` or `-Q inout` (long form `--direction`) keeps only received or only sent packets, on platforms that support it. | | Named interface (`-i eth0`) | `-i any` on Linux | |---|---|---| | Link-layer header | the real Ethernet header, both MAC addresses | a cooked pseudo-header: packet type, interface, one source link-layer address | | Promiscuous mode | requested by default; `-p` turns the request off | never | | Same packet seen twice | no | possible when it crosses two interfaces | | Best for | a known path, MAC-level questions | finding which interface carries the flow | On Linux the cooked header (link type `LINUX_SLL2`, the default for `any` since tcpdump 4.99.0 where libpcap supports it) records whether a packet was addressed to this host, broadcast, multicast, addressed to another host or sent by this host, and printed lines show the interface name with `In` or `Out`. A packet that crosses a bridge and its member port, or a VLAN sub-interface and its parent, can be captured once on each. ## Promiscuous mode and `-p` By default tcpdump asks for **promiscuous mode** on a named interface, so the NIC passes up frames that are not addressed to it. On a switched network that rarely adds much: the switch delivers this host's traffic plus broadcast and flooded frames unless a mirror port feeds the interface, and getting other hosts' traffic to the capture point is a separate subject. `-p` (`--no-promiscuous-mode`) tells tcpdump not to enable it. The man page warns that the interface may already be promiscuous for another reason, so `-p` is not a filter meaning "only my traffic". ## Writing and reading a file - `-w file` writes the **raw packets** in pcap format instead of decoding and printing them; `-w -` writes them to standard output. - Redirecting printed output with `>` saves **text**. Calling it `.pcap` changes nothing: readers recognise a capture file by the magic number in its header, not by its extension (tcpdump adds none, though the man page recommends `.pcap`). - `-r file` reads a savefile back. It needs **no special privileges**, unlike opening a live device. - `-c count` exits after that many packets. Without `-c`, tcpdump runs until it receives SIGINT (Ctrl-C) or SIGTERM. - On exit tcpdump reports packets captured, received by filter and dropped by kernel; a non-zero drop count means the file has gaps the network did not cause. ## A safe first capture, step by step 1. Run `tcpdump -D` and identify the interface that carries the traffic, or watch `-i any` for a few seconds to see which interface the flow uses. 2. Capture to a disk with room: `sudo tcpdump -i eth0 -c 5000 -w /var/tmp/web-443.pcap 'tcp port 443'`. The filter expression always comes last, quoted for the shell. 3. Read the summary for drops, then copy the file off the host and open it in Wireshark, or read it with `tcpdump -r`. 4. Delete the capture when you are done: payloads can hold credentials and personal data.
- Why can't Wireshark open the file produced by `tcpdump -i eth0 > capture.pcap`?Without `-w`, tcpdump decodes each packet and prints a text line to standard output, so the redirect saved text with a `.pcap` name. Capture readers identify a pcap file by the magic number in its header, not the extension, so Wireshark finds no capture format. Re-run the capture with `-w capture.pcap`.
- When would you choose `-i any`, and what do you give up?Use it when you do not know which interface carries a flow: a bond, VLAN sub-interfaces, container bridges or policy routing. Each packet is tagged with its interface and direction. You give up the Ethernet header (a cooked pseudo-header keeps only one source link-layer address), promiscuous mode, and you may see a packet twice if it crosses two interfaces. Once you know the interface, capture on it by name.
- Does reading a capture back with `tcpdump -r` need root?No. tcpdump's man page says reading a saved packet file needs no special privileges; only opening a live capture device does. A common practice is to capture with sudo, change the file's owner or copy it, and analyse it as an ordinary user.
saying these in an interview costs you the question
- Redirecting tcpdump's printed output with > produces a pcap file Wireshark can open.
- Without -i, tcpdump captures on every interface at once.
- Capturing on -i any puts every interface into promiscuous mode.
- The .pcap extension is what makes a file readable as a capture.
- Reading a saved capture with tcpdump -r needs root, just like capturing.