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

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:

https://www.ietf.org/mail-archive/web/tcpm/current/msg01200.html

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

Philst
4311616
accept rate: 27%

edited 04 Apr '17, 04:59

Jasper's gravatar image

Jasper ♦♦
23.8k551284


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

Start Quote.

DUPLICATE ACKNOWLEDGMENT:

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

Philst
4311616
accept rate: 27%

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

    /* DUPLICATE ACK
     * 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 ♦♦
23.8k551284
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

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "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:

×42
×6

question asked: 04 Apr '17, 03:38

question was seen: 1,243 times

last updated: 04 Apr '17, 20:52

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