From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 05:35:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E9210656BF for ; Fri, 1 Aug 2008 05:35:28 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 9637B8FC15 for ; Fri, 1 Aug 2008 05:35:27 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 13539 invoked from network); 1 Aug 2008 05:08:46 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 1 Aug 2008 05:08:46 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 1 Aug 2008 00:08:38 -0500 (CDT) From: Mike Silbersack To: ticso@cicely.de In-Reply-To: <20080718135931.GA48087@cicely7.cicely.de> Message-ID: References: <20080718135931.GA48087@cicely7.cicely.de> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: TCP zombie connections with 7-RELEASE and STABLE from 15th june X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 05:35:28 -0000 On Fri, 18 Jul 2008, Bernd Walter wrote: > 443 is a self written server, but it also happens with port 80 and > sslproxy. > The client is a telnet, which disconnects directly after connecting, > so the disconnect is initiated from the client, which seems to be > important for this problem to trigger. > > You can see that the FIN handshake completes and netstat on the > client box shows the connection in TIME_WAIT. > The server however has the connection still in ESTABLISHED state. Well, syncookies allow the ack of the 3WHS to establish a connection. Just a quick look at your tcpdump shows that since you aren't sending any data you are not advancing the sequence number. As a result, it looks like one of the ACKs the client sends during connection shutdown may actually be causing the server to re-establish the connection. You might want to file a PR with exact instructions (and code) that'll easily reproduce this so that it can be solved at some point in the future. I don't have time to look into it now, although I'd be happy to code review a fix! -Mike