forged tsecr giving -ve numbers in rtt calculation causing
silby at silby.com
Wed Jan 21 00:50:17 PST 2004
On Tue, 20 Jan 2004, Richard Wendland wrote:
> This does suggest Ken is seeing TSecr messed up in some other way than
> simple zeroing.
Or working from an old codebase... we'll have to wait for him to respond
to find out. KEN! KEN! WHERE ARE YOOOOOO?
> I'd expect this to be a pretty rare event, and perhaps my suggestion
> that the 64 sec TCPTV_REXMTMAX limit be implemented correctly is a
> good enough solution on its own for a rare event. It should certainly
> avoid the insane -450000000 tp->t_rxtcur Ken has seen. It's simple to
> implement, does what was probably originally intended, and also protects
> from bizarre problems with non-timestamp option SRTT calculation.
> Full validation of TSecr would be nice, but perhaps excessive for
> something that should not happen. A 64 second RTO may discourage such
> strangeness :)
I think that just ensuring proper capping of the timeout is good enough,
the other timestamp issue I was referring to is how it (incorrectly)
scales with hz. I think I'll take a look at both of these problems once I
catch up on other patches I have in the pipeline.
Mike "Silby" Silbersack
More information about the freebsd-net