[pf4freebsd] Re: Bridging 2nd try and call for testers

Brandon Weisz brandon at mail.avioc.org
Wed Sep 15 20:49:36 PDT 2004


On Tue, 2003-09-02 at 08:37, Brandon Weisz wrote:
> On Mon, 2003-09-01 at 12:08, Max Laier wrote:
> 
> [.....]
> 
> > and try again to get pf running. Remember to set net.link.ether.bridge_ipf:
> > 1 This time it should at least see some packets ... or get a panic, not sure
> > about it ;)
> > 
> 
> Excellent.  My initial pass/block tests were successful. 

After pushing a good bit of traffic at it, I did manage to get a panic.

Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0xc
fault code		= supervisor read, page not present
instruction pointer	= 0x8:0xc0337380
stack pointer		= 0x10:00xd1ca7c64
frame pointer		= 0x10:0xd1ca7c7c
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 12 (swi1: net)
trap number		= 12
panic: page fault

I hand copied this as I didn't have serial console or any debugging
enabled.  Hopefully there aren't too many typos. 

I'll continue to test and see if I can reproduce this.  Some other
things I noticed:

With pf enabled, i start to occasionally see loops on the bridge:

-- loop (0) 00.08.74.9a.19.74 to xl1 from xl0 (active)

I know the kernel supports some primitive form of loop detection.  I
wasn't seeing these loops with pf disabled and only the bridge
operating.

Thanks again,

Brandon

> 
> I will continue testing with a more realistic ruleset, however this is
> quite promising.
> 
> > Thank you for your help.
> >     Max
> > 
> > 
> 
> 





More information about the freebsd-pf mailing list