
When a production server starts behaving strangely at 2AM and you are logged in over SSH with no GUI, your first move is not to restart the service. Your first move is to watch what is actually happening on the network. That is exactly where the tcpdump command in Linux becomes the most valuable tool in your sysadmin toolkit. It is fast, lightweight, and available on virtually every Linux distribution without any extra setup.
In this guide, you will learn how to use the tcpdump command in Linux with examples that cover real-world scenarios. Whether you are diagnosing a DNS failure, hunting a rogue process sending outbound traffic, or auditing your own network for plaintext credentials, tcpdump gives you direct visibility into raw network packets from the command line. This tutorial is written for beginner to intermediate Linux users, developers, and sysadmins who want clear, actionable steps backed by genuine field experience.
We will cover everything from installing tcpdump and reading its output to applying advanced filters and saving captures for Wireshark analysis. Every command includes a plain-English explanation of not just how to run it, but why it works the way it does. By the end of this guide, you will have enough hands-on knowledge to use tcpdump confidently in both test environments and live production systems.
Prerequisites
Before you follow the steps in this guide, make sure you have the following in place:
- Operating System: Any modern Linux distribution (Ubuntu 20.04+, Debian 11+, CentOS 7+, RHEL 8+, Fedora 36+, or Arch Linux)
- User Permissions: Root access or a user account with
sudoprivileges (tcpdump requires raw socket access) - Network Interface: At least one active network interface (run
ip linkto confirm) - Terminal Access: Direct console or SSH session with a stable connection
- Optional Tools: Wireshark installed locally if you plan to analyze
.pcapcapture files offline - Disk Space: At least 500MB of free space if you plan to write captures to file on a busy server
Step 1: Update Your System and Verify Tcpdump Is Available
Why You Should Check Before Installing
Most Linux distributions ship with tcpdump pre-installed. Attempting to install a package that already exists at an older version can cause dependency conflicts on some systems. Running a version check first saves you that headache.
tcpdump --version
Expected output:
tcpdump version 4.99.1
libpcap version 1.10.1 (with TPACKET_V3)
OpenSSL 3.0.2 15 Mar 2022
If you see a version number, tcpdump is already installed. If you get command not found, move to the next sub-step.
How To Install Tcpdump Command on Your Distribution
First, update your package index to avoid installing a stale version.
Ubuntu and Debian:
sudo apt update && sudo apt install tcpdump -y
CentOS and RHEL:
sudo yum install tcpdump -y
Fedora:
sudo dnf install tcpdump -y
Arch Linux:
sudo pacman -S tcpdump
Why sudo is required here: Package managers write to system directories that regular users cannot modify. The sudo prefix temporarily grants the necessary root privileges for that single operation. Tcpdump itself also needs sudo to open raw sockets when you run it, which is a deliberate security restriction built into the Linux kernel.
Step 2: Understand the Basic Syntax and Output Format
The Core Syntax
Every tcpdump command follows this structure:
tcpdump [options] [filter expression]
optionschange how tcpdump behaves (which interface to use, how verbose to be, whether to save to file)filter expressionis a Berkeley Packet Filter (BPF) rule that tells tcpdump which packets to capture
Reading a Live Output Line
Run this command to capture 5 packets and then stop:
sudo tcpdump -c 5 -n -i any
You will see output similar to this:
15:47:24.248737 IP 192.168.1.185.22 > 192.168.1.150.37445: Flags [P.], seq 201747193:201747301, ack 1226568763, win 402, length 108
Here is what each part means:
15:47:24.248737— Timestamp with microsecond precision. Use this to correlate packet events with system logs.IP— The layer-3 protocol. You will also seeIP6,ARP, and others here.192.168.1.185.22— Source IP address with the source port appended after the last dot.>— Direction of traffic. Left side is source, right side is destination.192.168.1.150.37445— Destination IP and port.Flags [P.]— TCP flags.Pis Push,.is ACK.[S]means SYN (new connection),[R]means RST (connection rejected),[F]means FIN (connection closing).length 108— Payload size in bytes.
Why reading flags matters: When you see a flood of [S] packets from one IP to many destination ports, that is a port scan. When you see [R] responses to every [S], the connection was actively refused. Misreading these flags leads to wrong conclusions and wasted troubleshooting time.
Step 3: Learn the Most Useful Tcpdump Command Options
Understanding these flags turns tcpdump from a noisy data firehose into a precise diagnostic tool.
| Option | What It Does | Why You Need It |
|---|---|---|
-i eth0 |
Capture on a named interface | Prevents capturing on the wrong interface on multi-homed servers |
-n |
Disables DNS name resolution | Stops tcpdump from making DNS queries that add noise to your capture |
-nn |
Disables DNS and port name resolution | Shows raw port numbers like 80 instead of http for cleaner parsing |
-v / -vv / -vvv |
Increases output verbosity | Reveals TTL, checksum, IP options hidden in default output |
-c N |
Stops after N packets | Protects disk and CPU on high-traffic servers |
-s 0 |
Captures full packet payload | Default truncates packets; -s 0 ensures no data is cut off |
-A |
Shows payload in ASCII | Lets you read plaintext HTTP, FTP, and SMTP content directly |
-X |
Shows payload in HEX and ASCII | Better for binary protocol debugging |
-D |
Lists all available interfaces | Run this first on any unfamiliar server before capturing |
-w file.pcap |
Writes raw packets to a file | Saves captures for offline analysis in Wireshark |
-r file.pcap |
Reads packets from a saved file | Replays a previous capture with any filter you choose |
Why -s 0 is often forgotten: The default snap length in older tcpdump versions was 68 bytes, which captures headers but cuts off most of the payload. On modern versions the default is 262144 bytes, but explicitly setting -s 0 removes the limit entirely and guarantees you never miss content.
Step 4: Configure Tcpdump Command Filters for Targeted Captures
Filters are where tcpdump goes from useful to powerful. They tell the kernel’s BPF engine exactly which packets to pass through before they ever reach userspace, which keeps your output clean and your system load low.
Filter by Protocol
sudo tcpdump -n icmp
sudo tcpdump -n udp
sudo tcpdump -n tcp
Why this matters: Filtering at the protocol level removes 80% or more of packet noise on a typical server. If you are investigating a DNS problem, you only want UDP port 53 traffic, not the SSH session you are using to run the command.
Filter by Host
# All traffic to or from a specific IP
sudo tcpdump -n host 192.168.1.100
# Only traffic coming FROM that IP
sudo tcpdump -n src host 192.168.1.100
# Only traffic going TO that IP
sudo tcpdump -n dst host 192.168.1.100
Why src and dst matter separately: When you suspect a machine is exfiltrating data, you want src host to see what it is sending outbound. Using plain host shows both directions and doubles your output.
Filter by Port
sudo tcpdump -n port 443
sudo tcpdump -n portrange 8080-8090
sudo tcpdump -n not port 22
Why exclude port 22: When you are running tcpdump over an SSH session, the command captures your own SSH traffic in a feedback loop. Adding not port 22 removes that noise immediately.
Combine Filters with Boolean Logic
sudo tcpdump -n 'src host 192.168.1.10 and tcp port 80'
sudo tcpdump -n 'host 192.168.1.10 and (port 80 or port 443)'
sudo tcpdump -n 'tcp and not port 22 and not port 3306'
Why use single quotes: Bash processes parentheses and special characters before passing the command to tcpdump. Single quotes send the filter expression to the BPF engine raw, exactly as you wrote it. Skipping the quotes causes silent filter failures that are painful to debug.
Step 5: Run Practical Tcpdump Examples with Real-World Use Cases
Linux Server Tutorial: Capture HTTP Traffic and Extract Requests
sudo tcpdump -s 0 -v -n -l -i eth0 port 80 | egrep -i "POST /|GET /|Host:"
Why pipe to egrep: Raw tcpdump output for HTTP traffic is verbose. Piping through egrep filters to only the HTTP request lines, giving you an instant, readable HTTP access log without touching the application itself. This is invaluable when an app’s own logging is broken or missing.
Capture DNS Queries to Diagnose Resolution Failures
sudo tcpdump -i eth0 -s 0 -n port 53
Expected output:
10:12:33.449823 IP 10.0.0.5.42831 > 8.8.8.8.53: A? app.example.com. (32)
10:12:33.461002 IP 8.8.8.8.53 > 10.0.0.5.42831: A app.example.com. 93.184.216.34 (48)
Why this is the fastest DNS debug method: If you see the query leave the server but no response arrives, the DNS server is unreachable or the UDP response is being blocked. If no query appears at all, the application is failing before it even attempts resolution. Each scenario requires a completely different fix.
Capture ICMP to Verify Connectivity at the Packet Level
sudo tcpdump -n icmp
Why use this instead of just ping: The ping command tells you the result. Tcpdump tells you what actually happened at the packet level. If ping times out but tcpdump shows ICMP echo requests leaving the interface, the problem is on the remote end or in a firewall between the two hosts.
Detect a Port Scan in Real Time
sudo tcpdump -nn -c 500 | grep "Flags \[S\]"
Why look for [S] flags: A SYN flood from a single source IP to many different destination ports is the exact packet signature of an Nmap or Masscan port scan. Catching it in tcpdump gives you the source IP for an immediate firewall block.
Capture DHCP Lease Negotiations
sudo tcpdump -v -n port 67 or port 68
Why target ports 67 and 68: DHCP runs over UDP with the server on port 67 and the client on port 68. When a server loses its IP address on reboot, this capture shows the full DISCOVER, OFFER, REQUEST, ACK cycle, including the IP being requested and the server ID granting it.
Step 6: Save Captures to File and Replay Them Later
Write a Capture to a .pcap File
sudo tcpdump -n -i eth0 -s 0 -w /tmp/capture.pcap
Press Ctrl+C to stop the capture. The file is now saved at /tmp/capture.pcap.
Why -w is critical for serious analysis: Live terminal output scrolls too fast to analyze in real time on a busy interface. Writing to a .pcap file captures everything and lets you apply different filters at replay time without running the capture again.
Read and Filter a Saved Capture
sudo tcpdump -r /tmp/capture.pcap -n port 443
sudo tcpdump -r /tmp/capture.pcap -n src host 192.168.1.100
Why apply filters at read time: A single capture file becomes a reusable asset. You can slice it by port, host, or protocol repeatedly without generating new network traffic.
Set Up Rotating Capture Files for Long-Term Monitoring
sudo tcpdump -n -i eth0 -s 0 -W 10 -C 100 -w /var/log/captures/capture.pcap
-W 10— Keep a maximum of 10 files, then overwrite the oldest (ring buffer)-C 100— Rotate to a new file every 100MB
Why use rotation: Without -W and -C, a long-running tcpdump on a busy server can fill your root partition within an hour. Rotation creates a fixed-size sliding window of recent traffic that never exceeds your specified disk limit.
Stream Captures Directly Into Wireshark Over SSH
ssh root@remote-server 'tcpdump -s0 -c 1000 -nn -w - not port 22' | wireshark -k -i -
Why this workflow is a game-changer: Remote servers almost never have a GUI. This command streams raw packets from the remote machine into Wireshark running on your local desktop in real time. You get the headless efficiency of tcpdump with the visual protocol dissection power of Wireshark, all without copying any files.
Troubleshooting: Common Tcpdump Errors and Fixes
Error 1: tcpdump: no suitable device found
Cause: You ran tcpdump without sudo or without specifying a valid interface.
Fix:
sudo tcpdump -D # List available interfaces first
sudo tcpdump -i eth0 # Then specify the correct one
Error 2: tcpdump: eth0: No such device exists
Cause: The interface name on your system is different (common on cloud VMs where interfaces are named ens3, enp0s3, or ens160).
Fix:
ip link show # List all interfaces and their actual names
sudo tcpdump -i ens3 # Use the correct name
Error 3: Capture file is full of truncated packets
Cause: You forgot -s 0, so tcpdump is cutting off packet payloads at the default snaplen.
Fix:
sudo tcpdump -s 0 -i eth0 -w capture.pcap
Error 4: BPF filter syntax error on a complex expression
Cause: Bash is interpreting parentheses in your filter before passing it to tcpdump.
Fix: Wrap the entire filter in single quotes:
sudo tcpdump -n 'host 10.0.0.1 and (port 80 or port 443)'
Error 5: Tcpdump fills the disk on a production server
Cause: Running without a packet count limit (-c) or file rotation (-W, -C) on a high-traffic interface.
Fix: Always use a limit when capturing on production:
sudo tcpdump -c 500 -n -i eth0 -w /tmp/capture.pcap
# or use rotation
sudo tcpdump -W 5 -C 50 -n -i eth0 -w /tmp/cap.pcap