# Revision history [back]

### TCP Dup ACK detection bug?

Hi all!

In RFC 5681 it is stated that:

DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a "duplicate" in the following algorithms when: .... (e) the advertised window in the incoming acknowledgment equals the advertised window in the last incoming acknowledgment.....

AND

    Alternatively, a TCP that utilizes selective acknowledgments
(SACKs) [RFC2018, RFC2883] can leverage the SACK information to
determine when an incoming ACK is a "duplicate" (e.g., if the ACK
contains previously unknown SACK information).


But if you check the next PCAP it seems Wireshark ignores the last statement:

Frames 355,356,357 and a lot of subsequent ones have the same ACK number of 314254 (relative), they contain changing SACK blocks but at the same time Advertised window size also changes. Therefore they have been decoded (incorrectly?) as [TCP Window updates], whereas they should be decoded as Dup ACKs.

Frames 486-508 are Fast retransmisions whereas they have been decoded as [TCP Out-Of-Orders]. Is it a bug or I'm missing something?

### TCP Dup ACK detection bug?

Hi all!

In RFC 5681 it is stated that:

DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a "duplicate" in the following algorithms when: .... (e) the advertised window in the incoming acknowledgment equals the advertised window in the last incoming acknowledgment.....

AND

    Alternatively, a TCP that utilizes selective acknowledgments
(SACKs) [RFC2018, RFC2883] can leverage the SACK information to
determine when an incoming ACK is a "duplicate" (e.g., if the ACK
contains previously unknown SACK information).


But if you check the next PCAP it seems Wireshark ignores the last statement:

Frames 355,356,357 and a lot of subsequent ones have the same ACK number of 314254 (relative), they contain changing SACK blocks but at the same time Advertised window size also changes. Therefore they have been decoded (incorrectly?) as [TCP Window updates], whereas they should be decoded as Dup ACKs.

Frames 486-508 are Fast retransmisions retransmissions whereas they have been decoded as [TCP Out-Of-Orders]. Is it a bug or I'm missing something?