Subject: small bug in BSD timestamp code

From: Mark Allman <[email-masked]>
Date: Mon, 13 Sep 1999 11:09:52 -0400

While poking into a problem we were having with an experimental
version of TCP I stubbled across what I think is a bug in the BSD
timestamp code.  I found the bug in NetBSD (and have reported it to
those folks), but it seems to be present in TCP/IP Illustrated,
Volume 2, so I assume that it might be in other systems and
therefore other folks might be interested, as well.

One instance of the problem appears on page 976 of TCP/IP
Illustrated, Volume 2 (although, there are probably others, but that
is left as an exercise).  As shown, if the timestamp option is
present in the received ACK an RTT sample is taken (and SRTT and
RTTVAR are updated).  However, I think a check is missing.  RFC 1323
states that if the timestamp received is zero it is invalid and
therefore should be ignored.  There is no check in the code for a
timestamp of zero.  So, if a zero is received the SRTT and RTTVAR
end up getting really hosed.

(Of course, the TCP that generated the zero timestamp was in error.
But, I believe that is a problem with the experimental kernel I have
been playing with.).

allman

---
http://roland.grc.nasa.gov/~mallman/

---

From: Thomas Skibo <[email-masked]>
Date: Mon, 13 Sep 1999 13:15:45 -0700

Ideally, the ECR should be ignored if it's zero because that's what the
other guy uses if he doesn't have a valid TS.recent (for a SYN or if
the "24 day connection" timeout occurred).  But, in all cases where
you're going to use an ACK to update the RTT (the ACK acks new data),
the peer ought to have a valid TS.recent from the segment for which
you're trying to get acknowledgement.

...unless there's some other way that TS.recent is discarded that I
can't remember.

-- 
Thomas Skibo		Juniper Networks, Inc.		[email-masked]