Hi all,
RFC1323 states:
This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in
SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window)
That's why I'm sure that the missing WS= in the syn/ack-Packet
will disable the window scaling completely for this session and
should not been calculated for the 3rd packet below.
Cheers
Markus
____________________
On Thu, 29 Jul 2004 11:42:12 -0400, Ian Schorr wrote:
Turning on relative sequence numbers also allows Ethereal to detect and understand TCP window scaling. Were scaling
bits set in the SYN segments for the connection? If so, I'm guessing that "747520" is the CORRECT window size, and
5840 is the window size before shifting bits (which is not the true size of the advertised window)...
Ian
____________________
On Jul 29, 2004, at 5:35 AM, Markus Rehbach wrote:
Hi all,
there seems to be a problem in 0.10.5 and probably older ones.
If preference is 'tcp.relative_sequence_numbers: TRUE' there is a wrong
value shown for the window size (3rd line below: Win=747520 should be 5840).
0.070763 a -> b TCP 32985 > imap [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=3609664 TSER=0 WS=7
0.071129 b -> a TCP imap > 32985 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
0.071176 a -> b TCP 32985 > imap [ACK] Seq=1 Ack=1 Win=747520 Len=0
If preference is 'tcp.relative_sequence_numbers: FALSE' it looks good.
0.076386 a -> b TCP 32991 > imap [SYN] Seq=4090487846 Ack=0 Win=5840 Len=0 MSS=1460 TSV=4006974 TSER=0 WS=7
0.076748 b -> a TCP imap > 32991 [SYN, ACK] Seq=3661596958 Ack=4090487847 Win=5840 Len=0 MSS=1460
0.076798 a -> b TCP 32991 > imap [ACK] Seq=4090487847 Ack=3661596959 Win=5840 Len=0
Problem shows up in ethereal and tethereal (no surprise;-).
Markus