Tcpdump Command in Linux with Examples

Tcpdump Command in Linux

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 sudo privileges (tcpdump requires raw socket access)
  • Network Interface: At least one active network interface (run ip link to confirm)
  • Terminal Access: Direct console or SSH session with a stable connection
  • Optional Tools: Wireshark installed locally if you plan to analyze .pcap capture 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]
  • options change how tcpdump behaves (which interface to use, how verbose to be, whether to save to file)
  • filter expression is 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 see IP6, 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. P is 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

VPS Manage Service Offer
If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal!
r00t is a dedicated and highly skilled Linux Systems Administrator with over a decade of progressive experience in designing, deploying, and maintaining enterprise-grade Linux infrastructure. His professional journey began in the telecommunications industry, where early exposure to Unix-based operating systems ignited a deep and enduring passion for open-source technologies and server administration.​ Throughout his career, r00t has demonstrated exceptional proficiency in managing large-scale Linux environments, overseeing more than 300 servers across development, staging, and production platforms while consistently achieving 99.9% system uptime. He holds advanced competencies in Red Hat Enterprise Linux (RHEL), Debian, and Ubuntu distributions, complemented by hands-on expertise in automation tools such as Ansible, Terraform, Bash scripting, and Python.

Related Posts