A Guide to tcpdump on Linux: Capturing and Analyzing Packets for Network Troubleshooting

When the Application Errors Out but Ping Still Works

It’s a classic troubleshooting scenario: a mobile app reports timeouts when calling your API. You SSH into the server, run ping against the database server or third-party API, and see 0% packet loss with a crisp 2ms RTT. Yet backend logs still spit out Connection timed out or Connection refused.

The reason is straightforward: ping relies on the ICMP protocol, whereas applications communicate over TCP/UDP. A successful ICMP Echo Request doesn’t guarantee that TCP port 443 or 5432 is accepting traffic. A firewall might be blocking application-specific ports, or the web server’s backlog queue could be maxed out. To pinpoint what is truly happening on the wire, you need packet-level visibility with tcpdump.

How tcpdump Captures and Analyzes Traffic

tcpdump is the quintessential command-line packet analyzer powered by the libpcap library. It intercepts raw frames directly at the Network Interface Card (NIC) before the operating system kernel or iptables stack processes them further.

When debugging TCP connections, focus on these four flags displayed inside square brackets [...]:

• [S] (SYN): Initiates the 3-way handshake.
• [S.] (SYN-ACK): The server acknowledges the handshake and responds to the client.
• [.] (ACK): Acknowledges receipt of previous packets.
• [F] (FIN): Gracefully terminates the connection from one side.
• [R] (RST): Abruptly resets the connection. This usually points to a closed port, a crashed recipient process, or a firewall actively sending an RST to reject traffic.

Hands-On: Essential tcpdump Commands

1. Quick Installation

tcpdump is available in the default package repositories of almost every Linux distribution:

# Ubuntu / Debian
sudo apt update && sudo apt install -y tcpdump

# RHEL / CentOS / Rocky Linux / AlmaLinux
sudo dnf install -y tcpdump

2. Listing Available Network Interfaces

First, inspect the available network interfaces on the host:

sudo tcpdump -D

The output lists interfaces alongside their index numbers, such as 1.eth0, 2.ens33, or any (to capture traffic across all interfaces).

3. Must-Know Command Parameters

Running a raw tcpdump command will flood your terminal instantly. Always pair it with these essential flags:

• -i <interface>: Specifies the network interface (e.g., -i eth0 or -i any).
• -n: Disables IP-to-hostname DNS lookups, significantly reducing terminal rendering lag.
• -nn: Disables both hostname and port name resolution (displaying raw ports like 80 and 443 instead of http and https).
• -c <count>: Exits automatically after capturing the specified number of packets (e.g., -c 20).
• -q: Quiet mode; outputs compact packet metadata.

A safe one-liner to quickly preview the first 5 packets:

sudo tcpdump -i eth0 -nn -c 5

4. Filtering Traffic with BPF (Berkeley Packet Filter)

The true power of tcpdump lies in its expressive BPF syntax. You can combine multiple criteria using and, or, and not.

Scenario A: Isolating a Specific Source or Destination IP

When investigating a specific client (e.g., 192.168.1.50) experiencing API call issues:

# Capture all bidirectional traffic to and from 192.168.1.50
sudo tcpdump -i eth0 -nn host 192.168.1.50

# Inspect only requests sent from the client to the server
sudo tcpdump -i eth0 -nn src host 192.168.1.50

# Inspect only server responses returning to the client
sudo tcpdump -i eth0 -nn dst host 192.168.1.50

Scenario B: Debugging Web Server Connections (Port 80 / 443)

Filter strictly for HTTP/HTTPS traffic to analyze TCP handshakes:

sudo tcpdump -i eth0 -nn "port 80 or port 443" -c 50

If you observe repeated client [S] packets met with server silence (no [S.] response), iptables or UFW is likely dropping the traffic. Conversely, if the server immediately fires back an [R] (RST) flag, Nginx or Apache has likely crashed or failed to bind to the port.

Scenario C: Diagnosing DNS Timeouts (Port 53)

Does curl hang for 5 to 10 seconds before downloading data? Slow DNS resolution is often the culprit:

sudo tcpdump -i eth0 -nn udp port 53

You can clearly see which resolver (e.g., 8.8.8.8 or a local resolver) received the A/AAAA queries and how many milliseconds elapsed before a response arrived.

5. Exporting pcap Files for Wireshark

Inspecting intricate TLS handshakes or complex HTTP payloads in a terminal is error-prone. Export the raw packets to analyze them visually in Wireshark:

# Capture 200 packets on port 443 and save them to dump.pcap
sudo tcpdump -i eth0 -nn -c 200 port 443 -w /tmp/dump.pcap

To inspect this capture file later directly on the server without a GUI:

tcpdump -nn -r /tmp/dump.pcap

6. Production Safety Warnings

Under heavy load, tcpdump can trigger CPU spikes or exhaust disk space through aggressive write I/O. For example, an API cluster handling 10,000 req/s can generate gigabytes of pcap data in just two minutes.

To prevent resource exhaustion from taking down your production servers, adhere to these three rules:

• Always specify -c: Cap the capture with a hard limit (e.g., -c 500 or -c 1000).
• Capture headers only: Use -s 96 (snaplen of 96 bytes) to capture only packet headers while dropping the payload. This slashes capture file size by over 80%.
• Never run unfiltered captures without targeted IP or port filters.

Summary

tcpdump is an indispensable diagnostic utility for anyone administering Linux systems. When cryptic network errors surface, a few targeted tcpdump commands will definitively isolate whether the fault lies in application code, local firewall rules, or the upstream ISP. Keep these practical BPF patterns handy for your next on-call shift.