Ah-hah! I was thinking of that.  I was playing around with sysctl earlier today and
changing net.inet.tcp.rfc1323 to 1 and then to 0 again.  But it really didn't make a
difference to Netcraft.  I guess it's not a big deal; if it makes uptimes harder to
predict, it's a good thing.

Cheers

(PS, am I seeing double, or are you also on the squirrelmail mailinglist?  Or maybe my
mail filters are messed up)

> It was a bug in the RFC1323 timestamp stuff that the uptime was
> predictable remotely... the commit message for rev 1.123 of
> sys/netinet/tcp_input.c says:
>
> Two changes, designed to make us even more resilient against TCP
> ISS attacks (which we already fend off quite well).
>
> 1. First-cut implementation of RFC1948, Steve Bellovin's cryptographic
>   hash method of generating TCP ISS values.  Note, this code is experimental and
>   disabled by default (experimental enough that I don't export the variable via
>   sysctl yet, either).  There are a couple of issues I'd like to discuss with
>   Steve, so this code should only be used by people who really know what they're
>   doing.
>
> 2. Per a recent thread on Bugtraq, it's possible to determine a system's
>   uptime by snooping the RFC1323 TCP timestamp options sent by a host; in 4.4BSD,
>   timestamps are created by incrementing the tcp_now variable at 2 Hz; there's
>   even a company out there that uses this to determine web server uptime.
>   According to Newsham's paper "The Problem With Random Increments", while
>   NetBSD's TCP ISS generation method is much better than the "random increment"
>   method used by FreeBSD and OpenBSD, it is still theoretically possible to mount
>   an attack against NetBSD's method if the attacker knows how many times the
>   tcp_iss_seq variable has been incremented.  By not leaking uptime information,
>   we can make that much harder to determine.  So, we avoid the leak by giving
>   each TCP connection a timebase of 0.