[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20090901.154629.200974750.davem@davemloft.net>
Date: Tue, 01 Sep 2009 15:46:29 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: opurdila@...acom.com, themann@...ibm.com, netdev@...r.kernel.org,
raisch@...ibm.com
Subject: Re: TSecr != 0 check in inet_lro.c
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 25 Aug 2009 07:42:33 +0200
> Octavian Purdila a écrit :
>>
>> I'm failing to understand the purpose of this check. Any hints? :)
>>
>
> rfc1323 badly interpreted ?
>
> I remember tsecr=0 was forbidden by Linux, while apparently rfc is not
> so clear.
>
> rfc1323 : 3.2
> The Timestamp Echo Reply field (TSecr) is only valid if the ACK
> bit is set in the TCP header; if it is valid, it echos a times-
> tamp value that was sent by the remote TCP in the TSval field
> of a Timestamps option. When TSecr is not valid, its value
> must be zero. The TSecr value will generally be from the most
> recent Timestamp option that was received; however, there are
> exceptions that are explained below.
>
> Note how this is not saying "a zero Tsecr value is not valid"
Indeed this is a very tricky situation.
What it's saying here is that you can emit a zero TSecr when you
simply haven't received a valid timestamp from the peer yet.
I think we can therefore remove all of these special zero checks, but
we must be mindful to make sure we handle the connection startup case
properly (where we see these 'no valid timestamp yet' zero TSecrs).
--
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