From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 20:48:51 2010 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 182E4106566C for ; Tue, 6 Jul 2010 20:48:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4728FC1A for ; Tue, 6 Jul 2010 20:48:50 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-066-042-254.pools.arcor-ip.net [88.66.42.254]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MHKSt-1OIEZS0BbH-00EBZb; Tue, 06 Jul 2010 22:48:45 +0200 From: Max Laier Organization: FreeBSD To: Jeremy Chadwick Date: Tue, 6 Jul 2010 22:48:42 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.1-RC2; KDE/4.4.4; amd64; ; ) References: <20100706174155.GA56410@slackbox.erewhon.net> <20100706203222.GA68830@icarus.home.lan> In-Reply-To: <20100706203222.GA68830@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007062248.42720.max@love2party.net> X-Provags-ID: V02:K0:xtIlAx3+7lx0F1KH1jUg4TbnfqEMc4k3EvYBN8OT/xe 7tD8uVghiI1SKm07/0qzWuQv13ZhqddXL6shBrLAIt79GDDZDB XInV+zEEq2jjwZ27izdUUYKGMxFNXvyIfAeBn5DoM2NbaTUipF /vJZiXngwFAreLunc2K2nZ/UVfDjX7EHNEjjnSDawKdSnAJbtG 9zMk+4bn2oe1PmopVUA9g== Cc: Roland Smith , David Warren , freebsd-stable@freebsd.org Subject: Re: 8.0 network problem 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, 06 Jul 2010 20:48:51 -0000 On Tuesday 06 July 2010 22:32:22 Jeremy Chadwick wrote: > Adding Max Laier (maintainer of pf) to the CC list. He may have some > ideas as to what's causing this. Max, relevant thread details: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057586.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057597.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057602.html > > The last link above indicates the OP gets decent transfer rates with pf > disabled, and includes his pf.conf. Please check "pfctl -si" esp. "state-mismatch" This is always the first indication that something is wrong. In addition you can set a higher pf debugging level (pfctl -xm) in order to get more information on the issue - if the cause is indeed a state mismatch. > On Tue, Jul 06, 2010 at 07:41:55PM +0200, Roland Smith wrote: > > On Tue, Jul 06, 2010 at 01:06:25AM -0500, David Warren wrote: > > > pass out keep state > > > > I think keeping state is the default now. > > It is, but it's worth going over the "history" just so people > understand. I've been schooled on this in the past, but I'm still going > off of memory so if someone knows otherwise please chime in. > > In 7.2 and earlier (I could have the version numbers wrong, but > 7.3-PRERELEASE doesn't require this), you had to explicitly state "keep > state flags S/SA" on TCP traffic, and "keep state" on UDP/ICMP traffic. > This is because said version(s) use older and newer pf, respectively. > > So in the OP's case, the above rule on an older OS would cause mayhem > (excessive states being created for TCP, and improperly at that (any > outbound TCP packet, rather than ones with only SYN set when looking at > only SYN & ACK)). > > In 7.3 and later (including 8.x and onward), the "keep state" parameter > isn't needed; it's explicitly applied unless you use "no_state". pf > also intelligently figures out when to use "flags S/SA" (e.g. for TCP > rules). For example, the following pf.conf rule (notice that there's no > protocol defined): > > pass in quick on em0 inet from any to 1.2.3.4 keep state > > Gets turned into: > > pass in quick on em0 inet from any to 1.2.3.4 flags S/SA keep state > > And "does the right thing" even with UDP/ICMP traffic where there's no > stateful flags involves. Meaning, the "flags S/SA" part applies to any > inbound TCP, and isn't used for other protocols. > > Back to the problem at hand: > > I wonder if it's lack of "quick" on some rules which is causing the > problem; hard to say, and I'm not sure how to "benchmark" pf. > > Furthermore, remember that the OP can move to another NIC and the > problem goes away[1]. I know there have been issues in the past > reported with em(4) and pf ALTQ, but that isn't in use here. > > > > [1]: I assume the OP is updating pf.conf to specify the changed > interface and so on; if not, then I imagine it would be as effective as > disabling pf (thus "it's fast when I use something other than em0" would > be inaccurate). I simply don't know.