Updated with link to example capture
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
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:
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
edited 27 Sep '14, 23:22
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