From: Eric Dumazet <eric.dumazet@gmail.com>
To: Stephen Hemminger <shemminger@vyatta.com>, dmitriy.balakin@nicneiron.ru
Cc: netdev@vger.kernel.org
Subject: Re: Fw: [Bug 24842] New: Compatibility issue with uggly Windows RFC1323 implementation.
Date: Mon, 13 Dec 2010 18:14:39 +0100 [thread overview]
Message-ID: <1292260479.2759.69.camel@edumazet-laptop> (raw)
In-Reply-To: <20101213085913.374c1072@nehalam>
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
next prev parent reply other threads:[~2010-12-13 17:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2010-12-13 20:44 ` Дмитрий Балакин
2010-12-13 22:31 ` Eric Dumazet
2010-12-14 0:35 ` Дмитрий Балакин
2010-12-16 22:08 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1292260479.2759.69.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=dmitriy.balakin@nicneiron.ru \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox