forged tsecr giving -ve numbers in rtt calculation causing retran

[Mike Silbersack]

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 :)
>
> 	Richard

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