Date: Tue, 20 Jan 2004 00:27:48 +0000 (GMT) From: Richard Wendland <richard@starburst.demon.co.uk> To: silby@silby.com (Mike Silbersack) Cc: freebsd-net@freebsd.org Subject: Re: forged tsecr giving -ve numbers in rtt calculation causing retran Message-ID: <200401200027.AAA09260@starburst.demon.co.uk> In-Reply-To: <20040119011745.D85911@odysseus.silby.com> from "Mike Silbersack" at Jan 19, 2004 01:21:01 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> Hm, wasn't this accounted for in rev 1.174 / 1.107.2.31? From Matt's > commit log: True. My notes must have been from an older version. Sorry. > Of course, that doesn't account for other non-zero strange values. I > guess the timestamp code needs a lot of work. :( This does suggest Ken is seeing TSecr messed up in some other way than simple zeroing. 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 -- Richard Wendland richard@wendland.org.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401200027.AAA09260>