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

TCP transmission deviates from receive window - any legitimate reason

0

I have observed a TCP connection where the client keeps sending data despite the sequence number exceeding the highest ack number + window size received from the peer. Shortly thereafter the peer terminates the connection, and I am trying to figure out why. Is there any legitimate reason to transmit the data even though it falls outside the peer's receive window?

For instance there is an ACK=24220 with Win=65392 and the transmitter responds with a segment with SEQ=93364, which is clearly outside the window. Am I fundamentally misunderstanding how the TCP window is supposed to work?

The full capture of this particular stream can be found at https://drive.google.com/file/d/0B17tiJAzTan8Q1VvRm1lcWwtRG8/view?usp=sharing

Some more context: the application in question is Picasa's google album upload on Windows XP, which uses the InternetWriteFile API.

asked 16 Aug '15, 10:30

Evgeny's gravatar image

Evgeny
1111
accept rate: 0%


One Answer:

0

I don't know why the sender keeps sending data even after the receive window fills. (Something about the way the XP TCP stack works ?)

I do note, however, that the rate at which the receiver acks the data seems pretty low and that repeated duplicate acks are being received.

Maybe the connection is being throttled or something...

Can you try the upload with a more modern version of Windows ?

The TCP graph of the session is shown below. (Statistics ! Tcp StreamGraph ! Time-Sequence Graph (tcptrace)

The top line shows the available window (shown as the maximum sequence number of the window); the next shows the send sequence numbers and the bottom line shows the ack sequence numbers for the upload sender to receiver direction.

alt text

answered 16 Aug '15, 13:42

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850
accept rate: 17%

edited 16 Aug '15, 13:43

The other strange issue is that the "Don't Fragment" flag isn't set, which it should be... this doesn't look like a "normal" capture at all :-)

(16 Aug '15, 14:06) Jasper ♦♦

Windows 10 on a different PC on the same WiFi network does not have this problem. This does seem like something specific to XPs stack, however I haven't found any documented bug.

(16 Aug '15, 14:11) Evgeny

... and the server does not support Selective Acknowledgements.

According to Jaspers finding:

I found something for Win2000 systems:

However, if MTU detection is disabled (that is, the value of EnablePMTUDiscovery is 0), the system uses a fixed MTU of 576 bytes. If you change the default value of the MTU entry, you override either setting as it pertains to the interface represented by this subkey.

This can be found here: https://technet.microsoft.com/en-us/library/cc938197.aspx

But it seems to be valid for XP, too. Because the largest SegementSize from the Client is 536 in the trace.

Could you provide the Win10 trace, too?

(16 Aug '15, 15:01) Christian_R