[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