From symptoms to the actual bytes
The earlier guides in this rung handed you two flashlights. Ping tells you whether a host answers and how long the round trip takes; traceroute sketches the path by abusing the TTL. Both are forms of active measurement: you inject probe traffic and watch what bounces back. They are wonderful for the question "is it up, and how far?", but they answer in summaries. When the real complaint is "the page loads but it stalls halfway", a summary is not enough. You need to read the conversation itself.
That is what packet capture does. Instead of sending probes, it quietly copies every frame that crosses an interface and hands you a faithful transcript: the real packets, with every header and byte your machine actually sent or received. This is pure passive measurement — you add no traffic of your own, you just listen. The tool that records is tcpdump (a small command-line capture engine) or a graphical capture; the tool that decodes and lets you read it is Wireshark. Think of packet capture as a wiretap on your own line, recording the calls so you can play them back in slow motion.
Why a capture is layered, just like the network
Open one captured packet in Wireshark and the single most useful thing you will see is that it unfolds into a stack of expandable rows. This is not a coincidence — it is encapsulation from the foundations rung, finally made visible. Each layer wrapped the one above it in its own header, like nested envelopes, and Wireshark simply peels them back in order. The bytes never changed; the tool is just reading the labels at each layer for you.
ONE PACKET, AS WIRESHARK UNFOLDS IT
-----------------------------------------------------------
Frame 42: 74 bytes captured <- capture metadata (time, length)
Ethernet II src a4:.. dst 3c:.. type IPv4 <- link layer (MAC addresses)
IPv4 src 192.168.1.10 dst 93.184.216.34 <- network layer (IP addresses)
TCP src port 51514 dst port 443 <- transport layer (ports)
[SYN] seq=0 win=64240
(no payload yet -- this is just the handshake opening)
outermost header read first -> innermost payload last
Reading top to bottom, the outermost layer is the link-layer frame with MAC addresses (who is the next hop on this wire), then the IP header with source and destination addresses (where in the whole Internet), then the TCP segment with port numbers (which program on each end). The port is the apartment number after the street address. The deeper you click, the more specific the question it answers: the same packet tells you the hop, the host, and the program, all at once, because every layer left its own header behind.
Filters: capturing everything is a mistake
A busy machine can send and receive tens of thousands of packets a second. Capture all of them and you will drown — your disk fills, the tool lags, and the one exchange you care about is a needle in a haystack of unrelated chatter. The skill that separates a frustrating capture from a useful one is filtering, and it comes in two distinct flavours that beginners constantly confuse.
The first is the capture filter, the famous BPF filter (Berkeley Packet Filter). It decides which packets get recorded at all, applied down in the kernel before the data is ever copied to your tool — so it is cheap and it permanently throws away whatever does not match. The syntax is terse and host/port oriented: "tcp port 443", "host 93.184.216.34", "udp port 53 and not src net 10.0.0.0/8". Use a capture filter when you already know roughly what you want and the link is too busy to record everything.
The second is the display filter, which Wireshark applies after the fact to a capture you already have. It is far richer because by then every field has been decoded: you can write "http.response.code == 404", "tcp.flags.syn == 1 && tcp.flags.ack == 0" to find connection openings, or "tcp.analysis.retransmission" to surface only the packets Wireshark thinks were re-sent. The rule of thumb: a capture filter (BPF) limits what you record and you cannot get it back; a display filter only hides rows and you can change it freely. When in doubt, capture a little wider with BPF, then narrow with display filters.
Following one conversation end to end
A single TCP connection is scattered through a capture, its packets interleaved with hundreds of others. Wireshark's most-loved feature, Follow TCP Stream, gathers just the packets of one connection, reassembles the byte stream in order, and shows you the actual conversation — the HTTP request you sent and the reply that came back, in readable text. This is where the layered transcript pays off: you stop looking at isolated packets and start reading a dialogue.
- Start the capture (with a BPF filter like "host example.com" if the link is busy), then do the thing that misbehaves — load the page, send the message — and stop.
- Apply a display filter to find the connection, e.g. "tcp.port == 443", and look for the opening SYN.
- Confirm the three-way handshake: SYN, then SYN-ACK, then ACK. If you never see the SYN-ACK come back, the problem is reaching the server at all — a routing, firewall, or DNS issue, not the app.
- Right-click any packet in the connection and choose Follow TCP Stream to read the request and reply as plain text.
- Scan for trouble: retransmissions and duplicate ACKs mean loss; a long gap between a request and its reply is the server thinking; a connection reset (RST) means one side hung up abruptly.
Notice how much this narrows the question. If the handshake completes instantly but the reply takes two seconds, the network is fine and the server is slow. If you see the request go out and then a flurry of retransmissions before the reply, the path is dropping packets and TCP is recovering. The capture does not just say "slow"; it points a finger. That talent — turning a vague complaint into a specific layer and a specific cause — is exactly what the last guide in this rung builds on.
What capture cannot see — and what to do instead
Packet capture is powerful, but be honest about its limits. The biggest one: encryption. Recall that TCP is reliable but not secure and encrypts nothing by itself — TLS does. So when you follow a stream to an HTTPS server you can read the three-way handshake, the IP addresses, the ports, the packet sizes and timing, and the TLS setup. But the actual HTTP request and reply are ciphertext. You can see that a conversation happened and how big and how fast it was, but not what was said, unless you have the session keys. Capture sees the envelopes, not the letter inside an encrypted one.
Capture also does not scale. A full transcript of one machine for one minute is fine; a full transcript of every link in a datacenter is absurd — the recording would be larger than the traffic itself. This is exactly the gap that the first guide drew between deep-but-narrow and broad-but-shallow. For network-wide visibility you summarize instead of transcribe: flow records like NetFlow and sFlow keep one small line per conversation (who talked to whom, on which ports, how many bytes and packets) instead of every byte, and SNMP polls counters off each device. That whole world of always-on summaries is network telemetry, and observability is the art of asking questions of it after the fact.
One last honesty, less technical but no less important: watching other people's traffic is not a neutral act. Even when you have the technical access, a capture can hold passwords, personal data and private messages, and recording it may break the law or a workplace policy. The honest rule is simple — capture your own traffic, or traffic you are explicitly authorized to inspect, and handle the saved file like the sensitive recording it is.