From owner-freebsd-bugs Fri Nov 1 01:10:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA10142 for bugs-outgoing; Fri, 1 Nov 1996 01:10:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA10134; Fri, 1 Nov 1996 01:10:02 -0800 (PST) Resent-Date: Fri, 1 Nov 1996 01:10:02 -0800 (PST) Resent-Message-Id: <199611010910.BAA10134@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, peter@spinner.DIALix.COM Received: from spinner.DIALix.COM (peter@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA09767 for ; Fri, 1 Nov 1996 01:06:04 -0800 (PST) Received: (from peter@localhost) by spinner.DIALix.COM (8.8.2/8.8.2) id RAA09028; Fri, 1 Nov 1996 17:06:00 +0800 (WST) Message-Id: <199611010906.RAA09028@spinner.DIALix.COM> Date: Fri, 1 Nov 1996 17:06:00 +0800 (WST) From: Peter Wemm Reply-To: peter@spinner.DIALix.COM To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1940: TCP doesn't time out of FIN_WAIT_1 and floods packets. Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1940 >Category: kern >Synopsis: TCP doesn't time out of FIN_WAIT_1 and floods packets. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 1 01:10:01 PST 1996 >Last-Modified: >Originator: Peter Wemm >Organization: not. >Release: FreeBSD 2.2-CURRENT i386 >Environment: Machine built from -current sources within the last week. The machine is running a web proxy server (squid-1.1.beta). >Description: An unusual jump in network outbound network traffic turned out to be caused by a -current machine with a stuck connection. The proxy server had initiated the connection: Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) [..] tcp 0 366 fermi.29485 kaos.http FIN_WAIT_1 [..] I am not sure of the sequence of events that lead to this getting in this state, but it was running this sequence of packets, even after squid had closed the connection (and even after having been killed): peter@fermi[8:27am]/home/squid-125# tcpdump -s 1500 -N tcpdump: listening on ed0 08:28:26.419290 kaos.http > fermi.29485: . ack 2272139 504 win 9112 (DF) 08:28:26.419459 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 (DF) 08:28:26.426922 kaos.http > fermi.29485: . ack 1 win 9112 (DF) 08:28:26.427038 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 (DF) 08:28:26.435747 kaos.http > fermi.29485: . ack 1 win 9112 (DF) 08:28:26.435877 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 (DF) 08:28:26.445638 kaos.http > fermi.29485: . ack 1 win 9112 (DF) 08:28:26.445750 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 (DF) 08:28:26.454399 kaos.http > fermi.29485: . ack 1 win 9112 (DF) 08:28:26.454548 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 (DF) [...] I presume this is a half-close, what is meant to happen here? >How-To-Repeat: Unknown, but I hope it doesn't.. :-] >Fix: It seems that the tcp connection managed to get into a state where both ends were out of sync. I don't know my tcp states well enough to understand what is meant to happen here, but hanging in FIN_WAIT_1 forever doesn't seem nice. >Audit-Trail: >Unformatted: