Re: A strange TCP timestamp problem?

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> How about using a cheap pseudo-random number generator seeded with 
> a fixed value?
That wouldn't work because it doesn't lead to values increasing over time.
I indeed thought about hashing uptime plus a random constant generated at boot.

There seem to be two uses of the timestamp: extend the range of sequence 
numbers by using (sequence number, timestamp value) pairs instead and 
introducing some notion of time (to measure RTTs, ordering packets and the 
like).

So to fulfil the some-notion-of-time part, you need to use uptime plus a 
constant offset. I guess OS L chose that constant to be zero, but I do 
understand the concern that the peer can deduce your uptime from that. So 
you can use a random constant instead, but then your peer can tell that you 
booted (because the timestamps don't increment nicely). If you use Real Time 
(at boot) for the constant offset, you defeat that. If your RTC is wrong, 
it's mostly OK because the only thing your peer can deduce is your RTC is 
wrong. If you don't have a RTC, use a random constant.

Let me repeat that it's most probably not the small value of the 
currently-used offset (1) causing the problem, but the repeated use of the 
same offset over long periods of time.

Any objections to the approach of using Real Time at boot (on the same scale 
as the actual increments) as an offset, or, lacking an RTC, a random value? 
I guess it would take someone with network stack knowledge some five to ten 
minutes to implement that, no?