From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 09:10:26 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 7A42F16A4CE for ; Tue, 6 Apr 2004 09:10:26 -0700 (PDT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 192D243D46 for ; Tue, 6 Apr 2004 09:10:26 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040406160912.PLEB27801.out008.verizon.net@mac.com>; Tue, 6 Apr 2004 11:09:12 -0500 Message-ID: <4072D627.9060909@mac.com> Date: Tue, 06 Apr 2004 12:09:11 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Erhart References: <20040405171756.90E3BF8F2@gemini.nersc.gov> <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> <4071D923.A7E0D93F@freebsd.org> <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com> In-Reply-To: <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [68.160.247.127] at Tue, 6 Apr 2004 11:09:11 -0500 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: Tue, 06 Apr 2004 16:10:26 -0000 Brandon Erhart wrote: > They are not timing out after 2MSL. I set my MSL to the lowest possible > setting (10) as to make TIME_WAIT connections disappear. The > FIN_WAIT_[1,2] and LAST_ACK seem to be sticking around for a while. > However, not ALL of them stick around for a "long time"(more on this in > a sec) -- e.g., after I kill my program, and say I've got 6,000 > connections sitting in FIN_WAIT_[1,2] or LAST_ACK, about a minute > afterwards 90% of them have disappeared. There seem to be a few stick > around for as long as 30 minutes or more, and in fact, a few of them > stuck around until I rebooted the computer. People are starting to set up honeynets or tarpits which will "persist capture" TCP connections "forever" by responding with a zero window size. Such things slow down the spread of worms/virii effectively, but they also make nmap or other scanning tools (perhaps Brandon's) unhappy. It might be interesting to retest one of these stuck connections by hand and see whether the remote machine generates a normal response. -- -Chuck