Reading a packet capture like a repair ticket

2026-05-28

People open a capture the way they open a haunted house: scrolling through packets waiting for something scary to announce itself. That works about as well as fixing a laptop by staring at the motherboard. A capture is a repair ticket. You work it like one: symptom first, then the boring questions, then — and only then — the cause.

Symptom first

Write down, in one sentence, what the capture is supposed to explain. "Page loads are slow on this one machine." "Something talks out at 3 AM." "This app can't reach its server." If you can't write the sentence, you don't have a ticket, you have a fishing trip, and fishing trips in a busy capture last forever. The sentence determines everything you do next: the time window you care about, the host you pivot on, whether you're hunting for an absence (the reply that never came) or a presence (the connection that shouldn't exist).

The boring questions

On the bench you check the power supply before you reflow anything, because it's free and it's the answer a third of the time. Captures have the same checklist, and it's deliberately dull:

Does the conversation start? Filter to one flow and look at the handshake. SYN with no SYN-ACK is a completely different ticket (routing, firewall, dead host) than a handshake that completes and then goes sideways (application). Half of all "network problems" are resolved at this line.
Does the name resolve, and to what? Look at the DNS before the connection. Slow answers, failed lookups, or a resolver you don't recognize answering at all — each one redirects the investigation. DNS is the power supply of network problems.
Who hangs up, and how? A polite FIN from the far end, a RST in the middle of a transfer, or a connection that just goes silent until retransmissions give up — three different stories. RSTs arriving suspiciously fast, faster than the round-trip to the real server could possibly be, mean something in the middle is talking over the line.
What do the retransmissions say? Retransmissions and duplicate ACKs are the network coughing. A few are weather. A pattern — always one direction, always one path, always above a certain packet size — is a diagnosis. Always-one-size points at MTU; the big packet leaves and nothing comes back.
Do the timestamps agree with the complaint? "It's slow" should be visible as a gap. Find the gap. Is the silence between the request and the first byte of the answer (their side), or between packets you sent (your side)? The gap has an owner. Your job is to read the deed.

Then the cause

Notice what hasn't happened yet: no deep protocol analysis, no decoding, no heroics. Most tickets die in the boring questions. The ones that survive have now been narrowed from "the network is broken" to something like "this host's HTTPS to this address completes a handshake and then stalls exactly 60 seconds before the far side resets." That sentence practically closes itself — a 60-second stall ending in a reset is an idle timeout on some middlebox with opinions.

Round numbers are confessions. Failures at exactly 30, 60, 300 seconds are timeouts. Sizes failing at exactly some threshold are MTU or a buffer. Things breaking at the top of the hour are a scheduled job. Nature doesn't do round numbers; configuration files do.

The part nobody does

Take a capture of the same traffic when it works. On the bench you'd never diagnose a noise without knowing what the machine sounds like healthy, but people will stare at a sick capture for hours without once looking at a healthy one. The diff is the diagnosis. The working capture turns "is this normal?" — the question that eats the whole afternoon — into a question with an answer.

Last thing, and it's the same speech I gave at the counter: the capture tells you what happened, not who to be mad at. Symptom, boring questions, cause, fix. Write down what it was when you're done. The next ticket is the same ticket; the only question is whether you'll recognize it.

leadline / TG-8191

index · last touched 2026-05-28