> How about the following patch, which addresses the problem of using a
> bogus timestamp in PAWS as well (and also gets all the places where
> ts_present is set to 1 :-)

Hmm.  This doesn't seem quite right to me.

Now, I don't have the appropriate RFC's handy (I'm composing this
offline), but from looking at the code, it looks like the TCP
timestamp option contains two timestamps: one which is our timestamp
as echoed by the remote system, and the other is the remote system's
timestamp as echoed by us.

ts_recent is kept in the remote system's timebase.  If the remote
system doesn't echo a timestamp, but includes its own, then the
RFC1323 check for duplicate acks due to sequence space wraparound
would still seem to be valid.

Maybe there should be two different ts_present bits: one to indicate
presence of the ts_val (timestamp from the remote system), and one for
ts_ecr (our timestamp echoed by the remote system).

						- Bill