>Number:         18677
>Category:       kern
>Synopsis:       TCP timestamp option (RFC1323) mishandled in NetBSD 1.6
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 16 19:33:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Richard Wendland
>Release:        NetBSD 1.6
>Organization:
>Environment:
>Description:
NetBSD 1.6 appears to mishandle RFC1323 TCP timestamp option
processing on passive opens (server side).

When offered a TCP timestamp on a SYN, opening a TCP connection,
NetBSD 1.6 responds with a zero timestamp on SYN-ACK, agreeing the
option, but does not send any more timestamps on later TCP segments.
This is almost certainly not intended behaviour, and defeats
the purpose of agreeing the option. It is not intended RFC1323
behaviour, though may not be a technical infringement.
Sending a zero timestamp on SYN-ACK is unusual behaviour,
different from previous versions of NetBSD.

I am not a NetBSD user, and have only noticed this behaviour
remotely, with connections from a different OS.  I have noticed
this behaviour with www.se.netbsd.org and webmail.turbocat.de,
which I believe are running NetBSD 1.6, though cannot be certain
of that.  This problem needs to be verified.

>How-To-Repeat:
While running `tcpdump -n -s 120 host www.se.netbsd.org' on a RFC1323
capable OS make a HTTP HEAD request to www.se.netbsd.org, eg by:

% telnet www.se.netbsd.org 80
HEAD / HTTP/1.1
Host: www.se.netbsd.org
Connection: close

[HTTP response]

Doing that on a FreeBSD 4.6-RELEASE system gives the following
tcpdump trace (195.92.95.37 is FreeBSD, 213.179.7.206 is www.se.netbsd.org):

02:36:08.219512 195.92.95.37.2234 > 213.179.7.206.80: S 1234992940:1234992940(0) win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 471860816 0> (DF)
02:36:08.290157 213.179.7.206.80 > 195.92.95.37.2234: S 160806593:160806593(0) ack 1234992941 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 471860816> (DF)
02:36:08.290213 195.92.95.37.2234 > 213.179.7.206.80: . ack 1 win 33304 <nop,nop,timestamp 471860823 0> (DF)
02:36:13.019364 195.92.95.37.2234 > 213.179.7.206.80: P 1:18(17) ack 1 win 33304 <nop,nop,timestamp 471861296 0> (DF)
02:36:13.289594 213.179.7.206.80 > 195.92.95.37.2234: . ack 18 win 17520 (DF)
02:36:13.289629 195.92.95.37.2234 > 213.179.7.206.80: P 18:64(46) ack 1 win 33304 <nop,nop,timestamp 471861323 0> (DF)
02:36:13.362162 213.179.7.206.80 > 195.92.95.37.2234: P 1:251(250) ack 64 win 17520 (DF)
02:36:13.362209 213.179.7.206.80 > 195.92.95.37.2234: F 251:251(0) ack 64 win 17520 (DF)
02:36:13.362240 195.92.95.37.2234 > 213.179.7.206.80: . ack 252 win 33054 <nop,nop,timestamp 471861330 0> (DF)
02:36:13.362886 195.92.95.37.2234 > 213.179.7.206.80: F 64:64(0) ack 252 win 33304 <nop,nop,timestamp 471861330 0> (DF)
02:36:13.428336 213.179.7.206.80 > 195.92.95.37.2234: . ack 65 win 17520 (DF)
02:36:13.432049 213.179.7.206.80 > 195.92.95.37.2234: . ack 65 win 17520 (DF)
02:36:13.432083 195.92.95.37.2234 > 213.179.7.206.80: R 1234993005:1234993005(0) win 0 (DF)

NB An additional small issue is why NetBSD ACKs the FreeBSD FIN
twice?

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: