28 October 2026

Reading a packet capture without guessing

The most expensive part of a packet capture is not taking it. It's opening it with a theory already in mind and spending an hour confirming it.

Before capturing, I write down one sentence: what would be different in the packets if my theory were true. If the answer is vague, the capture is not worth starting. "It's slow" is not a question. "The client sends the request but the server waits two seconds before the first byte" is.

Then three filters, in this order:

tcp.analysis.flags — retransmissions and zero windows first. If the path is dropping packets, everything else is noise. tcp.flags.syn == 1 and tcp.flags.ack == 0 — did the handshake even complete, and how long did it take. Then Follow TCP Stream on a single slow request, not on the whole connection.

The trap is measuring the wrong interval. A request that takes three seconds end-to-end is often 20 ms of server time and 2.98 s of connection reuse, DNS, or a middlebox doing something creative. Split the interval before blaming a component.

A capture is evidence, not an explanation. The explanation is the sentence you can write afterwards that predicts what the next capture will show.