How to diagnose TCP retransmissions from a PCAP

A retransmission is a symptom, not a diagnosis. The useful question is which flow is affected, where the capture was taken, and what happened immediately before the repeated bytes.

1. Find suspected retransmissions

Open the capture in Wireshark and apply this display filter:

tcp.analysis.retransmission || tcp.analysis.fast_retransmission || tcp.analysis.spurious_retransmission

These are analysis fields inferred by Wireshark from the packets visible at the capture point. They are not flags transmitted on the wire. A matching packet means Wireshark saw TCP sequence space that appears to have been sent before.

For a command-line list with the frame number, time, endpoints and sequence number:

tshark -r capture.pcapng \
  -Y "tcp.analysis.retransmission || tcp.analysis.fast_retransmission" \
  -T fields -E header=y \
  -e frame.number -e frame.time_relative \
  -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport \
  -e tcp.seq -e tcp.len

The official TCP display-field reference documents the analysis fields, while the tshark manual explains -r, -Y and field output.

2. Validate one affected conversation

Counts across an entire capture hide the shape of the problem. Select a suspected packet, note its tcp.stream value, then filter to that conversation:

tcp.stream eq 17

Check the packet before the retransmission and the acknowledgements travelling in the opposite direction. Useful signs include:

• Several duplicate ACKs followed quickly by a fast retransmission: consistent with one missing segment while later segments arrived.
• A long pause followed by a retransmission: consistent with the retransmission timeout expiring.
• A retransmission immediately followed by a cumulative ACK: the original or repeated segment may have been delayed rather than permanently lost.
• Many retransmissions across unrelated flows at exactly the same time: investigate capture loss or an overloaded observation point.

Use Analyze → Expert Information for a summary, then Follow → TCP Stream to understand the application impact. The round-trip-time graph and TCP stream graph can reveal whether delay rose before loss.

3. Work out the likely cause

First determine direction. If the repeated data travels from client to server, look for missing ACK progress from the server side; if it travels the other way, reverse the reasoning. Then correlate the event with:

• Rising RTT and bursts of retransmissions: congestion or a saturated queue is plausible.
• Isolated loss with stable RTT: a lossy link, wireless interference or transient forwarding issue is more plausible.
• Out-of-order packets that later fill the gap: multipath reordering may be involved.
• Only one endpoint or VLAN affected: focus on the path unique to it.
• Zero-window advertisements: the receiver is unable to accept more data; this is flow control, not necessarily network loss.

A single capture rarely proves the physical point of loss. It proves what was visible at one observation point. The strongest diagnosis comes from synchronized captures on both sides of the suspected segment.

Manual method vs PCAPNG Analyzer