> Le lundi 13 décembre 2010 à 23:44 +0300, Дмитрий Балакин a écrit :
>> 2010/12/13 Eric Dumazet <eric.dumazet@gmail.com>:
>> > Le lundi 13 décembre 2010 à 08:59 -0800, Stephen Hemminger a écrit :
>> >>
>> >> Begin forwarded message:
>> >>
>> >> Date: Mon, 13 Dec 2010 14:29:58 GMT
>> >> From:
bugzilla-daemon@bugzilla.kernel.org
>> >> To:
shemminger@linux-foundation.org
>> >> Subject: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
>> >>
>> >>
>> >>
https://bugzilla.kernel.org/show_bug.cgi?id=24842
>> >>
>> >> Summary: Compatibility issue with uggly Windows RFC1323
>> >> implementation.
>> >> Product: Networking
>> >> Version: 2.5
>> >> Kernel Version: All
>> >> Platform: All
>> >> OS/Version: Linux
>> >> Tree: Mainline
>> >> Status: NEW
>> >> Severity: normal
>> >> Priority: P1
>> >> Component: IPV4
>> >> AssignedTo:
shemminger@linux-foundation.org
>> >> ReportedBy:
dmitriy.balakin@nicneiron.ru
>> >> Regression: No
>> >>
>> >>
>> >> Created an attachment (id=40012)
>> >> --> (
https://bugzilla.kernel.org/attachment.cgi?id=40012)
>> >> Patch
>> >>
>> >> First, sorry for my bad english.
>> >>
>> >> The issue is that Linux-based OS sometimes can't make an tcp connection to some
>> >> Windows servers with switched on buggy implementation of rfc1323, that
>> >> described on this forum:
>> >>
http://www.network-builders.com/windows-tcp-timestamp-not-compliant-rfc-1323-a-t80898.....
>> >>
>> >> Because some Windows hosts implementation of rfc1323 bases on randomly
>> >> generated TSval and sent first value of TSval as 0, the difference of recent
>> >> and new TSval sometimes has been affected by a sign magic issue and the PAWS
>> >> mechanism has been triggered. Anyway, the rfc1323 has discribes the condition
>> >> of PAWS as "0 < (t - s) < 2**31", that has been right implementation in current
>> >> linux kernel, but incompatible with Windows bug.
>> >>
>> >> For example, the one of affected to this issue Windows host is behind
>> >> relay.n-l-e.ru:80
>> >>
>> >> I think that my small patch makes the kernel more compatible with this windows
>> >> bug.
>> >>
>> >> -
>> >
>> > I have no problem connecting my linux client to relay.n-l-e.ru:80
>> >
>> > Could you elaborate please ?
>> >
>> > 18:13:12.444250 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [S],
>> > seq 665972386, win 5840, options [mss 1460,sackOK,TS val 1746885 ecr
>> > 0,nop,wscale 7], length 0
>> > 18:13:12.473912 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [S.],
>> > seq 190215045, ack 665972387, win 5792, options [mss 1460,sackOK,TS val
>> > 730697107 ecr 1746885,nop,wscale 0], length 0
>> > 18:13:12.473976 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.],
>> > ack 1, win 46, options [nop,nop,TS val 1746888 ecr 730697107], length 0
>> > 18:13:14.984153 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.],
>> > seq 1:8, ack 1, win 46, options [nop,nop,TS val 1747139 ecr 730697107],
>> > length 7
>> > 18:13:15.013901 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
>> > ack 8, win 5792, options [nop,nop,TS val 730697360 ecr 1747139], length
>> > 0
>> > 18:13:15.377879 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [P.],
>> > seq 8:10, ack 1, win 46, options [nop,nop,TS val 1747178 ecr 730697360],
>> > length 2
>> > 18:13:15.403900 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
>> > ack 10, win 5792, options [nop,nop,TS val 730697399 ecr 1747178], length
>> > 0
>> > 18:13:15.461384 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [P.],
>> > seq 1:159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr
>> > 1747178], length 158
>> > 18:13:15.461429 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [.],
>> > ack 159, win 54, options [nop,nop,TS val 1747186 ecr 730697405], length
>> > 0
>> > 18:13:15.461448 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [F.],
>> > seq 159, ack 10, win 5792, options [nop,nop,TS val 730697405 ecr
>> > 1747178], length 0
>> > 18:13:15.461607 IP 10.150.51.215.51781 > 212.176.201.162.80: Flags [F.],
>> > seq 10, ack 160, win 54, options [nop,nop,TS val 1747186 ecr 730697405],
>> > length 0
>> > 18:13:15.533846 IP 212.176.201.162.80 > 10.150.51.215.51781: Flags [.],
>> > ack 11, win 5792, options [nop,nop,TS val 730697412 ecr 1747186], length
>> > 0
>> >
>> >
>> >
>>
>> Problems occur only when the remote side sets the TC val > 2147483647,
>> ie when there is a sign:
>>
>
> You mean a windows machine with a big uptime ?
> That must be quite rare indeed ;)
>
> Anyway, we can not test values like suggested patch, or risk a problem
> when wrap around occurs...
>
> However, testing the special ts_recent=0 case would be possible (we
> already did a change to accept a windows initiated connect to a linux
> server and still activate tcp timestamps)
>
> (commit fc1ad92dfc4e363a055 tcp: allow timestamps even if SYN packet has
> tsval=0)
>
> Something like following patch ?
>
> Thanks
>
>
> [PATCH net-next-2.6] tcp: relax tcp_paws_check()
>
> Some windows versions have wrong RFC1323 implementations, with SYN and
> SYNACKS messages containing zero tcp timestamps.
>
> We relaxed in commit fc1ad92dfc4e363 the passive connection case
> (Windows connects to a linux machine), but the reverse case (linux
> connects to a Windows machine) has an analogue problem when tsvals from
> windows machine are 'negative' (high order bit set) : PAWS triggers and
> we drops incoming messages.
>
> Fix this by making zero ts_recent value special, allowing frame to be
> processed.
>
> Based on a report and initial patch from Dmitiy Balakin
>
> Bugzilla reference :
https://bugzilla.kernel.org/show_bug.cgi?id=24842
>
> Reported-by:
dmitriy.balakin@nicneiron.ru
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> include/net/tcp.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 3f227ba..2ab6c9c 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1038,7 +1038,13 @@ static inline int tcp_paws_check(const struct tcp_options_received *rx_opt,
> return 1;
> if (unlikely(get_seconds() >= rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS))
> return 1;
> -
> + /*
> + * Some OSes send SYN and SYNACK messages with tsval=0 tsecr=0,
> + * then following tcp messages have valid values. Ignore 0 value,
> + * or else 'negative' tsval might forbid us to accept their packets.
> + */
> + if (!rx_opt->ts_recent)
> + return 1;
> return 0;
> }
>
>
>
>
