Bug 24842 - Compatibility issue with uggly Windows RFC1323 implementation.
Summary: Compatibility issue with uggly Windows RFC1323 implementation.
Status: RESOLVED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV4 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-13 14:29 UTC by Dmitriy Balakin
Modified: 2010-12-17 14:20 UTC (History)
0 users

See Also:
Kernel Version: All
Subsystem:
Regression: No
Bisected commit-id:


Attachments
It's a wrong patch (546 bytes, text/plain)
2010-12-13 14:29 UTC, Dmitriy Balakin
Details
Capture session in libpcap format (3.00 KB, application/octet-stream)
2010-12-13 14:43 UTC, Dmitriy Balakin
Details
Patch from Eric Dumazet (604 bytes, patch)
2010-12-17 14:19 UTC, Dmitriy Balakin
Details | Diff

Description Dmitriy Balakin 2010-12-13 14:29:56 UTC
Created attachment 40012 [details]
It's a wrong 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.
Comment 1 Dmitriy Balakin 2010-12-13 14:43:40 UTC
Created attachment 40022 [details]
Capture session in libpcap format
Comment 2 Dmitriy Balakin 2010-12-13 21:33:55 UTC
Note that problems arise only when the remote side sets the TC val > 2147483647,
ie when there is a sign.

Also, probably due to the fact that I started to place the resource address in public forums as part of the issue, currently administrator of the host relay.n-l-e.ru reconfigure the system so that the connection is reset after a short timeout, then before me has not been noticed. But this does not hide the problem.
Comment 3 Dmitriy Balakin 2010-12-17 14:19:20 UTC
Created attachment 40622 [details]
Patch from Eric Dumazet
Comment 4 Dmitriy Balakin 2010-12-17 14:20:20 UTC
Patch has been committed to net-next-2.6 tree at upstream git. Commit bc2ce894e113ed95b92541134b002fdc641e8080

Note You need to log in before you can comment on or make changes to this bug.