What Is tcpdump? Reading Raw IP Packets in the Terminal

Seeing Exactly What Crosses Your Network Interface

Most network troubleshooting tools give you statistics — bytes transferred, connection counts, error rates. tcpdump gives you something more fundamental: the actual packets themselves, in real time, as they cross your network interface. Every TCP handshake, every DNS query, every HTTP request — all visible as raw data in your terminal.

tcpdump has been part of Unix-like systems since 1988. It uses the Berkeley Packet Filter (BPF) framework to capture packets at the kernel level before they reach user-space applications, which is why it can see traffic that other tools miss. On Linux, it uses libpcap. On BSD and macOS, it reads directly from the BPF device. The capture happens at the network interface level, which means you see exactly what is entering and leaving the machine.

This is the tool network engineers reach for when a customer says \"the connection drops randomly\" and no application-level log shows anything. When a security team says \"we think there's unexpected outbound traffic.\" When you need to know with certainty what is actually happening on the wire.

How tcpdump Works: BPF and Kernel-Level Capture

When you run tcpdump, it opens a raw socket on the specified network interface and attaches a BPF filter program to it. The BPF filter runs inside the kernel — packets that don't match the filter are discarded before they ever reach user space. This means tcpdump can operate at very high speeds without saturating the CPU with packet-parsing work in user space.

The flow is:

1. A packet arrives at or departs from the network interface
2. The kernel passes the packet through the attached BPF filter program
3. If the filter matches, a copy of the packet is placed in a ring buffer
4. tcpdump reads from the ring buffer and formats the output
5. Optionally, packets are written to a PCAP file for offline analysis

This architecture allows tcpdump to capture at wire speed even on high-throughput interfaces, and to do so with minimal impact on the system handling the actual traffic.

Basic Usage and Essential Flags

Running tcpdump without arguments captures all traffic on the default interface and prints it to stdout. In practice you almost always want filters. Core flags:

• -i eth0 — specify the network interface. Use -i any to capture on all interfaces.
• -n — do not resolve IP addresses to hostnames. This is critical for performance during high-traffic captures; DNS lookups for each packet slow output dramatically.
• -v / -vv / -vvv — increase verbosity. More detail about TTL, IP flags, checksums.
• -c 100 — capture exactly 100 packets then exit.
• -w capture.pcap — write packets to a PCAP file instead of printing to screen. Open this file later in Wireshark or read it back with tcpdump using -r capture.pcap.
• -s 0 — capture the full packet. By default, older versions of tcpdump truncate to 68 bytes. Setting snap length to 0 captures the complete packet.
• -A — print packet payload as ASCII text. Useful for reading unencrypted HTTP or SMTP traffic.
• -X — print payload as both hex and ASCII.

Writing Effective BPF Filters

Filters are where tcpdump's power becomes apparent. BPF filter syntax lets you compose complex expressions using host, port, protocol, and logical operators:

• tcpdump host 203.0.113.5 — capture all traffic to or from a specific IP
• tcpdump src 203.0.113.5 — capture only traffic originating from that IP
• tcpdump dst 203.0.113.5 — capture only traffic destined for that IP
• tcpdump port 443 — capture all HTTPS traffic
• tcpdump tcp port 22 — capture SSH traffic specifically
• tcpdump not port 22 — capture everything except SSH (useful to filter out your own remote session)
• tcpdump 'src 10.0.0.5 and dst port 80' — compound filter: traffic from a specific source to HTTP
• tcpdump 'tcp[tcpflags] & (tcp-syn) != 0' — capture only TCP SYN packets (new connection attempts)
• tcpdump 'tcp[tcpflags] & (tcp-rst) != 0' — capture TCP RST packets (connection resets)
• icmp — capture only ICMP traffic (pings and unreachable messages)

Quoting complex filters with single quotes prevents the shell from interpreting special characters.

Reading tcpdump Output

A typical tcpdump line looks like:

14:23:01.542108 IP 192.168.1.42.54321 > 93.184.216.34.80: Flags [S], seq 1234567890, win 64240, length 0

Breaking this down:

• 14:23:01.542108 — timestamp with microsecond precision
• IP — this is an IPv4 packet
• 192.168.1.42.54321 — source IP and source port
• 93.184.216.34.80 — destination IP and destination port
• Flags [S] — TCP flags. S = SYN, A = ACK, F = FIN, R = RST, P = PSH. A normal TCP handshake shows [S], [S.] (SYN-ACK), [.] (ACK).
• seq 1234567890 — TCP sequence number
• win 64240 — TCP receive window size
• length 0 — payload length in bytes

tcpdump vs Wireshark: Choosing the Right Tool

Real-World Use Cases

Diagnosing a dropped connection: Run tcpdump -n host <remote-ip> -w session.pcap while reproducing the problem. Open the PCAP in Wireshark afterward and look for RST packets, retransmission storms, or asymmetric routing (packets leaving but no replies arriving).

Finding unexpected outbound traffic: Run tcpdump -n 'not port 22 and not port 80 and not port 443' to see traffic on unusual ports. Any unexpected destination IPs or ports are worth investigating.

Verifying firewall rules: After adding a firewall rule to block a specific IP, run tcpdump to confirm packets from that IP are no longer reaching the server. If they still appear in tcpdump output, the firewall rule is not working as expected.

DNS debugging: Run tcpdump -n udp port 53 to see all DNS queries and responses. You can verify which DNS server queries are going to, what names are being resolved, and whether responses are returning correctly.

TLS handshake verification: Run tcpdump -n 'tcp port 443 and (tcp[tcpflags] & (tcp-syn) != 0)' to see new HTTPS connection attempts without capturing payload data.

Common Misconceptions

Misconception 1: tcpdump requires root everywhere

tcpdump requires the capability to open raw sockets. On Linux, this is CAP_NET_RAW. While traditionally this meant running as root, modern systems can grant this capability specifically: setcap cap_net_raw+eip /usr/bin/tcpdump. On some distributions, adding a user to the pcap group is sufficient. You do not always need full root access.

Misconception 2: tcpdump can see encrypted traffic content

tcpdump captures the raw packets. For TLS/HTTPS traffic, you see the encrypted payload — not the plaintext. You can see that a connection was made, the IP addresses and ports involved, certificate negotiation details, and packet sizes. But the actual HTTP request and response content inside TLS is not readable. To inspect TLS content you need the session keys, which requires application-level cooperation.

Misconception 3: Running tcpdump impacts traffic

tcpdump captures copies of packets; it does not affect the packets themselves. Traffic flows normally. The only impact is CPU and disk I/O from the capture process itself. On very high-throughput links (10 Gbps+), a naive tcpdump capture can drop packets if the ring buffer fills faster than it can be read. For high-speed captures, specialized tools like PF_RING or DPDK-based capture are used.

Misconception 4: tcpdump and Wireshark capture differently

Both use libpcap (or WinPcap/npcap on Windows) as the capture library. They produce the same PCAP format files. The difference is entirely in how they display and analyze the captured data — Wireshark has a rich GUI and deep protocol dissectors; tcpdump prints formatted text to the terminal. A PCAP file captured with tcpdump opens perfectly in Wireshark and vice versa.

Pro Tips for Effective Packet Capture

• Always use -n in production captures. DNS resolution per packet can create additional network traffic and dramatically slow output. Resolve IPs after the fact if needed.
• Write to file with -w when capturing for analysis. Live terminal output is hard to read and you will miss packets. Capture to a PCAP and analyze it offline in Wireshark or with tcpdump -r.
• Rotate capture files with -C and -W. The flags -C 100 -W 10 create a rotating set of 10 files, each 100MB maximum. This prevents a single capture session from filling your disk.
• Filter out your own SSH session. When capturing remotely over SSH, add not port 22 to your filter to avoid an endless loop of SSH traffic capturing itself being printed, which then generates more SSH traffic.
• Use timestamps carefully. The default timestamp is local time. Use -tttt for human-readable timestamps with date, or -ttt for inter-packet timing (useful for latency analysis).
• Combine tcpdump with grep for quick field extraction. Pipe output: tcpdump -n -l | grep -E 'SYN|RST' gives a live feed of connection events. The -l flag enables line-buffered output for pipe compatibility.

Check what traffic your IP is currently generating and receiving.