From owner-freebsd-isp Sun Jan 14 09:40:13 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13389 for isp-outgoing; Sun, 14 Jan 1996 09:40:13 -0800 (PST) Received: from cabal.io.org (cabal.io.org [198.133.36.103]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA13365 Sun, 14 Jan 1996 09:40:06 -0800 (PST) Received: (from taob@localhost) by cabal.io.org (8.6.12/8.6.12) id MAA01695; Sun, 14 Jan 1996 12:38:09 -0500 Date: Sun, 14 Jan 1996 12:38:07 -0500 (EST) From: Brian Tao To: Bill Fenner cc: Michael Smith , freebsd-hackers@freebsd.org, freebsd-isp@freebsd.org Subject: Re: A few other concerns from a FreeBSD ISP In-Reply-To: <96Jan10.155941pst.177478@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-isp@freebsd.org Precedence: bulk On Wed, 10 Jan 1996, Bill Fenner wrote: > > I have always thought that this situation could only be attributed to > one or the other end not waiting for 2*MSL before deleting connection > information. In particular, if the source end cut its TIME_WAIT state > short for some tcpcb, that port number could get reused while the > server end was still in TIME_WAIT and thus completely ignoring all > packets. Hmmmm, okay, whatever you say. ;-) > But I haven't yet gotten around to testing this theory; I can't say > that I recall seeing this problem, so it may also be load-related, > etc. I don't think it is. I've seen it happen to individual workstations as well as to shell servers with 100+ people on it. The really irritating thing is that it works *most* of the time, under either extreme of load condition. :( -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't"