From owner-cvs-all@FreeBSD.ORG Tue Apr 20 10:08:11 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 017AC16A4D7 for ; Tue, 20 Apr 2004 10:08:11 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 28D9A43D5A for ; Tue, 20 Apr 2004 10:08:10 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 46300 invoked from network); 20 Apr 2004 17:08:09 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 20 Apr 2004 17:08:09 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 20 Apr 2004 14:12:51 -0500 (CDT) From: Mike Silbersack To: Nate Lawson In-Reply-To: <20040420054638.E27872@root.org> Message-ID: <20040420141059.Q25391@odysseus.silby.com> References: <200404200633.i3K6XdXn067858@repoman.freebsd.org> <20040420032850.H20848@odysseus.silby.com> <20040420054638.E27872@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_subr.c tcp_var.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 17:08:11 -0000 On Tue, 20 Apr 2004, Nate Lawson wrote: > > I think that we may have to break away from standard RFC handling and > > change the TIME_WAIT code in tcp_input so that it will accept any SYN > > packet coming in without regard to the sequence number, forcing the > > TIME_WAIT socket to be recycled. > > It's been a while since I looked at all the RFCs, but can the window scale > option be taken into account for this? I'm thinking that if you receive a > packet while in TIME_WAIT with the proper window scale + sequence, accept > it, otherwise discard. As for initial sequences, make them less dependent > on port/address combos. Not sure if this will solve your problem. > > -Nate I don't see how the window scale option would change the situation at all. Making ISNs less dependent on the port/address pair isn't a solution either, their dependence on port/address is RFC1948's best property! In the face of high speed networks, we may just have to drop the check completely. Mike "Silby" Silbersack