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

TCP Window Scaling - handshake and data traffic difference?

0

Updated with link to example capture

Hi,

While troubleshooting what seems to be an issue related to TCP Window Scaling I noticed the following in this capture: https://www.cloudshark.org/captures/42b210c2004c

  • The client announced that it supported TCP Window Scaling in the SYN (65535x16)
  • The server announced that it did not support TCP Window Scaling (or rather did not announce that it DID support it...) in the SYN/ACK
  • The TCP Window Size in the following traffic from the client is reported in the Packet List in Wireshark as 1048560 and in the Packet Details as 65535x16 i.e. clearly still using TCP Window Scaling.

Now to the question:

I've read and re-read the "Bible" (TCP/IP Illustrated Vol 1) about this subject along with a number of Google hits. The conclusion is that if one side supports TCP Window Scaling and the other does not it will not be used at all.

However I'm wondering why I'm still seeing scaled window size in the traffic following the initial handshake? If it's not being used at all, why is the client still advertising it?

I see two possible scenarios:

  1. The client is oblivious to the fact that the server is not using TCP Window Scaling and thus keeps on using it. This could be in conflict with the conclusion found elsewhere, but in all honesty I have not seen a capture where the server actually needed to transfer data back to the client and thus never having the need to fill the window.
  2. The client does indeed stop using TCP Window Scaling after the handshake, since the server did not support it, but Wireshark picked up the TCP Option for Window Scaling in the SYN and "remembers" that for the TCP stream in question. I consider this to be slightly confusing if true.

Finally, this does not seem at all seem to be related to the problem at hand; after doing a number of captures, it is clear in all of them. Wireshark version used: 1.12.1 Clients: Mac OS X 10.9.4 and Windows 7.

Help is appreciated - especially if I'm completely missing the obvious :-)

asked 27 Sep '14, 13:35

NJL's gravatar image

NJL
21●4●4●8
accept rate: 0%

edited 27 Sep '14, 23:22

It would help troubleshoot what you're seeing if you'd post an actual capture file somewhere, like cloudshark.org, so we can load it in Wireshark and see what's happening.

(27 Sep '14, 15:45) Jim Aragon

Thanks for the heads-up. I've added a link.

(27 Sep '14, 23:23) NJL

I have been asking myself the same thing all day. I have the same in a capture here. Client say 16258 Window : WSS 4, Server says window 4328(...) WSS nothing. Client uses WSS 4 for the whole Conversation, Server uses none.

Funnily enough Bytes in flight never goes about 16258, So I can only assume it is NOT using the WSS??

(29 Sep '14, 13:03) DarrenWright

I found that Wireshark v1.10.10 (on Mac OS X at least) displayed everything correctly. Perhaps you could try that version to see for yourself if it changes anything?

(30 Sep '14, 00:47) NJL

One Answer:

0

Looks like a Wireshark misinterpretation (= bug) to me, because if one of the two systems does not signal that it supports the Window Scaling mechanism both should not use it. And I guess they both don't, because the client uses a pretty large window of 64k all the time (but I have to admit that it's an Apple device, and I only have experience with the TCP stack of Windows regarding it's behavior towards Window Scaling).

In my eyes this is just Wireshark decoding it wrong - it does know that the server doesn't use Window scaling (check TCP header in packet 5, where it says "Window size scaling factor: -2 (no window scaling used)"), so it should apply that knowledge to both directions, but doesn't.

You might want to open a bug report at http://bugs.wireshark.org and attach the trace (and maybe mention this post by URL)

answered 28 Sep '14, 09:24

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

Thanks, that's also my conclusion.

I'll probably try to install older versions of Wireshark and see if that changes anything.

P.S. Do you happen to know of any material where the TCP stack of Windows is documented - e.g. for a similar scenario? There are plenty of books and websites covering how TCP should behave according to the RFCs etc., but I have a hard time finding the "bible" that covers Windows. Any help appreciated :-)

(28 Sep '14, 22:35) NJL

You'll want to look at "Windows Internals" if you're interested in the TCP interna of the current windows OS'es. That's the "Windows" bible, prepare for 1000+ pages though ;)

(28 Sep '14, 23:49) Landi

I've opened a bug report after I verified that Wireshark v1.10.10 on Mac OS X 10.9 does not show this behaviour.

(30 Sep '14, 00:48) NJL

For reference, the bug is 10514

(30 Sep '14, 01:37) grahamb ♦