From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:32:12 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 AC20516A4CE for ; Sun, 4 Apr 2004 15:32:12 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A12943D5A for ; Sun, 4 Apr 2004 15:32:12 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 13406 invoked from network); 4 Apr 2004 22:32:10 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 4 Apr 2004 22:32:10 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 4 Apr 2004 17:32:09 -0500 (CDT) From: Mike Silbersack To: Brandon Erhart In-Reply-To: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> Message-ID: <20040404172904.M33929@odysseus.silby.com> References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Sun, 04 Apr 2004 22:32:12 -0000 On Sun, 4 Apr 2004, Brandon Erhart wrote: > Hello everyone, > > I am writing a network application that mirrors a given website (such as a > suped-up "wget"). I use a lot of FDs, and was getting connect() errors when > I would run out of local_ip:local_port tuples. I lowered the MSL so that > TIME_WAIT would timeout very quick (yes, I know, this is "bad", but I'm > going for sheer speed here), and it alleviated the problem a bit. In 5.2, I added code which automatically recycles TIME_WAIT sockets so that this problem doesn't happen. That's one possible solution that that sub-problem, but as you've solved it with the msl change it's hardly a large enough reason to change. > 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. I have been unable to find must information on a timeout for > these states. I came across a small patch that modified tcp_timer.c in > /usr/src/sys/netinet. It changed line #484 (in FreeBSD 4.9-REL) from: If you can recreate this problem frequently, could you try capturing a connection "hanging" with tcpdump? Perhaps there is a problem in our TCP state engine that needs to be fixed. Mike "Silby" Silbersack