8.0 network problem
max at love2party.net
Tue Jul 6 20:48:51 UTC 2010
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:
> 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 220.127.116.11 keep state
> Gets turned into:
> pass in quick on em0 inet from any to 18.104.22.168 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. I know there have been issues in the past
> reported with em(4) and pf ALTQ, but that isn't in use here.
> : 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.
More information about the freebsd-stable