Using tcpdump and Wireshark to Effectively Analyze Network Traffic – ITFROMZERO

Table of Contents

Up and Running in 5 Minutes

Got a network issue on your server and not sure what traffic is flowing? Open a terminal and run this:

# Capture all traffic on interface eth0
sudo tcpdump -i eth0

# View only HTTP (port 80) and HTTPS (port 443) traffic
sudo tcpdump -i eth0 'port 80 or port 443'

# Save to file to open in Wireshark later
sudo tcpdump -i eth0 -w /tmp/capture.pcap

Those three commands are enough to see what traffic is passing through your server. The filtering and analysis is where you’ll spend most of your time — and it’s also the most interesting part.

tcpdump — Your Go-To Weapon on Headless Servers

Installation

# Ubuntu/Debian
sudo apt install tcpdump -y

# CentOS/RHEL
sudo yum install tcpdump -y

# List available interfaces
sudo tcpdump -D

The Most Commonly Used Filters

tcpdump uses Berkeley Packet Filter (BPF) syntax — it looks strange at first, but 10 minutes is all you need to memorize the ones you’ll use most:

# Filter by host (both src and dst)
sudo tcpdump -i eth0 host 192.168.1.100

# View traffic from a specific IP only
sudo tcpdump -i eth0 src host 192.168.1.100

# View traffic to a specific IP only
sudo tcpdump -i eth0 dst host 192.168.1.100

# Filter by subnet
sudo tcpdump -i eth0 net 192.168.1.0/24

# Combine multiple conditions
sudo tcpdump -i eth0 'host 192.168.1.100 and port 443'

# Exclude SSH to reduce noise
sudo tcpdump -i eth0 'not port 22'

Wireshark — When You Need to Dig Deeper

tcpdump captures, Wireshark analyzes. My go-to workflow: capture on the headless server using tcpdump, copy the pcap file to my local machine, then open Wireshark. This separation keeps the server from burning resources on a GUI while giving me a comfortable interface to work in.

Capture on the Server, Analyze Locally

# On server: capture for 60 seconds, save file
sudo tcpdump -i eth0 -w /tmp/capture_$(date +%Y%m%d_%H%M%S).pcap -G 60 -W 1

# Copy to local machine
scp user@server:/tmp/capture_*.pcap ~/Desktop/

Open the pcap file in Wireshark and use Display Filters to narrow things down:

# Filter in Wireshark (Display Filter bar)
http                          # HTTP only
tcp.port == 443               # HTTPS
ip.addr == 192.168.1.100      # By IP
tcp.flags.syn == 1            # SYN packets only
http.response.code == 500     # HTTP 500 errors
dns                           # DNS queries only

Wireshark Features You Can’t Afford to Miss

Follow TCP Stream: Right-click a packet → Follow → TCP Stream. Wireshark reassembles the entire client-server conversation into a single readable view. Using this for HTTP debugging alone can save you hours.
Statistics → Conversations: One glance tells you which IPs are consuming the most bandwidth — invaluable when dealing with a small DDoS or a rogue process pulling unusual amounts of data.
Statistics → IO Graph: A traffic chart over time. Far easier to spot anomalous spikes than reading through log lines one by one.
Analyze → Expert Information: Wireshark automatically highlights TCP retransmissions, connection resets, and window size issues — no need to know any filters, just open this panel to see all problems at a glance.

Real-World Debugging: Intermittent Packet Loss

The toughest debug I’ve ever dealt with was intermittent packet loss that only happened between 8 and 9 PM. Daytime pings were fine. During peak hours, certain connections would start lagging. Running ping -i 0.2 -c 500 showed a loss rate of only 0.3–0.5% — enough for users to notice lag, but too low for basic tcpdump to catch anything useful.

The approach:

# Continuous capture, rotate file every 5 minutes, keep max 24 files (2 hours)
sudo tcpdump -i eth0 -w /tmp/capture_%H%M.pcap -G 300 -W 24 \
  'not port 22 and not arp'

# Script running in parallel to detect packet loss
ping -i 0.2 -c 1000 192.168.1.1 | grep -E 'packet loss|time='

With a pcap file captured during the exact window when the problem occurred, I opened Wireshark and filtered:

# Find TCP retransmissions
tcp.analysis.retransmission

# Find duplicate ACKs (sign of packet loss)
tcp.analysis.duplicate_ack

# Find all TCP issues
tcp.analysis.flags

The results were clear: the retransmission rate jumped from under 1% to 13–15% right when traffic spiked. Tracing back by timestamp, I found that a switch in the network was dropping packets when its buffer filled up. Not the server, not the application — the switch. Without Wireshark, I’d probably have spent days more chasing ghosts.

Advanced: Remote Capture Over SSH

Don’t want to store files on the server? Pipe directly over SSH to Wireshark on your local machine:

# On macOS/Linux, open local Wireshark and capture from a remote server
ssh user@server 'sudo tcpdump -i eth0 -nn -w - not port 22' | wireshark -k -i -

# Or use tshark (CLI version of Wireshark) to analyze directly on the server
sudo tshark -i eth0 -Y 'http.response.code >= 400' \
  -T fields -e ip.src -e http.response.code -e http.request.uri

Automated HTTP Error Analysis with tshark

# Export HTTP requests to CSV for analysis
sudo tshark -r /tmp/capture.pcap \
  -Y 'http.request' \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e http.request.method \
  -e http.request.uri \
  -E header=y \
  -E separator=, \
  > /tmp/http_requests.csv

# Count requests by method
sudo tshark -r /tmp/capture.pcap \
  -Y 'http.request' \
  -T fields -e http.request.method | sort | uniq -c | sort -rn

Practical Tips from Experience

1. Limit capture size to avoid filling your disk:

# Limit to 100MB, rotate across 5 files
sudo tcpdump -i eth0 -w /tmp/cap.pcap -C 100 -W 5

2. Capture headers only, not payload — saves space while retaining enough data for TCP analysis:

# -s 96: capture only first 96 bytes per packet
sudo tcpdump -i eth0 -s 96 -w /tmp/headers_only.pcap

3. Capture on multiple interfaces simultaneously:

# Use 'any' to capture all interfaces
sudo tcpdump -i any -nn -w /tmp/all_interfaces.pcap

4. Quick latency analysis with tshark:

# View TCP connection setup time (SYN → SYN-ACK)
sudo tshark -r /tmp/capture.pcap \
  -Y 'tcp.flags.syn==1 and tcp.flags.ack==1' \
  -T fields -e ip.src -e ip.dst -e tcp.time_delta

5. Servers using NIC offloading (checksum offload) will often trigger “bad checksum” warnings in tcpdump — these are false positives, not real errors. Suppress the warning to reduce noise:

sudo tcpdump -i eth0 --no-promiscuous-mode -K 'port 80'

Learn these two tools once, use them for life. tcpdump runs on any Linux server without extra dependencies or a GUI. Wireshark turns raw packets into something humans can actually read. Together, there’s virtually no network problem that can stay hidden for long.