From owner-freebsd-stable@FreeBSD.ORG Mon Nov 19 20:37:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20C116A420; Mon, 19 Nov 2007 20:37:14 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6223613C46A; Mon, 19 Nov 2007 20:37:14 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 9299D1CD15; Mon, 19 Nov 2007 21:21:42 +0100 (CET) Date: Mon, 19 Nov 2007 21:21:42 +0100 From: Jan Srzednicki To: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Message-ID: <20071119202142.GI2045@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: pf(4) using inapropriate timeout values, 6.2-R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 20:37:14 -0000 Hello, I'm running pf(4) on a 6.2-RELEASE system. The problem occurs when on a TCP connection, one side sends a FIN (by issuing shutdown(SHUT_WR) on the socket), which is then ACK-ed properly. According to pf.conf(5), the connection should then be subject to tcp.closing timeout: tcp.closing The state after the first FIN has been sent. But, after testing, I have discovered that the connection is timeouted after tcp.finwait value: tcp.finwait The state after both FINs have been exchanged and the connec- tion is closed. Some hosts (notably web servers on Solaris) send TCP packets even after closing the connection. Increas- ing tcp.finwait (and possibly tcp.closing) can prevent block- ing of such packets. I'm positively sure it's precisely this value that timeouts this conection (which later on get state mismatches). Default tcp.closing value is quite big (15 minutes), while tcp.finwait ain't, and I have tuned tcp.finwait to a small value due to excesive number of short-lived connections I have running. This happens both with "keep state" and "modulate state". Is it some kind of a known issue? Is there any fix avalaible? I didn't test it on any other system than 6.2-R. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta