ZNetLab › Published › Blog post
Reading a packet capture without drowning in it
Filter first, read second. A capture you open unfiltered is a capture you will close again.
The first capture anybody opens is forty thousand frames and they close it again. That is the correct reaction — unfiltered, a capture is noise, and the skill is not reading faster but looking at less.
Filter before you read. Not after. Start with the two ends you care about
and nothing else: ip.addr == 10.1.1.5 && ip.addr == 10.2.2.9. If you do not
know both ends yet, start with the protocol: tcp.port == 22, dns, arp.
Then look for the shape, not the bytes. A working TCP session has a distinctive silhouette: SYN, SYN/ACK, ACK, then data. A SYN with no SYN/ACK means nothing is listening or something dropped it. A SYN, SYN/ACK, ACK, then a long pause and retransmissions means the path broke after the handshake — which, if the retransmitted packets are large and the handshake was small, is an MTU problem.
Count the retransmissions. One is normal. A pattern is a fault.
Watch the direction. Half the "the server is not responding" tickets turn out to be the server responding to an address the client never sees, because of a NAT or a route asymmetry. The capture says so instantly if you are looking at both directions and not just one.
Capture on a link in the simulator, export the .pcap, and open it in the analyser you actually use at work. The traffic is real, the file is real, and it is a lot easier to learn a filter syntax on twelve frames you caused than on forty thousand you did not.
Join the discussion
Replies, likes and bookmarks live in the community half, which needs a free account. Writing here is free too, and everything is reviewed before it is published.
Open this in the communityEverything publishedHow this works