tcpdump: The Packet Capture Tool Every Network Engineer Should Know

The Moment I Saw tcpdump in Action

Back in 2016, I was working as a network engineer. A VoIP issue landed on our desk — calls weren't connecting through the SIP proxy. Users reported failed calls, but the PBX logs showed nothing obvious. We escalated to Cisco TAC.

A tier 3 support engineer joined the session. He didn't ask for screenshots or logs. He SSHed directly into the SIP proxy server and ran one command:

tcpdump -i vlan100 port 5060 -w /tmp/sip_capture.pcap

"Make a test call," he said. We did. Five minutes later, he stopped the capture and opened the file. Scrolling through SIP messages — INVITE, TRYING, RINGING — he pointed at one line. The SIP proxy was sending a 403 Forbidden response. The trunk configuration on the proxy side had a mismatch. One config change later, calls connected fine.

That moment stuck with me. No guessing. No trial and error. Just packets on a screen showing exactly what happened. tcpdump gave him ground truth in five minutes.

What tcpdump Is (30 Seconds)

tcpdump is a command-line packet analyzer. It captures network traffic on a system's interface and displays packet headers (and optionally payloads) in real time, or writes them to a file for later analysis.

Key facts:

• Runs on Linux, macOS, and BSD — and, on some Cisco platforms with an underlying Linux shell (Nexus, ACI leaf switches, IOS-XE Guest Shell), a real version of it is available too
• Ships pre-installed on most Linux distributions
• No GUI required — works over SSH on headless servers
• Captures raw packets off the wire
• Output readable by Wireshark, tshark, or other pcap tools

Why does CLI matter? Because the server with the problem rarely has a desktop environment. When you SSH into a remote box at 2 AM troubleshooting a production issue, tcpdump is already there waiting.

Installing tcpdump

On the AlmaLinux VPS I run day to day:

sudo dnf install -y tcpdump

On a NixOS workstation, drop it into a shell without installing anything permanently:

nix-shell -p tcpdump

Or add it to your system packages if you want it around permanently:

# configuration.nix
environment.systemPackages = with pkgs; [
  tcpdump
];

Debian/Ubuntu:

sudo apt install -y tcpdump

macOS ships an older bundled version out of the box; grab the current release with Homebrew if you want the latest features:

brew install tcpdump

Basic tcpdump Commands

Capture on a specific interface

tcpdump -i eth0

Captures all traffic on eth0. Without filters, this is noisy — useful only for quick sanity checks.

Filter by port

tcpdump -i eth0 port 80

Captures only HTTP traffic. Swap 80 for 5060 (SIP), 53 (DNS), or 443 (HTTPS).

Filter by host

tcpdump -i eth0 host 192.168.1.100

Captures traffic to or from that IP address.

Write to a file (pcap format)

tcpdump -i eth0 -w /tmp/capture.pcap

Saves raw packets to a .pcap file. Open it later with Wireshark or read it back with tcpdump itself.

Read from a file

tcpdump -r /tmp/capture.pcap

Replays a saved capture in the terminal.

Capture a limited number of packets

tcpdump -i eth0 -c 50

Captures 50 packets, then stops. Handy for quick snapshots without flooding your terminal.

Combine filters

tcpdump -i eth0 host 10.0.0.5 and port 443

Captures HTTPS traffic involving that specific host.

tcpdump -i eth0 port 5060 or port 5061

Captures SIP traffic on both the standard and TLS ports.

Verbose output

tcpdump -i eth0 -vvv port 53

Shows detailed DNS packet info. More vs mean more verbosity.

When to Reach for tcpdump

Network connectivity issues. "Is traffic even reaching this server?" Run tcpdump on the destination interface. If packets show up, the network path is fine. If not, the problem is upstream.

Protocol debugging. HTTP returning 502? Capture on port 80/443 and see if the backend is responding at all. DNS not resolving? Capture on port 53 and check whether queries go out and answers come back. SIP calls failing? Capture on port 5060 and trace the full call flow — INVITE, response codes, BYE.

Firewall verification. Firewall rules say traffic should pass. But does it? tcpdump shows what actually hits the interface. If packets arrive but no response goes out, the firewall or the application itself is dropping them.

Remote troubleshooting. SSH into the affected machine, run tcpdump, watch packets in real time. No physical access needed, no GUI tools, nothing extra to install. This is why network engineers reach for it constantly.

The "it works from my machine" problem. A client says a service is unreachable. You test from your machine and it works fine. Run tcpdump on the server while they reproduce the issue, then compare. Often the answer is sitting right there in the packet headers — wrong destination IP, a dropped SYN, unexpected reset flags.

tcpdump vs Wireshark

Both analyze packets. They're built for different moments.

Best practice: capture with tcpdump on the remote server, download the .pcap, and analyze it with Wireshark locally. You get the convenience of CLI capture and the depth of GUI analysis.

What the 2016 Experience Taught Me

Before seeing tcpdump in action, I relied on logs and error messages to troubleshoot. After watching that engineer find the root cause in five minutes, I changed my whole approach.

Now, when I hit a network issue, my first instinct is:

1. SSH into the relevant system
2. Run tcpdump with the right filter
3. Reproduce the issue
4. Read the packets

Logs tell you what the application thinks happened. Packets show you what actually happened on the wire. Sometimes those two stories match. Sometimes they don't.

The SIP proxy was logging nothing useful. The packets showed a 403 Forbidden — proof the proxy itself was rejecting the call. Without tcpdump, we'd have spent hours checking PBX configs, codec settings, and firewall rules one by one. With it, five minutes and done.

Getting Started

tcpdump needs root or sudo access to capture packets:

sudo tcpdump -i any port 80

Start simple. Pick one service. Capture traffic while it's working. Then capture while it's broken. Compare the two captures side by side. You'll learn more from 10 minutes of packet capture than from hours of reading documentation.

Every network engineer should know tcpdump. It isn't fancy. It isn't modern. It doesn't have a slick UI. But it's everywhere, it works, and packets don't lie.

Have a tcpdump war story? Share it in the comments.