| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1292279462.2679.146.camel@edumazet-laptop> Date: Mon, 13 Dec 2010 23:31:02 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Дмитрий Балакин <dmitriy.balakin@...neiron.ru>, David Miller <davem@...emloft.net> Cc: Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org Subject: Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation. Le lundi 13 décembre 2010 à 23:44 +0300, Дмитрий Балакин a écrit : > 2010/12/13 Eric Dumazet <eric.dumazet@...il.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@...zilla.kernel.org > >> To: shemminger@...ux-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@...ux-foundation.org > >> ReportedBy: dmitriy.balakin@...neiron.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@...neiron.ru Signed-off-by: Eric Dumazet <eric.dumazet@...il.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; } -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists