From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 20:32:24 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 72C111065673 for ; Tue, 6 Jul 2010 20:32:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 573118FC19 for ; Tue, 6 Jul 2010 20:32:23 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id ecb81e0081vN32cA1kYPXQ; Tue, 06 Jul 2010 20:32:23 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id ekYN1e00B3S48mS8ikYNBy; Tue, 06 Jul 2010 20:32:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5C1B39B425; Tue, 6 Jul 2010 13:32:22 -0700 (PDT) Date: Tue, 6 Jul 2010 13:32:22 -0700 From: Jeremy Chadwick To: Roland Smith Message-ID: <20100706203222.GA68830@icarus.home.lan> References: <20100705055105.GA21681@icarus.home.lan> <20100706174155.GA56410@slackbox.erewhon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100706174155.GA56410@slackbox.erewhon.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Max Laier , 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:32:24 -0000 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. 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. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |