// networking basics — module 05

Module 5 — Reading Traffic: tcpdump & Wireshark

Soren Brumbach · · 9 min read

Thesis: You can't attack or defend traffic you can't read. This is the module that turns three modules of networking theory into something you can see with your own eyes. Packet analysis is the ground truth of networking: when documentation and reality disagree, the capture is right. After this module, "the three-way handshake" isn't a diagram you memorized — it's three highlighted lines you can point to.

Prerequisite: Module 4 — Networking III: The Protocols You'll Live In (and DNS in Depth) and everything before it. This module is where Modules 2, 3, and 4 stop being abstract — you'll find each of their concepts inside real packets.

5.1 Why packet analysis is the ground truth

Every other source of information about a network is a summary: a log says "connection from X," a tool says "port open," a dashboard says "traffic normal." A packet capture is none of those — it's the unfiltered, byte-for-byte record of what actually crossed the wire. No assumptions, no interpretation, no software deciding what's worth mentioning. When you're confused about what's happening, the capture is the court of final appeal. Learning to read one is the highest-leverage skill in this entire course, which is exactly why networking comes before everything else.

5.2 Capturing traffic — the mechanics and the ethics

To capture, software puts a network interface into a mode where it hands up copies of packets. A few concepts:

  • Which interface — you capture on a specific NIC (eth0, wlan0, or a virtual lab interface). You only see traffic that reaches that interface.
  • Promiscuous mode — normally a NIC ignores frames not addressed to its MAC. In promiscuous mode it grabs everything it can see on the segment, not just its own traffic. On a modern switched network a machine mostly only sees its own traffic anyway (switches forward frames only to the right port) — which is why serious capture happens at a deliberate vantage point:
  • Where to capture — on the host itself (its own traffic), or at a network tap or a switch SPAN/mirror port that copies all traffic to a monitoring port. In your lab, you capture on the attacker box or on a target.
  • The ethics, again — capturing traffic means reading other people's data. Do it only in your own lab or where you're authorized (Module 0, §0.7). Sniffing a network you don't own is exactly the kind of unauthorized access that rule forbids.

5.3 tcpdump — the command-line workhorse

tcpdump is the no-frills, everywhere-available capture tool. It runs on servers with no GUI, and it's how you grab traffic on a remote box. The essentials:

  • Pick an interface: tcpdump -i eth0. List interfaces with tcpdump -D.
  • Read the terse output: each line is one packet — timestamp, source → destination, protocol, flags, sequence numbers. Dense, but it's all Modules 2–4 vocabulary.
  • Write a capture to a file: tcpdump -i eth0 -w capture.pcap saves raw packets to a .pcap file you can open later in Wireshark. -r capture.pcap reads one back.
  • Useful flags: -n (don't resolve names/ports to slow DNS lookups — show raw numbers), -c 100 (stop after 100 packets), -v/-vv (more detail).

BPF capture filters

You rarely want all traffic. BPF (Berkeley Packet Filter) syntax tells tcpdump what to capture. The building blocks compose with and, or, not:

  tcpdump -i eth0 host 192.168.1.10           # only to/from that host
  tcpdump -i eth0 port 53                       # only DNS
  tcpdump -i eth0 tcp                            # only TCP
  tcpdump -i eth0 'tcp port 80 and host 10.0.0.5'   # HTTP to/from one host
  tcpdump -i eth0 'udp and not port 53'         # UDP except DNS

Because this filter is applied before capture, packets that don't match are never recorded at all — which matters for the crucial distinction in §5.5.

5.4 Wireshark — the graphical powerhouse

Wireshark is tcpdump's graphical sibling: it captures the same packets but dissects them into a readable, clickable tree. Its window has three panes, and understanding them is most of the skill:

 ┌──────────────────────────────────────────────────────────┐
 │  PACKET LIST — one row per packet: #, time, src, dst,     │
 │  protocol, info. Click a row to inspect it.               │
 ├──────────────────────────────────────────────────────────┤
 │  PACKET DETAILS — the selected packet's nested headers,   │
 │  as an expandable tree:                                   │
 │    ▸ Frame                                                │
 │    ▸ Ethernet II   (Layer 2 — MAC addresses)              │
 │    ▸ Internet Protocol   (Layer 3 — IP addresses)         │
 │    ▸ Transmission Control Protocol  (Layer 4 — ports,     │
 │        flags, seq/ack)                                    │
 │    ▸ Hypertext Transfer Protocol  (Layer 7 — the data)    │
 ├──────────────────────────────────────────────────────────┤
 │  PACKET BYTES — the raw hex and ASCII of the packet.      │
 └──────────────────────────────────────────────────────────┘

Stop and appreciate the details pane: that expandable tree of nested headers is encapsulation from Module 2, §2.4, made visible. The onion, unwrapped, layer by layer, for a real packet. This is the moment the abstraction becomes concrete — expand each layer and you are literally peeling the packet.

Two more indispensable features:

  • Follow Stream — right-click a packet → Follow → TCP/HTTP Stream reassembles an entire conversation (all the scattered packets of one connection) into a single readable transcript. This is how you read a whole HTTP exchange or spot a plaintext login instantly.
  • Statistics — Statistics → Protocol Hierarchy (what protocols are present and in what proportion) and Conversations (who talked to whom, how much). A fast way to get oriented in an unfamiliar capture: "who are the top talkers?"

Wireshark also shows Expert Info (flagged anomalies like retransmissions and resets) and coloring rules (bad packets in red/black), both of which draw your eye to what's interesting.

5.5 Capture filters vs. display filters — the #1 beginner trap

Wireshark has two kinds of filter, they use different syntax, and confusing them is the most common beginner mistake. Get this crystal clear:

  • Capture filter — decides what to record. Applied before capture (it's BPF syntax, same as tcpdump: host 10.0.0.5, port 80). Anything it excludes is gone forever — never written down. You use it to keep captures small and focused.
  • Display filter — decides what to show from what you already recorded. Applied after capture, and changeable anytime without losing data (Wireshark's own richer syntax: http, dns, ip.addr == 10.0.0.5, tcp.flags.syn == 1). You use it to explore a capture you already have.
   [ all traffic ] ──capture filter──► [ what's recorded ] ──display filter──► [ what you see ]
                     (before, permanent)                     (after, reversible)

The rule of thumb: capture broadly, display narrowly. It's usually safer to capture more than you think you need (you can't display what you didn't record) and then use display filters to zero in. Say this distinction out loud until it's automatic.

Common display filters worth knowing: http, dns, tcp.port == 443, ip.addr == 192.168.1.10, tcp.flags.syn == 1 && tcp.flags.ack == 0 (SYN-only — the start of handshakes and the fingerprint of a SYN scan).

5.6 Reading real things — tie every earlier module to reality

This is the point of the whole module. In your captures, find and identify each of these:

  • The three-way handshake (Module 3). Filter for one connection and spot the SYN, then SYN/ACK, then ACK — three consecutive packets. Confirm the flags in the details pane. The diagram you drew from memory is now on your screen.
  • A DNS query and response (Module 4). Filter dns. Find the query (name + record type) and the matching response (the answer). One question, one answer, on port 53.
  • An HTTP request/response (Module 4/6). Filter http, follow the stream, and read the method, path, headers, status code, and body in plain text.
  • A plaintext login. Capture a login over an unencrypted protocol (HTTP form, Telnet, or FTP) in your lab and watch the username and password appear in clear text. This is the visceral proof of §4.8 — do it once and you'll never trust a plaintext protocol again.
  • ARP (Module 2). Filter arp and watch the "who has this IP? / it's at this MAC" exchange from §2.7.
  • Trouble signs. Learn to recognize retransmissions (TCP resending lost data), RST floods, and scan patterns (one host hitting many ports, lots of lone SYNs).

5.7 Extracting artifacts

A capture doesn't just show that a file crossed the wire — over an unencrypted protocol, Wireshark can reassemble and save the file itself (File → Export Objects → HTTP, for example). Images, documents, and executables can be pulled straight out of a capture. This is central to both incident response (recovering what an attacker downloaded) and interception (grabbing what crossed the wire).

5.8 → Red/Blue

Identical tool, identical skill, opposite intent. Attackers sniff traffic to steal plaintext credentials and secrets, map a network by watching who talks to whom, and craft or inspect packets to understand and manipulate a target. Defenders live inside packet captures during incident response — reconstructing exactly what happened, extracting the malware or the exfiltrated file, and using the capture to build and validate detections. When an alert fires, the pcap is the ground truth that confirms or refutes it. The exact same three panes serve both.

Lab 5

This is the most important hands-on module so far. Do all of it, in your lab.

  1. Capture your own web request. Start a capture, browse to an HTTP (not HTTPS) test site, stop the capture. Using the display filter http, find your own request and read its method and path.

  2. Read a DNS lookup. Capture while you run dig or load a page. Filter dns, find your query, and identify the query name, the record type, and the answer in the response.

  3. Confirm the handshake, in order. Isolate a single TCP connection (click one packet → Follow TCP Stream, or filter on one port pair). Confirm you can see, in order: the SYN / SYN-ACK / ACK handshake, the data, and the FIN/ACK (or RST) teardown. Point at each. Compare to the drawing you made in Module 3.

  4. Prove the filter distinction. Do the same capture twice: once using a capture filter (port 80) so only that traffic is recorded, and once capturing everything and using a display filter (http) to show only that traffic. Then articulate out loud the difference — and why you can widen the display filter afterward but can't recover what a capture filter threw away.

  5. See plaintext danger. In your lab, log into an unencrypted service (an HTTP login form, FTP, or Telnet). In the capture, find the username and password in clear text. Sit with that.

  6. Investigate a mystery pcap. Get a pre-made practice .pcap (plenty exist for training) and answer, using only the capture: who talked to whom, over what protocol, and what was transferred? Use Statistics → Conversations to orient, then drill in.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. Why is a packet capture the "ground truth" of a network, above logs and tools?
  2. What is promiscuous mode, and why does a SPAN port or tap matter on a switched network?
  3. What are Wireshark's three panes, and which one is encapsulation made visible?
  4. Explain the difference between a capture filter and a display filter — when each is applied, which is reversible, and why "capture broadly, display narrowly" is the rule.
  5. What does "Follow TCP Stream" do and why is it useful?
  6. Write a display filter that shows only DNS, and one that shows only SYN-only packets.

And perform cold:

  • Capture live traffic, then find and point to the three-way handshake, a DNS query/response, and an HTTP request in it.
  • Capture a plaintext login and extract the credentials from the capture.

When all of that is effortless: Module 6 — How the Web Works (Because Everything Is Web Now)