Reading Your First Packet Capture Without Getting Lost
Opening a capture for the first time is genuinely unpleasant. Thousands of rows scroll past, each one technically relevant, none of them obviously the problem. The skill being tested is not protocol knowledge but the willingness to throw away almost everything you collected.
Decide the question before you capture
"The network is slow" is not a question a capture can answer. "Does the server acknowledge our requests within 200 milliseconds" is. Write the question down, then capture only what could answer it: one host pair, one port, one time window. Guides on this discipline, including those collected at the troubleshooting material on this site, all start from the same place — scope first, tooling second.
A filtering sequence that works
- Filter to the two endpoints in question and nothing else
- Follow a single conversation from setup to teardown
- Look at the handshake, then at retransmissions, then at timing gaps
- Only then read payload contents, if the protocol is unencrypted
Working in that order keeps you from forming a theory too early. Most people jump straight to payload inspection and miss that the connection was resetting twice a minute the whole time.
Signals worth knowing on sight
Duplicate acknowledgements clustered together mean a segment went missing and the receiver is asking for it. A zero window advertisement means the receiving application has stopped reading fast enough — that is a server problem wearing a network costume. Long gaps between a request and its response, with no retransmissions in between, point at processing time rather than transport. Retransmissions on both directions at once usually mean the path itself, not either endpoint.
Capture hygiene
Capture at both ends when you can; a one-sided view cannot distinguish "never sent" from "never arrived". Use a ring buffer with size limits so a long reproduction attempt does not fill the disk. Record the exact clock time you started, because correlating with application logs is where most captures actually earn their value. And write down what you expected to see before you look — being wrong on paper is how the method improves.
Reading Your First Packet Capture Without Getting Lost
Reading Your First Packet Capture Without Getting Lost
Opening a capture for the first time is genuinely unpleasant. Thousands of rows scroll past, each one technically relevant, none of them obviously the problem. The skill being tested is not protocol knowledge but the willingness to throw away almost everything you collected.
Decide the question before you capture
"The network is slow" is not a question a capture can answer. "Does the server acknowledge our requests within 200 milliseconds" is. Write the question down, then capture only what could answer it: one host pair, one port, one time window. Guides on this discipline, including those collected at the troubleshooting material on this site, all start from the same place — scope first, tooling second.
A filtering sequence that works
Working in that order keeps you from forming a theory too early. Most people jump straight to payload inspection and miss that the connection was resetting twice a minute the whole time.
Signals worth knowing on sight
Duplicate acknowledgements clustered together mean a segment went missing and the receiver is asking for it. A zero window advertisement means the receiving application has stopped reading fast enough — that is a server problem wearing a network costume. Long gaps between a request and its response, with no retransmissions in between, point at processing time rather than transport. Retransmissions on both directions at once usually mean the path itself, not either endpoint.
Capture hygiene
Capture at both ends when you can; a one-sided view cannot distinguish "never sent" from "never arrived". Use a ring buffer with size limits so a long reproduction attempt does not fill the disk. Record the exact clock time you started, because correlating with application logs is where most captures actually earn their value. And write down what you expected to see before you look — being wrong on paper is how the method improves.