From owner-freebsd-net@FreeBSD.ORG Mon Jan 19 16:26:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B15816A4CE for ; Mon, 19 Jan 2004 16:26:13 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-240.abel.net.uk [193.109.51.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78DE143D1D for ; Mon, 19 Jan 2004 16:26:10 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id AAA09260; Tue, 20 Jan 2004 00:27:49 GMT From: Richard Wendland Message-Id: <200401200027.AAA09260@starburst.demon.co.uk> To: silby@silby.com (Mike Silbersack) Date: Tue, 20 Jan 2004 00:27:48 +0000 (GMT) In-Reply-To: <20040119011745.D85911@odysseus.silby.com> from "Mike Silbersack" at Jan 19, 2004 01:21:01 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Ken Faiczak cc: freebsd-net@freebsd.org Subject: Re: forged tsecr giving -ve numbers in rtt calculation causing retran X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@wendland.org.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 00:26:13 -0000 > 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