From owner-freebsd-net@FreeBSD.ORG  Mon Apr  5 12:32:43 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 F020116A4CE
	for <freebsd-net@freebsd.org>; Mon,  5 Apr 2004 12:32:43 -0700 (PDT)
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 812B343D4C
	for <freebsd-net@freebsd.org>; Mon,  5 Apr 2004 12:32:43 -0700 (PDT)
	(envelope-from berhart@erhartgroup.com)
Received: from cocaine.erhartgroup.com
	(c-67-166-0-138.client.comcast.net[67.166.0.138])
	by comcast.net (sccrmhc12) with SMTP
	id <20040405193242012002iicie>; Mon, 5 Apr 2004 19:32:42 +0000
Message-Id: <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com>
X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0
Date: Mon, 05 Apr 2004 13:32:49 -0600
To: Eli Dart <dart@nersc.gov>
From: Brandon Erhart <berhart@ErhartGroup.COM>
In-Reply-To: <20040405171756.90E3BF8F2@gemini.nersc.gov>
References: <20040405171756.90E3BF8F2@gemini.nersc.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
cc: freebsd-net@freebsd.org
Subject: Re: FIN_WAIT_[1,2] and LAST_ACK 
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Apr 2004 19:32:44 -0000

Well, I responded to the group that I had taken one of the fellows advice 
posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c.

So all is well -- it gets TCPS_CLOSED state and the tcps_close() function 
called on the tuple IMMEDIATELY. It doesn't switch states depending on 
which state the connection is currently in. I also made a sysctl variable 
for it (to turn the "feature" on or off), and will post the small patch 
along w/ some other small changes I have made soon.

Thanks,

Brandon

At 11:17 AM 4/5/2004, you wrote:

>In reply to Brandon Erhart <berhart@ErhartGroup.COM> :
>
> > Hello everyone,
>
> > However, I have run into a new problem. I am getting a good amount of
> > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a
> > long while.
>
>Could you define "long" in this case?  Are we talking about 60
>seconds, or 60 minutes?  I get the feeling that your requirements
>might make your perception of "long" different from others' notion of
>"long."
>
>The reason I ask is that there was a bug once upon a time that made
>some connections stick in LAST_ACK forever....
>
>                 --eli
>
>
>