From aj@zadok.Ieunet.ie  Tue Oct 17 10:53:13 1995
Received: from pop.Ieunet.ie (zadok.Ieunet.ie [192.111.39.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA01838
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 17 Oct 1995 10:52:23 -0700
Received: by pop.Ieunet.ie (Smail3.1.29.1 #2)
	id m0t5GAy-000IFUC; Tue, 17 Oct 95 18:51 WET DST
Message-Id: <m0t5GAy-000IFUC@pop.Ieunet.ie>
Date: Tue, 17 Oct 95 18:51 WET DST
From: aj@Ieunet.ie (Alan Judge)
Sender: aj@zadok.Ieunet.ie (Alan Judge)
Reply-To: tech@Ieunet.ie
To: FreeBSD-gnats-submit@freebsd.org
Cc: tech@Ieunet.ie
Subject: 2.0.5-950622-SNAP tcp CLOSING/LAST_ACK problem (maybe fixed??)
X-Send-Pr-Version: 3.2

>Number:         784
>Category:       kern
>Synopsis:       TCP WWW connections seem to get stuck and never go away
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 17 11:00:01 PDT 1995
>Closed-Date:    Sat Nov 11 09:42:17 PST 1995
>Last-Modified:  Sat Nov 11 09:44:53 PST 1995
>Originator:     Alan Judge
>Release:        FreeBSD 2.0-BUILT-19950612 i386
>Organization:
Ieunet Ltd.
>Environment:

	We're running 2.0.5-950622-SNAP on a fairly busy web server,
	having just moved our primary web stuff over. 

>Description:
	The machine wedged earlier today, having running out of
	mbuf clusters (which I'll need to increase anyway).

	Having a snoop around, it would seem that some WWW connections
	with data queued are not going away after a dialup user
	hangs up.

	For example:
f072fc00 tcp        0   5270  192.111.39.241.80  138.220.76.189.130 CLOSING
f075c300 tcp        0  16384  192.111.39.34.8000 193.120.254.57.165 LAST_ACK

	Eventually this fills all the mbufs and everything stops.

>How-To-Repeat:

	Run a popular web server :-)  I'm sure that www.FreeBSD.org has
	hit similar problems.

>Fix:
	
	I've had a look at the sources and it would seem that keep alives
	have no effect here, as they are ignored if
		tp->t_state <= TCPS_CLOSE_WAIT

	However, from looking at the 2.1.0-951005-SNAP I see some
	interesting new code in tcp_timer.c.  Am I correct in
	thinking that the code that starts:
	       * Hack: if the peer is dead/unreachable, we do not
	       * time out if the window is closed.  After a full
	might fix the problem if pulled into my tcp_timers.c???
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: davidg 
State-Changed-When: Sat Nov 11 09:42:17 PST 1995 
State-Changed-Why:  
This bug was caused by the lack of timeouts in several important 
cases. It was fixed in rev 1.8 of tcp_timer.c and rev 1.17 of 
tcp_usrreq.c. 
>Unformatted:
