Re: A strange TCP timestamp problem?

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

We seem to get bitten by the same problem when accessing web sites hosted 
by the university's central IT through our proxy server.
It looks like some hitherto unidentified component there gets taken aback 
by repeated SYNs with tsval=1 and keeps dropping them.

> The question is, is rejecting the packet based on tsval = 1 a reasonable 
> behavior?
As the issue is probably something along the lines of NetBSD vs. Well Know 
Network Component Supplier C, the question whether C's behaviour is resonable 
is of secondary interest.
Our impression is also that it's not just sending SYNs with tsval=1 causing 
the other side to drop but repeatedly doing so from the same IP in a short 
time frame causing the drops. If we re-direct traffic to our backup proxy 
server, everything works fine for a while, but only for a while.

I understand the argument against sending something based on uptime instead. 
What about sending something based on real time instead? I have no idea which 
timers are available in the network stack at which cost, but in case it's 
unfeasable to use real time directly, one could sample real time at boot 
(initialisation) and use that as an offset, no? I thought of using a random 
offset determined at boot, but then the other side could at least identify 
re-boots (because the values don't increment nicely).