On 10/30/14 02:07, John Sullivan wrote:
On Wednesday, October 29, 2014, 6:42:00 PM, Jeff Morriss wrote:
On 10/28/14 11:12, ?? wrote:
Hi ,
If the server does not support 'Window Scale' option, even the
client send one packet with WS=256, I thought the real window size
should be consider small than 64K. But I can see the 'Calculated
window size' is larger that 64K on Wireshark1.12.1, is there something
wrong ? the trace file is attached.
Well remember that on a given TCP connection there are 2 window sizes:
that of the client and that of the server.
Technically 6, 3 in each direction. The effective window is the minimum
of the 3 which apply in a particular direction.
Well, true, but in this context there are only 2 which we're talking
about. :-)
In this trace the client supports scaling but the server does not.
Wireshark (at least the development version I just tried) correctly
applied scaling to the client's window but not to the server's window:
If the server doesn't send a Window Scale option, not even with a
scale factor of 1 (indicating it understands, but is not using it on
its own advertised receive windows), then it doesn't understand the
option and the client should assume it doesn't apply. Not that it
*really* matters since the server will simply not be using all of the
client's allowed receive window and the client never had any
expectation that it ought to be receiving a certain amount of data at
any point anyway.
Hmm, I don't do much with TCP (from a protocol perspective) but that
certainly makes sense. And, in fact, it appears that the TCP dissector
*wants* to act that way, based on the comments in the code:
/* This is called for SYN and SYN+ACK packets and the purpose is to verify
* that we have seen window scaling in both directions.
* If we can't find window scaling being set in both directions
* that means it was present in the SYN but not in the SYN+ACK
* (or the SYN was missing) and then we disable the window scaling
* for this tcp session.
*/
It would be good if someone can open a bug report (attaching this
already-public capture file) so this isn't forgotten.