* Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
@ 2010-12-13 16:59 Stephen Hemminger
2010-12-13 17:14 ` Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2010-12-13 16:59 UTC (permalink / raw)
To: netdev
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.html.
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.
--
--- include/net/tcp.h.orig 2010-12-02 04:41:22.000000000 +0300
+++ include/net/tcp.h 2010-12-13 13:58:05.000000000 +0300
@@ -1077,9 +1077,10 @@
}
static inline int tcp_paws_check(const struct tcp_options_received *rx_opt,
- int paws_win)
+ unsigned int paws_win)
{
- if ((s32)(rx_opt->ts_recent - rx_opt->rcv_tsval) <= paws_win)
+ if (rx_opt->ts_recent < rx_opt->rcv_tsval ||
+ rx_opt->ts_recent - rx_opt->rcv_tsval <= paws_win)
return 1;
if (unlikely(get_seconds() >= rx_opt->ts_recent_stamp + TCP_PAWS_24DAYS))
return 1;
--
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. 2010-12-13 16:59 Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation Stephen Hemminger @ 2010-12-13 17:14 ` Eric Dumazet 2010-12-13 20:44 ` Дмитрий Балакин 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2010-12-13 17:14 UTC (permalink / raw) To: Stephen Hemminger, dmitriy.balakin; +Cc: netdev 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.html. > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. 2010-12-13 17:14 ` Eric Dumazet @ 2010-12-13 20:44 ` Дмитрий Балакин 2010-12-13 22:31 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: Дмитрий Балакин @ 2010-12-13 20:44 UTC (permalink / raw) To: Eric Dumazet; +Cc: Stephen Hemminger, netdev 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.html. >> >> 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: 23:40:52.726909 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [S], seq 1116163452, win 5840, options [mss 1460,sackOK,TS val 141403 ecr 0,nop,wscale 6], length 0 23:40:52.737227 IP 212.176.201.162.80 > 213.141.147.8.33778: Flags [S.], seq 4019723831, ack 1116163453, win 16384, options [mss 1360,nop,wscale 0,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0 23:40:52.737392 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 141405 ecr 0], length 0 23:40:52.737926 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [P.], seq 1:113, ack 1, win 92, options [nop,nop,TS val 141405 ecr 0], length 112 23:40:52.749101 IP 212.176.201.162.80 > 213.141.147.8.33778: Flags [P.], seq 1:415, ack 113, win 65423, options [nop,nop,TS val 3503477357 ecr 141403], length 414 23:40:52.749219 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 141408 ecr 0], length 0 23:40:53.002253 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [P.], seq 1:113, ack 1, win 92, options [nop,nop,TS val 141472 ecr 0], length 112 23:40:53.012252 IP 212.176.201.162.80 > 213.141.147.8.33778: Flags [P.], ack 113, win 65423, options [nop,nop,TS val 0 ecr 141408], length 0 23:40:55.665916 IP 212.176.201.162.80 > 213.141.147.8.33778: Flags [P.], seq 1:415, ack 113, win 65423, options [nop,nop,TS val 3503477387 ecr 141408], length 414 23:40:55.666023 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 142137 ecr 0], length 0 23:40:55.676963 IP 212.176.201.162.80 > 213.141.147.8.33778: Flags [P.], seq 1:415, ack 113, win 65423, options [nop,nop,TS val 3503477387 ecr 142137], length 414 23:40:55.677007 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 142140 ecr 0], length 0 23:41:01.683646 IP 212.176.201.162.80 > 213.141.147.8.33778: Flags [P.], seq 1:415, ack 113, win 65423, options [nop,nop,TS val 3503477447 ecr 142140], length 414 23:41:01.683752 IP 213.141.147.8.33778 > 212.176.201.162.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 143642 ecr 0], length 0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. 2010-12-13 20:44 ` Дмитрий Балакин @ 2010-12-13 22:31 ` Eric Dumazet 2010-12-14 0:35 ` Дмитрий Балакин 2010-12-16 22:08 ` David Miller 0 siblings, 2 replies; 6+ messages in thread From: Eric Dumazet @ 2010-12-13 22:31 UTC (permalink / raw) To: Дмитрий Балакин, David Miller Cc: Stephen Hemminger, netdev 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.html. > >> > >> 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; } ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. 2010-12-13 22:31 ` Eric Dumazet @ 2010-12-14 0:35 ` Дмитрий Балакин 2010-12-16 22:08 ` David Miller 1 sibling, 0 replies; 6+ messages in thread From: Дмитрий Балакин @ 2010-12-14 0:35 UTC (permalink / raw) To: Eric Dumazet; +Cc: David Miller, Stephen Hemminger, netdev 14 декабря 2010 г. 1:31 пользователь Eric Dumazet <eric.dumazet@gmail.com> написал: > 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.html. >> >> >> >> 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; > } > > > > In Windows uptime should be about 7 years old to sign is appear in a TS value, it really should be quite rare. But there is such a systems, where the TS value has nothing to do with uptime and randomly generated for each TCP connection, such as the one referred to earlier. Yes, you're right, my patch breaks the PAWS. Your patch is the right way. Thanks! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. 2010-12-13 22:31 ` Eric Dumazet 2010-12-14 0:35 ` Дмитрий Балакин @ 2010-12-16 22:08 ` David Miller 1 sibling, 0 replies; 6+ messages in thread From: David Miller @ 2010-12-16 22:08 UTC (permalink / raw) To: eric.dumazet; +Cc: dmitriy.balakin, shemminger, netdev From: Eric Dumazet <eric.dumazet@gmail.com> Date: Mon, 13 Dec 2010 23:31:02 +0100 > [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> Applied to net-next-2.6, thanks! ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-12-16 22:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-13 16:59 Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation Stephen Hemminger 2010-12-13 17:14 ` Eric Dumazet 2010-12-13 20:44 ` Дмитрий Балакин 2010-12-13 22:31 ` Eric Dumazet 2010-12-14 0:35 ` Дмитрий Балакин 2010-12-16 22:08 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).