Before receiving three times Dup ACK, and prior to RTO, received the packet required with Dup ACK (it is unknown whether came late or retransmitted).

NW route was different for packets (for example, such as by Equal-Cost Multi Path) and really switched the order.

Next two reasons will be considered as cause. 'It is within the RTO of time, but Seq# is not in order' will appear this mark. Unlike the Fast, this mark is displayed when the packet after the RTO is received in a different order as the order of the Seq#.

Īs above, when TCP Dup ACK is resent three times (four times including first sent), Fast Recovery Algorithm of TCP works and opponent resent the packet required with Ack# without waiting for the RTO (Retransmission TimeOut).This mark will be displayed in packet what wireshark believes to have been retransmitted by this algorithm (Dup ACK is the third and within RTO). So, if this Dup ACK occurs frequently, it is probable that packet loss has occurred less frequently. If the opponent comes send this many times, it will be considered that he does not receive a packet of Seq # = 1000, and he requests a retransmission. įor example, when Ack# = 1000, it means ' Next, I want to get the packet Seq#=1000 !'. The mark is displayed when 'The same Ack#(acknowledgment number) is observed compared as the one before packet.

It has been received prior to the start of capturing.This is displayed when the 'As far as we see the Seq#(sequence number) of the packet, a packet should be observed before this packet but not seen in Wireshark'.Ĭause of not capturing a packet before are perhaps two of either following.

Wireshark tcp retransmission