On Mon, Jun 6, 2016 at 8:31 AM, Robert Dahlem <Robert.Dahlem@xxxxxxx> wrote:
>
> On 01.06.2016 21:01, Jim Aragon wrote:
>
>> As Chris pointed out, packets with the SYN bit set are never scaled, so
>> the window size value and the calculated window size are the same, but f
>> you look farther down in the captured packets, past the SYN and SYN/ACK,
>> you will see that the calculated window size is the number in the window
>> size value field multiplied by the scale factor.
>
>
> I do not agree with the statement that packets with the SYN bit set are
> never scaled.
The standard is pretty clear for this case.
RFC1323 : https://www.ietf.org/rfc/rfc1323.txt section 2.2
"""
The Window field in a SYN (i.e., a <SYN> or <SYN,ACK>) segment
itself is never scaled.
"""
> In this particular case the SYN/ACK packet is the only one
> the client ever sees from the server until the problem shows up. So
> sure, the window that the server opens to the client is scaled at this
> moment.
>
> Anyway, I finally came down to the bottom of this: my system is a SLES
> 11 SP4 with a Linux kernel 3.0.101, a pretty old one. From what I read
> there might be a problem with the kernels view on window scaling. But
> one can tell the kernel to ignore out-of-window packets with
>
> sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal = 1
>
> Kind regards,
> Robert
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
