Retransmissions and gaps
A retransmission is a suspected repeat. A lost-segment note often means the capture never saw the original.
What Wireshark is willing to say
tcp.analysis.retransmission marks a frame Wireshark suspects is a repeat of an earlier sequence range. tcp.analysis.fast_retransmission is the same idea, timed from duplicate ACKs rather than from a long wait. tcp.analysis.duplicate_ack marks an ACK that repeats an acknowledgment, which is how a receiver says “I am still missing something.” These are analysis flags. The word in the details tree is “suspected” for a reason.
tcp.analysis.lost_segment means a later frame acknowledges or continues past bytes this file never contained. It is common at the start of a capture, when you opened the window in the middle of a stream. It is also common when the mirror dropped a frame. The flag means “not in this file.” It does not, by itself, mean the network dropped the packet on the way to the receiver.
tcp.analysis.retransmission && ip.addr == 10.8.0.40 && ip.addr == 10.8.0.20
Out of order is a different flag
tcp.analysis.out_of_order marks a segment that arrived in the file earlier than its sequence position, with a small delay. Reordering and loss look similar if you only watch the Info column. Open the analysis flags and read which one fired. A path that reorders will show out-of-order segments that are then acknowledged once, without a retransmission. Loss tends to grow duplicate ACKs and a retransmission.
tcp.analysis.spurious_retransmission marks a repeat the receiver had already acknowledged. The sender retransmitted anyway, often because its timer fired before the ACK arrived at this capture point, or because the ACK was delayed. It is a clue about timing, not proof that the first copy failed.
Worked case: the copy stalled at one capture point
A lab file copy from 10.8.0.40 to 10.8.0.20 shows a cluster of duplicate ACKs from the server, then a retransmission from the client, all in tcp.stream 4. You set a time reference on the first duplicate ACK. The retransmission sits 80 milliseconds later. The bytes in the retransmitted frame match a sequence the server had not acknowledged. At this capture point, the server asked for a hole and the client filled it.
The same hour, a second file taken on a busy mirror shows tcp.analysis.lost_segment with no duplicate ACKs and no retransmission. The receiver’s later ACK covers the “missing” bytes. The mirror dropped the frame. The conversation did not. You write the two notes differently: stream 4 recovered a hole; the mirror file has a capture gap. The capture-point line is what makes those notes different.
Count them inside one stream
A file-wide retransmission count mixes unrelated hosts. Filter to the stream, then read the flags, or use the Expert Information window after that filter is on and confirmed. A handful of retransmissions in a long copy is ordinary. A burst that lines up with a stall is the part worth a timestamp.
Keep the claim tied to a direction. “The client retransmitted 40 segments in stream 4 between 14:02 and 14:03” is a finding a second person can check. “The network was lossy” is a guess about every path, and this file is one path.
Diagram
A hole the receiver felt, and a hole only the capture has
- Stream
Filter to one tcp.stream before you count anything.
- Flag
Read the analysis flag: retransmission, duplicate ACK, out of order, or lost segment.
tcp.analysis.retransmission
- Neighbor
Look at the frames before and after. Duplicate ACKs plus a repeat tell a recovery story.
- Point
Ask whether a second capture point saw the same hole.
Two ways a sequence number can look missing
Flags. Duplicate ACKs, then a retransmission of the missing range.
Meaning. The receiver kept asking, and the sender repeated data.
Note. Time the gap. Name the stream and the direction.
Flags. Lost segment, then an ACK that covers the bytes, and no retry.
Meaning. The file has a gap. The endpoints may have seen every byte.
Note. Call it a capture gap unless a second point agrees.
Check yourself
1. Wireshark marks tcp.analysis.retransmission. What is the careful reading?
2. You see tcp.analysis.lost_segment, then an ACK covering those bytes, and no retransmission. What is the likely situation?
3. The whole lab file shows 400 retransmissions. How do you turn that into a claim?