Introducing the “Sovereign Snippets” Series: Most of our time is spent in complex configurations, but the real power of a Linux system often hides in the short, punchy commands we use every day to maintain control over our hardware. I’m starting this series to document the specific “one-liners” I use to audit, secure, and manage my systems. No fluff—just functional tools for those who prefer the CLI over a GUI.

The Unbounded Capture

When network connectivity fails, the instinct is often to cast the widest net possible. You suspect a routing issue, a firewall drop, or a botched TLS handshake, so you log into the server and type sudo tcpdump -w debug.pcap.

You intend to capture the traffic for just a few seconds, reproduce the error, and hit Ctrl+C. But then your phone rings, or you switch tabs to trigger the API call, and by the time you return to the terminal, tcpdump has captured three gigabytes of irrelevant background noise. You have successfully weaponized network diagnostics against your own /var partition.

A useful packet capture should act like a targeted diagnostic measurement. You must choose the interface, the host, the protocol, and—most importantly—the stopping condition before you press Enter. A well-crafted capture answers a single, specific question.

Step 1: Find the Interface

Before capturing, you need to know where to listen. Do not guess the interface name. Ask tcpdump to list every interface it has access to:

sudo tcpdump -D

(This will output a numbered list of interfaces, including physical adapters like eth0, virtual interfaces, and the Linux-specific any pseudo-interface).

Step 2: The Question-Shaped Capture

Let’s look at how to build a capture command that filters the noise at the kernel level using Berkeley Packet Filter (BPF) syntax.

Scenario A: The Single HTTPS Conversation

You want to watch the traffic between your server and a specific external API endpoint (e.g., 203.0.113.40), but you only care about the HTTPS traffic.

sudo tcpdump \
  -i eth0 \
  -nn \
  -c 50 \
  'host 203.0.113.40 and tcp port 443'

Scenario B: Isolating the Handshake

Perhaps you don’t even care about the encrypted data payload; you only need to know if the initial connection is being successfully established or if it is being actively rejected by a firewall. We can use bitmasking to look exclusively for SYN (synchronize) or RST (reset) flags.

sudo tcpdump \
  -i eth0 \
  -nn \
  -c 30 \
  'host 203.0.113.40 and tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-rst) != 0)'

Scenario C: The Bounded DNS Audit

You suspect DNS resolution is failing, and you need to save the capture to a file so you can pull it down to your workstation and analyze it in Wireshark.

sudo tcpdump \
  -i any \
  -nn \
  -s 256 \
  -c 200 \
  -w /var/tmp/dns-debug.pcap \
  'udp port 53 or tcp port 53'

Once the capture finishes (or hits the 200-packet limit), you can read the file directly in the terminal without touching the network again:

tcpdump -nn -r /var/tmp/dns-debug.pcap

Scenario D: The SSH Feedback Loop

If you are running tcpdump over an SSH connection, and you try to capture all traffic on eth0, tcpdump will capture your SSH packets. It will then print those packets to your screen, which generates more SSH packets, which tcpdump captures and prints. This is a pleasingly recursive failure mode that will quickly lag your terminal.

You must exclude your management connection. Replace 192.0.2.25 with the IP address of your admin workstation:

sudo tcpdump \
  -i eth0 \
  -nn \
  -c 200 \
  -w /var/tmp/remote-debug.pcap \
  'not (host 192.0.2.25 and tcp port 22)'

Breaking Down the Flags

Understanding the flags is the difference between a surgical extraction and a blunt-force trauma.

  • -nn: Crucial. This disables address and port-name resolution. Without it, tcpdump will attempt a reverse DNS lookup on every single IP it sees, which creates extra network traffic and introduces massive delays in the console output.
  • -c <count>: The Packet Limit. This forces tcpdump to exit after capturing the specified number of packets. Use this instead of relying on “Future You” to remember to hit Ctrl+C. (For longer investigations, look into the -G and -W flags to rotate files based on time or size).
  • -w <file>: Write the raw packets to a PCAP file instead of parsing them to the terminal.
  • -s <snaplen>: The Snapshot Length. This limits how many bytes of each packet are saved. tcpdump historically defaults to capturing only the packet headers (often 68 or 96 bytes). Modern versions often default to capturing the whole packet. If you only care about routing or IP headers, setting -s 256 saves massive amounts of disk space. Only use -s 0 (capture everything) when you genuinely need the full application payload.
  • The Quotes '': Always wrap your BPF filter expressions in single quotes. If you don’t, your bash shell will attempt to interpret characters like (, ), &, or | before tcpdump even sees them, resulting in syntax errors.

The Caveats (The Tax on Convenience)

  1. Checksum Offloading: If you are capturing packets locally, you may notice that outgoing packets appear to have broken checksums. This is normal. Modern network cards perform checksum offloading in hardware. tcpdump intercepts the packet at the kernel level before it hits the physical NIC, so the checksum hasn’t been calculated yet.
  2. BPF vs. Wireshark: The filter syntax you use on the command line (BPF) is evaluated by the kernel. This is incredibly efficient because unwanted packets are discarded before they are ever copied to user space. However, BPF syntax is different from the display filters you use inside the Wireshark GUI (tcp.port == 443).
  3. The Evidence Problem: PCAP files are dangerous. They may contain session cookies, plaintext credentials, internal IP addresses, and sensitive application data. Treat them like hazardous diagnostic evidence. Secure them, analyze them, and delete them when the ticket is closed.

Over to you: What is your go-to filter when troubleshooting a mysterious connection drop? Do you prefer parsing the raw text in the terminal, or do you always pull the PCAP down to Wireshark for visual analysis?