This is our old Q&A Site. Please post any new questions and answers at

In the capture included with Ask Wireshark question #60530, there were acknowledgement packets #17-#23 and #28-#31 that were Dup-ACKs but each also increased the Receive Window size.

Due to the receive window increase, Wireshark reported them as a "TCP Window Update" but did not report them as "Duplicate ACK".

It also seems that the receiving client also didn't treat them as Dup-ACKs.

1) Can anyone confirm that the Wireshark code explicitly decides not to treat a Dup-ACK as such if it also contains an increment (or change) to the Receive Window value.

2) Does anyone know if this is a general TCP/IP rule, as suggested in the article:

3) Can anyone comment about the way these are handled in any TCP/IP implementations they are aware of.

asked 04 Apr '17, 03:38

Philst's gravatar image

accept rate: 27%

edited 04 Apr '17, 04:59

Jasper's gravatar image

Jasper ♦♦

For my question (2), I just found RFC 5681 which does define Dup-ACKs.

Start Quote.


An acknowledgment is considered a "duplicate" in the following algorithms when

(a) the receiver of the ACK has outstanding data,

(b) the incoming acknowledgment carries no data,

(c) the SYN and FIN bits are both off,

(d) the acknowledgment number is equal to the greatest acknowledgment received on the given connection (TCP.UNA from [RFC793]) and

(e) the advertised window in the incoming acknowledgment equals the advertised window in the last incoming acknowledgment.

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).

End quote.

It would therefore appear that a receiver should not include Receive Window changes in any ACK packets that it wants to be treated as Dup-ACKs.

Thus, the TCP stack in the receiving client in Question #60530 is behaving badly.

This means that my own answers to my questions are:

(1) Yes, Wireshark is indeed treating behaving correctly in the way it handles such ACK packets.

(2) Yes, it is a rule as defined in RFC 5681 Section 2.

(3) Therefore, we wouldn't expect any TCP stacks to treat such ACKs as Dup-ACKs.

permanent link

answered 04 Apr '17, 20:52

Philst's gravatar image

accept rate: 27%

  1. I think this is the comment of the code block in question, taken from packet-tcp.c:

     * It is a duplicate ack if window/seq/ack is the same as the previous
     * segment and if the segment length is 0
  2. yes, I think it is, but stacks behavior may vary (as always) :-)

  3. I can't remember to have seen any trace where an ACK with a receive window change was considered a duplicate ACK.

permanent link

answered 04 Apr '17, 04:56

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 04 Apr '17, 03:38

question was seen: 1,684 times

last updated: 04 Apr '17, 20:52

p​o​w​e​r​e​d by O​S​Q​A