8.0 network problem

Max Laier 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:
> 
> 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.


More information about the freebsd-stable mailing list