From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 13:28:08 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 12EA716A4E2 for ; Mon, 5 Apr 2004 13:28:08 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81AC943D5F for ; Mon, 5 Apr 2004 13:28:02 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <200404052028010130013u80e>; Mon, 5 Apr 2004 20:28:01 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA22684; Mon, 5 Apr 2004 13:28:00 -0700 (PDT) Date: Mon, 5 Apr 2004 13:27:58 -0700 (PDT) From: Julian Elischer To: Eli Dart In-Reply-To: <20040405201050.D5B2EF8F2@gemini.nersc.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brandon Erhart 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 20:28:08 -0000 On Mon, 5 Apr 2004, Eli Dart wrote: > > In reply to Brandon Erhart : > > > 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. > > > I understand that -- I was trying to discover if you'd come across > something that needed a more general fix (see note from Mike > Silbersack). If your application can't wait for whatever the > standard timeout is, that's fine -- you've got your fix, and you're > good to go. However, if there is a problem with connections hanging > out forever in the process of closing, that something that might be > good to look at independently. > > So, do you remember how long the "problem connections" were sticking > around in FIN_WAIT_? or LAST_ACK? Are we talking seconds, minutes, > hours, days? > > Thanks, On the topic of Session shutdown... I have noticed an increasing number of machines on the net are terminating their session (usually the server, but not always) with a RESET packet instead of a FIN packet. In particular it seems that if the machine in question recieves a FIN packet, and has no more data to send, it replies with a RESET. I don't know what kind of machines this is but next time I see it I guess I'll look at it harder. Julian