TCP Spurious Retransmissions in Wireshark
Oliver Ripka
Wireshark's tcp.analysis.spurious_retransmission label means the segment looks unnecessary from the packets available in this capture. It is a useful lead, but it is not proof that the sender retransmitted data needlessly or that the network is faulty.
The first question is therefore not “how many spurious retransmissions are there?” It is: did the sender have evidence that this data was already acknowledged when it retransmitted it? The answer requires sequence numbers, ACK or SACK evidence, timing, capture location, and a complete-enough view of both directions.
What Wireshark is telling you
Display suspected cases with:
tcp.analysis.spurious_retransmission
Wireshark tracks TCP sequence space within the capture. It may apply this label when retransmitted bytes appear to have been acknowledged already. That judgment is based on the trace Wireshark can see, not on the sender's internal TCP state.
This distinction matters because a capture can omit the ACK that reached the sender, omit the original data segment, start after the connection began, or observe asymmetric paths. Packet reordering and capture-interface drops can also make a valid recovery sequence look contradictory.
Common explanations
| Explanation | Evidence you would expect | What does not prove it |
|---|---|---|
| Delayed or lost ACK | Original data is visible; the sender's retransmission timer expires before an ACK reaches it | A retransmission label alone |
| ACK reached sender but capture timing/path is misleading | ACK is visible at one observation point, but topology or timestamp evidence shows the sender may have seen events in another order | Packet-list order without checking capture points and clocks |
| Packet reordering | Sequence gaps fill quickly; duplicate ACK/SACK behavior is consistent with later arrival | A single out-of-order flag |
| Capture loss or incomplete capture | tcp.analysis.ack_lost_segment, missing sequence ranges, interface drops, or only one direction is present | Assuming every missing frame was lost on the production network |
| Sender/network defect | Repeated pattern across comparable streams and a capture close to the sender; endpoints and timing rule out capture artifacts | A count of “bad TCP” expert-info events |
A defensible diagnosis workflow
1. Isolate one TCP stream
Start with one affected connection rather than an aggregate count:
tcp.stream == 42
Record the capture location and whether both directions are visible. If the capture begins midstream or shows missing sequence space, lower your confidence immediately.
2. Find the original bytes and the retransmission
Compare tcp.seq, tcp.len, and the acknowledgment history. Wireshark exposes useful calculated fields including:
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.spurious_retransmission
tcp.analysis.rto
tcp.analysis.rto_frame
tcp.analysis.ack_rtt
tcp.analysis.rto and tcp.analysis.rto_frame help connect a timeout-driven retransmission to the earlier segment. They do not reveal a fixed RTO negotiated in the handshake. TCP does not negotiate an RTO option there.
3. Inspect ACK and SACK evidence
Determine what the receiver cumulatively acknowledged and whether SACK blocks identify bytes received beyond a gap. Duplicate ACKs and SACKs can explain why a sender retransmitted, but they can also be consequences of reordering. Follow the sequence rather than treating either as the cause.
4. Compare the elapsed time
A long interval tied to tcp.analysis.rto_frame suggests timer-based recovery. A rapid retransmission following duplicate ACKs is more consistent with fast retransmit. Compare tcp.analysis.ack_rtt across healthy and affected streams; one slow sample is weaker than a repeated shift in the same path and workload.
5. Challenge the capture
Check for:
tcp.analysis.ack_lost_segmentor sequence ranges never observed- interface or capture-tool drop counters
- hardware timestamping differences
- asymmetric routing or SPAN oversubscription
- offload effects when capturing on an endpoint
- a capture that starts after the TCP handshake
If the trace cannot establish what the sender received and when, report the retransmission as suspected, not proven.
6. Correlate with user impact
A retransmission matters when it explains delay, throughput collapse, an application timeout, or a failed transaction. Check whether the event aligns with a flat section in the TCP time-sequence graph, a rising RTT, a recovery burst, or a visible application stall. See the TCP performance-analysis workflow for the wider investigation pattern.
Example conclusion language
A strong finding separates observation, interpretation, and uncertainty:
Stream 42 retransmits bytes 186721–188180 after the calculated RTO. The original segment is visible, no covering ACK is observed before the retry, and the retransmission aligns with the transfer stall. Because the capture was taken at the server and reports no local drops, delayed or lost reverse-path acknowledgment is better supported than a capture artifact. The trace does not identify the device that discarded or delayed the ACK.
That is more useful than “Wireshark found 37 spurious retransmissions.” It tells another operator exactly what to verify.
When to escalate beyond one stream
After validating the pattern, compare affected and successful baselines by endpoint, path, time window, TCP options, RTT, and application outcome. Repetition across comparable flows increases confidence; broad counts without baselines often mix unrelated causes.
For your own capture, the PacketSafari AI PCAP analyzer keeps TCP recovery evidence, exact frames, application symptoms, alternatives, and limitations together in the investigation.
Bottom line
tcp.analysis.spurious_retransmission is a hypothesis generated from the visible trace. Prove or reject it with the original byte range, ACK/SACK history, retransmission timing, capture completeness, and a healthy baseline. Only then decide whether the sender, receiver, network path, or capture process is the most likely explanation.