After enough captures, the same shapes appear. Five patterns account for most connectivity complaints, and each one points at a different part of the system. Learn the shapes and you can triage a capture in under a minute instead of scrolling.
The table
| Pattern | Looks like | Usually means |
|---|---|---|
| Retransmissions | Same sequence number resent, spaced 1/3/7 s | Loss, congestion, or a duplex mismatch |
| Zero window | Receiver advertises window 0, sender waits | Receiver is slow: disk, CPU, or application |
| Reset after SYN | RST returned immediately | Port closed, or a policy that rejects |
| One-way traffic | Only one direction present in the capture | Asymmetric path or wrong capture point |
| Name delay | 2–5 s pause before the first SYN | DNS timeout or retry |
1. Retransmissions
seq 1 10:00:01.000 client → server 1460 bytes
seq 1 10:00:02.010 retransmission
seq 1 10:00:05.030 retransmission
The sender believes the segment was lost. Two possibilities: it was lost on the path, or the acknowledgement was lost.
- Loss in both directions → a congested or faulty link.
- Loss in one direction only → a duplex mismatch, a bad cable, or a one-way policy.
- Retransmissions clustered at one time of day → capacity, not failure.
Check the link: errors, discards, and duplex. A 100 Mbps link negotiated to half duplex produces exactly this pattern, and it is invisible in throughput graphs.
2. Zero window
server → client Window 0, ACK
client → server Window update, 0
(30 s of nothing)
The network delivered the data. The receiver cannot accept more because its buffer is full — usually an application not reading fast enough, a disk that cannot keep up, or a host under memory pressure.
This is not a network problem, and no amount of bandwidth will fix it. The fix is on the host: check CPU, disk latency, and the application's threading.
3. Reset after SYN
client → server SYN
server → client RST, ACK
Fast and explicit. The port is closed, or a firewall is configured to reject. Compare with a silent timeout, which means drop. The difference tells you whether the policy is "deny and tell" or "deny and hide," and that is a design decision someone made.
4. One-way traffic
A capture showing only the client's packets is not evidence that the server said nothing. It may be that the capture point only sees one direction — a mirror configured on one side of a link, or a routing asymmetry.
Confirm with a second capture point before concluding the server is silent. This mistake has produced more false "the server is down" conclusions than any other.
5. Name delay
10:00:00.000 DNS query
10:00:02.000 DNS query (retry, new ID)
10:00:04.010 DNS response
10:00:04.015 SYN
The application was not slow. It waited four seconds for a name. The DNS retry pattern — same question, new transaction ID — is the fingerprint of a resolver that did not answer the first time.
Look for: which resolver, whether the first query left, and whether a second resolver answered. In a district this is usually a forwarder problem or a resolver that is reachable from one VLAN and not another.
Worked example: three tickets, three patterns
| Ticket | Capture shows | Cause | Fix |
|---|---|---|---|
| "Gradebook is slow" | Retransmits on one direction, link errors climbing | Duplex mismatch on a 100 Mbps port | Fix speed/duplex |
| "File copy stalls" | Zero window from the server | Disk latency on the file server | Storage, not network |
| "Login takes 5 s" | DNS retry before every SYN | One DC not answering | Resolver health |
None of the three was solved by adding bandwidth, and each was solved in under ten minutes once the pattern was named.
Capture first, theory second
The temptation is to form a theory from the ticket text ("it's the firewall") and then look for evidence. The pattern method is the reverse: capture, classify, then investigate the class. It is faster because it does not depend on the ticket being right.
What breaks in production
- Treating retransmissions as proof of loss without checking both directions.
- Blaming the network for a zero window. The receiver is the problem.
- Reading a one-sided capture as a one-sided conversation.
- Missing DNS because the filter only looked at TCP.
- Ignoring timestamps, so a five-second DNS delay looks like a fast page load.
Checklist
- You classify the capture into one of the five patterns before theorizing.
- Retransmissions are checked in both directions.
- Zero window sends you to the host, not the switch.
- Reset versus timeout is treated as a policy distinction.
- DNS timing is measured before the first SYN.
- Two capture points are used whenever the traffic looks one-way.
Next
Captures tell you what happened once. The next series makes the network tell you continuously: Monitoring and Observability.