RFC1323. No timestamping if SYN timestamp = 0. Bug or Feature?

Dear NetDev,

I have noticed that when my Windows XP PC makes a TCP connection to my Linux PC, the Windows PC sends a timestamp option with timestamp value 0 in the starting SYN- and linux seems to ignore this timestamp and does not communicate with timestamp option
for the rest of the connection. There appears to be code in the TCP_IPV4.C file which checks for this condition and ignores timestamps if rcv_tsval == 0.  I have included this code, as well as the TCP dump of this behaviour at the bottom.

a) Is there a reason why Linux should not do timestamps if timestamp value in SYN is zero?
b) Does this not cause problems with Windows and Linux RFC1323
compatibility? (It seems like windows sends timestamp 0 in SYN packet perhaps as a rule).
c) Can this test condition be removed without other consequences?

Indeed I removed the condition and then a Windows initiated connection was able to talk timestamps with Linux with no problems. Why do we need this (timestamp=0 in SYN) exclusion in the first place?

Thanks
Bartek Wydrowski


Kernel Code: in tcp_ipv4.c
----------------------------

if (tp.saw_tstamp && tp.rcv_tsval == 0) {
                /* Some OSes (unknown ones, but I see them on web server,
which
                 * contains information interesting only for windows'
                 * users) do not send their stamp in SYN. It is easy case.
                 * We simply do not advertise TS support.
                 */
                tp.saw_tstamp = 0;
                tp.tstamp_ok = 0;
}

TCPdump of this behaviour:
-----------------------------

windows XP Box > Linux Box 1991982409:199198240 9(0) win 64240 <mss
1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

Linux Box > windows XP Box S 2478701299:247870129 9(0) ack 1991982410 win
5840 <mss 1460,nop,nop,sackOK,nop,wscale 8> (DF)





---------------------------------
Yahoo! Personals
- New people, new possibilities. FREE for a limited time!

It is impossible to comply to RFC1323 if we allow TSval in the
initial SYN packet to be zero, from RFC1323:

         When TSecr is not valid, its value must be zero.

It is therefore impossible to accept TSval as zero, because
our TSecr echo of that timestamp would be also zero and thus
invalid.

That is why we reject zero timestamps in the initial SYN packet.

David S. Miller wrote:

It is impossible to comply to RFC1323 if we allow TSval in the
initial SYN packet to be zero, from RFC1323:

        When TSecr is not valid, its value must be zero.

It is therefore impossible to accept TSval as zero, because
our TSecr echo of that timestamp would be also zero and thus
invalid.

That is why we reject zero timestamps in the initial SYN packet.
 

Note that the text does not say "When TSecr is zero, it is invalid."  
You are reversing the conditional statement "not valid implies zero" to 
"zero implies not valid." I don't think that the intent of this text in 
the RFC is to forbid the use of zero as a timestamp, but only to assert 
that the value should be set to zero by default.

-- 
Casey Carter
Casey@Carter.net
ccarter@cs.uiuc.edu
AIM: cartec69