


This means that if the sender does not receive the acknowledgement after three seconds (or RTT > 3 seconds), it will resend the packet. After each retransmission the value of the RTO is doubled and the computer will retry up to three times. On the initial packet sequence, there is a timer called Retransmission Timeout (RTO) that has an initial value of three seconds. The majority of us are well aware of the primary retransmission logic. Thus, to ensure the packet is received, the sender will retransmit the packet to the other party. If the three-way handshake is not present, then Wireshark will use the 3-ms rule.Easy to understand, right? But what happens when a packet is lost? TCP protocol has built-in logic for ensuring that packets are received. This is a hard-coded number, and Wireshark can mis-identify out-of-order packets as retransmissions and vice-versa.īeginning with Wireshark 1.12.x, if the TCP three-way handshake is present in the trace, Wireshark will calculate the initial round-trip time and compare to that instead of to 3 ms. In Wireshark versions up to and including 1.10.x, Wireshark will identify the packet as an out-of-order packet if it appears within 3 ms of where it should have been, and will identify it as a retransmission if it appears more than 3 ms from where it should have been. Wireshark has to try to distinguish between out-of-order packets and retransmissions. Unfortunately, out-of-order packets look exactly the same as retransmissions where you are downstream from the point of packet loss: There is a gap in the sequence numbers and the packet shows up later than expected.

In this case, you will see the expected sequence number only once.

In this case, there will be a gap in the sequence numbers, Wireshark's expert will say "Previous segment not captured," and then the expected packet will show up later. If you are capturing downstream from the point of packet loss-packets are being dropped before they pass your capture point-then Wireshark will only see the retransmission. In this case, you will see the expected sequence number twice. If you are capturing upstream from the point of packet loss-packets are being dropped after they pass your capture point-then Wireshark will see both the original packet and the retranmission and it will be clear that the second one is a retransmission. It is normal to see the sequence number only once if you are capturing downstream from the point of packet loss. It depends on where you are capturing in relation to the point of packet loss (upstream or downstream).
