Re: [RFC] tcp: allow timestamps even if SYN packet has tsval=0

[Eric Dumazet <dada1@cosmosbay.com>]

Ilpo Järvinen a écrit :
> On Fri, 13 Mar 2009, David Miller wrote:
> 
>> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
>> Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET)
>>
>>> On Wed, 11 Mar 2009, David Miller wrote:
>>>
>>>> From: Eric Dumazet <dada1@cosmosbay.com>
>>>> Date: Wed, 11 Mar 2009 13:17:54 +0100
>>>>
>>>>> So apparently WindowsXP sends a NULL tsval in SYN packet, then
>>>>> subsequent packets get a real value (60498) in this case.
>>>>>
>>>>> This seems to work on other OS as well, so is the following patch
>>>>> considered evil ?  Do we have security concerns or only risking
>>>>> windows client to have slightly wrong rtt estimation at the begining
>>>>> of the tcp session ?
>>>> I think we'll have to accept this.
>>>>
>>>> I don't see other systems blocking initial ts_ecn values of
>>>> zero like we do.
>>> What about the fact that PAWS could bite us leaving us a hung connection 
>>> if timestamp changes too much when we get the first ACK? Though I doubt 
>>> you can get windows to run long enough for this to become a problem if 
>>> they always start from zero... ;-)
>> I really don't think it's a real issue, and Windows XP should be happy
>> we're willing to try timestamps at all with it :-)
> 
> Right. Would it ever become a problem it would certainly possible to 
> collect the first real timestamp and discard the bogus zero. We just need 
> to be aware on this if some report about unable-to-connect appears once
> the change gets larger exposure in wild.
> 
> There could be other broken things such as firewalls zeroing it in SYNs 
> so the end host might not necessarily even be xp.
> 

If you believe this could cause unable-to-connect problem, we must revert the patch,
or implement your work-around :)

Thanks