From owner-freebsd-stable@FreeBSD.ORG Tue Nov 20 09:50:52 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 05BB516A46C; Tue, 20 Nov 2007 09:50:52 +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 B50C113C4BE; Tue, 20 Nov 2007 09:50:51 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id C1DAE1CCCC; Tue, 20 Nov 2007 10:50:41 +0100 (CET) Date: Tue, 20 Nov 2007 10:50:41 +0100 From: Jan Srzednicki To: Daniel Hartmeier Message-ID: <20071120095041.GJ2045@oak.pl> References: <20071119202142.GI2045@oak.pl> <20071120065334.GJ29432@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071120065334.GJ29432@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org, freebsd-pf@freebsd.org Subject: Re: 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: Tue, 20 Nov 2007 09:50:52 -0000 On Tue, Nov 20, 2007 at 07:53:34AM +0100, Daniel Hartmeier wrote: > On Mon, Nov 19, 2007 at 09:21:42PM +0100, Jan Srzednicki wrote: > > > I'm positively sure it's precisely this value that timeouts this > > conection (which later on get state mismatches). > > What does pfctl -vvss show for such a state entry, in particular the > right-most part of the first line ("ESTABLISHED:ESTABLISHED" while the > connection is still fully established, etc.)? OK, here it comes. This is the connection before sending the one-side FIN: self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829 ESTABLISHED:ESTABLISHED [390096685 + 66608] wscale 1 [3173293905 + 65537] wscale 1 age 00:00:00, expires in 24:00:00, 2:1 pkts, 116:64 bytes, rule 30 id: 47207d980002e600 creatorid: 082298e6 self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525 ESTABLISHED:ESTABLISHED [3173293905 + 65537] wscale 1 [390096685 + 66608] wscale 1 age 00:00:00, expires in 24:00:00, 2:1 pkts, 116:64 bytes, rule 30 id: 47207d980002e5ff creatorid: 082298e6 (they're both on the same host) Now the client sends FIN: 10:39:30.008969 IP MY_IP_HERE.64829 > MY_IP_HERE.12525: F 222:222(0) ack 1 win 33304 10:39:30.009008 IP MY_IP_HERE.12525 > MY_IP_HERE.64829: . ack 223 win 33304 And the state becomes: self tcp MY_IP_HERE:12525 <- MY_IP_HERE:64829 ESTABLISHED:FIN_WAIT_2 [390096685 + 66608] wscale 1 [3173294128 + 66608] wscale 1 age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30 id: 47207d980002e600 creatorid: 082298e6 self tcp MY_IP_HERE:64829 -> MY_IP_HERE:12525 FIN_WAIT_2:ESTABLISHED [3173294128 + 66608] wscale 1 [390096685 + 66608] wscale 1 age 00:00:04, expires in 00:00:05, 4:3 pkts, 441:168 bytes, rule 30 id: 47207d980002e5ff creatorid: 082298e6 Timeout values: # pfctl -s timeout No ALTQ support in kernel ALTQ related functions disabled tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 5s tcp.closed 10s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s > Does it matter which side of the connection (the client or the server) > half-closes the connection? Nope, this happens on both sides. > It's possible that there's a bug in mapping the timeout, I'll check. Thx. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta