|Summary:||Compatibility issue with uggly Windows RFC1323 implementation.|
|Product:||Networking||Reporter:||Dmitriy Balakin (dmitriy.balakin)|
|Component:||IPV4||Assignee:||Stephen Hemminger (stephen)|
It's a wrong patch
Capture session in libpcap format
Patch from Eric Dumazet
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