Skip to content

🔬 02-05: Reading Packets — Wireshark & tcpdump


📌 Why Learn to Read Raw Packets?

Every concept so far — encapsulation, TCP flags, sequence numbers, ports — has been described on paper. Packet capture tools let you actually see this stuff happening on a live network. This is one of the single most important practical skills in network security: you cannot detect, analyze, or defend against an attack you can't recognize in a capture.

Two tools dominate this space:

Tool Interface Best For
tcpdump Command line Servers, containers, remote boxes with no GUI — lightweight and scriptable
Wireshark Graphical Deep visual inspection, following streams, color-coded analysis, teaching/learning

💡 Many practitioners use both: tcpdump to capture traffic on a headless server (saving it to a file), then transfer that file to a desktop and open it in Wireshark for detailed visual analysis.


🖥️ Getting Started with tcpdump

tcpdump captures packets directly from a network interface and prints a summary line per packet (or writes them to a file for later analysis).

Basic Usage

# Capture on interface eth0, don't resolve IPs to hostnames (-n keeps output fast and readable)
sudo tcpdump -n -i eth0

# Add more verbosity (-vvv) and a filter for a specific port
sudo tcpdump -n -i eth0 -vvv "tcp port 179"

# Save captured packets to a file instead of printing them, for later analysis in Wireshark
sudo tcpdump -i eth0 -w /tmp/packets.pcap
  • -i <interface> — which network interface to listen on (e.g., eth0, wlan0)
  • -n — skip DNS reverse lookups on addresses (faster, avoids extra noise/traffic)
  • -w <file> — write raw captured packets to a .pcap file instead of printing a summary
  • -vvv — increase verbosity for more header detail per packet

Filter Examples (BPF Syntax)

tcpdump filters use Berkeley Packet Filter (BPF) syntax — the same filter language Scapy uses for its own sniffing filters:

# Only capture DNS traffic (port 53)
sudo tcpdump -i eth0 port 53

# Only capture traffic to/from a specific host
sudo tcpdump -i eth0 host 10.0.0.5

# Combine conditions: HTTP traffic to a specific host
sudo tcpdump -i eth0 host 10.0.0.5 and port 80

🦈 Getting Started with Wireshark

Wireshark provides the same packet capture capability as tcpdump, but displays every packet in a structured, expandable, color-coded interface — and lets you apply much richer display filters after capturing (as opposed to capture filters, which use BPF syntax and are applied before/during capture).

Wireshark Display Filter Examples

tcp.port == 80              # Show only traffic to/from TCP port 80 (HTTP)
ip.addr == 10.0.0.5          # Show only traffic to/from a specific IP
dns                          # Show only DNS packets
tcp.flags.syn == 1           # Show only segments with the SYN flag set
http.request                 # Show only HTTP request packets

💡 Note the syntax difference: Wireshark's display filters (tcp.port == 80) use a dotted field-name syntax and are far more expressive than tcpdump's capture filters (port 80), because display filters run against packets Wireshark has already fully parsed and stored, not against a live, resource-constrained capture stream.

Reading the Wireshark Window

Wireshark's main view has three stacked panes:

  1. Packet list — one row per captured packet, with a quick summary (source, destination, protocol, info).
  2. Packet details — the selected packet's headers shown as collapsible layers, exactly mirroring the encapsulation stack from 01-03: Frame → Ethernet → IP → TCP/UDP → Application protocol.
  3. Packet bytes — the raw hex/ASCII bytes of the packet, with the currently selected field highlighted.

🕵️ Identifying a TCP Handshake in a Capture

Once you filter to a single conversation (e.g., tcp.port == 443 or host 10.0.0.5), a normal connection setup shows a very recognizable three-packet pattern at the start:

No.   Time     Source        Destination    Protocol   Info
1     0.000    10.0.0.5      93.184.216.34  TCP        51000 → 443 [SYN] Seq=0
2     0.021    93.184.216.34 10.0.0.5       TCP        443 → 51000 [SYN, ACK] Seq=0 Ack=1
3     0.021    10.0.0.5      93.184.216.34  TCP        51000 → 443 [ACK] Seq=1 Ack=1

A practitioner scanning a capture learns to recognize this [SYN][SYN, ACK][ACK] sequence instantly — it's the visual fingerprint of 02-01's three-way handshake actually happening. If you only ever see a lone [SYN] with no reply, that's a strong sign the destination port is closed/filtered, or (in an attack scenario) a sign of a SYN flood in progress.


🔍 Identifying a DNS Query in a Capture

Filtering to dns (Wireshark) or port 53 (tcpdump) isolates DNS traffic. A simple lookup looks like this:

No.   Time     Source        Destination    Protocol   Info
1     0.000    10.0.0.5      8.8.8.8        DNS        Standard query 0x1a2b A example.com
2     0.015    8.8.8.8       10.0.0.5       DNS        Standard query response 0x1a2b A 93.184.216.34

Notice this is UDP, not TCP — there's no handshake before the query, matching what you learned in 02-03: UDP & Connectionless Protocols. A practitioner examining a suspicious capture would check things like:

  • Does the response's transaction ID (0x1a2b) match the query? (Mismatched or unexpected IDs can indicate a spoofed response — see 06-05: DNS Cache Poisoning.)
  • Did multiple responses arrive for a single query? (A strong indicator of a race-condition-based spoofing attempt, like the Kaminsky attack.)
  • Does the source IP of the response actually match a legitimate, expected DNS server?

🧰 Practical Workflow Tips

  • Always filter before you scroll. A busy interface can capture thousands of packets per second; use capture filters (tcpdump) or apply a display filter immediately (Wireshark) rather than scrolling through unfiltered noise.
  • Follow the stream. Wireshark's "Follow → TCP Stream" feature reconstructs the full back-and-forth of one conversation as readable text — invaluable for reading an HTTP request/response pair in full.
  • Save captures for later. A .pcap file is a permanent record — useful for incident response, teaching, or replaying traffic through analysis tools later.
  • Practice on your own traffic first. Capturing your own browser's traffic while you load a familiar site is the fastest way to build pattern recognition before analyzing something unfamiliar or malicious.

📌 Key Takeaways

  • tcpdump is a lightweight, scriptable, command-line capture tool, ideal for servers and containers; Wireshark is a graphical tool ideal for deep visual analysis.
  • tcpdump capture filters and Wireshark capture filters both use BPF syntax (port 53, host 10.0.0.5); Wireshark display filters use a richer dotted syntax (tcp.port == 80, dns).
  • Wireshark's packet details pane mirrors the encapsulation stack directly: Frame → Ethernet → IP → TCP/UDP → Application.
  • A TCP handshake is recognizable in a capture as the [SYN][SYN, ACK][ACK] three-packet pattern.
  • DNS queries appear as UDP traffic on port 53 with no handshake — a lookup is just one query packet and one response packet under normal conditions.
  • Anomalies worth watching for in a DNS capture include mismatched transaction IDs and multiple responses to a single query — both signs of possible spoofing.
  • Filtering aggressively and using "Follow Stream" are the two habits that turn an overwhelming raw capture into something actually readable.