From owner-freebsd-bugs  Sun Aug 11 11:40: 7 2002
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 964DA37B400
	for <freebsd-bugs@hub.freebsd.org>; Sun, 11 Aug 2002 11:40:05 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 54F9E43E3B
	for <freebsd-bugs@hub.freebsd.org>; Sun, 11 Aug 2002 11:40:05 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
	by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7BIe5JU036993
	for <freebsd-bugs@freefall.freebsd.org>; Sun, 11 Aug 2002 11:40:05 -0700 (PDT)
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7BIe58v036990;
	Sun, 11 Aug 2002 11:40:05 -0700 (PDT)
Date: Sun, 11 Aug 2002 11:40:05 -0700 (PDT)
Message-Id: <200208111840.g7BIe58v036990@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
Cc: 
From: "G.P. de Boer" <g.p.de.boer@st.hanze.nl>
Subject: Re: kern/41552: TCP timers' sysctl's overflow
Reply-To: "G.P. de Boer" <g.p.de.boer@st.hanze.nl>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-bugs.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-bugs>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-bugs>
X-Loop: FreeBSD.org

The following reply was made to PR kern/41552; it has been noted by GNATS.

From: "G.P. de Boer" <g.p.de.boer@st.hanze.nl>
To: freebsd-gnats-submit@FreeBSD.org, g.p.de.boer@st.hanze.nl
Cc:  
Subject: Re: kern/41552: TCP timers' sysctl's overflow
Date: Sun, 11 Aug 2002 20:41:36 +0200

 Just a little follow-up to raise another issue. I was having growing amounts of
 TCP-connections which idled in the LAST_ACK state. They didn't timeout. I
 found somebody who had this problem on 4.2 and applied his patch to the 4.6.1
 source. That solved the issue.
 
 I looked at the tcp sources a bit, but since it's not really the easiest 
 protocol on
 earth I couldn't find out if there was already some kind of timeout for 
 LAST_ACK.
 My question: Does the problem with 'net.inet.tcp.keepidle' have as 
 side-effect that
 connections in LAST_ACK state never time out or is there another issue?
 I can't hardly believe there's no timeout for LAST_ACK anywhere, but just 
 curious.
 
 Here's a link to the original post about the LAST_ACK problem on 4.2:
 http://archives.neohapsis.com/archives/freebsd/2001-03/0363.html
 
 With regards,
 G.P. de Boer
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message