machine locks with PF (without using user dependent rules)

Mon Feb 7 07:52:43 PST 2005

Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier:
> On Saturday 08 January 2005 17:52, Robert Watson wrote:
> > On Sat, 8 Jan 2005, Harald Schmalzbauer wrote:
> > > my machine hard locks with the attached ruleset.  If I set
> > > debug.mpsafenet to 0 everything is fine. This was a wild guess from me,
> > > I could nowhere find the info that PF needs this tweaking and I think
> > > it's not intended, otherwise it would be done in rc.conf e.g.
>
> Yes, it is not intended.  Please keep in mind that debug.mpsafenet cannot
> be alterted at runtime, hence rc.conf would be too late anyway.  Just
> making that clear.
>
> > > I read about user depending rules in IPFW and that one has to disable
> > > mpsafenet, but I'm not using user based rules in my PF config!
> > > Unfortunately this machine is a CF-Card based Router wher I cannot
> > > debug anything, perhaps I can bring a witness-kernel on it, please tell
> > > me if this problem is new to you and if I should do that.
> >
> > I've CC'd Max Laier due to his extensive work with pf on FreeBSD.  I
> > think a WITNESS+INVARIANTS kenrel would be quite helpful, if you could.
>
> Yes, WITNESS would be interesting, though I don't expect to see any LORs,
> as this is not an overly complicated ruleset.  Actually, I am very
> surprised that it does lock up - what hardware is this?

Resuming work on this, I managed to get a remote console to the box and here's 
what I get with today's RELENG_5 and the following command, also I need to 
set debug.mpsafenet to 0 otherwise my ruleset doesn't work (do what it should 
do and does when set to 0 but not when default 1):
pfctl -F all -f /etc/pf.conf

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc1d7
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc047ac48
stack pointer           = 0x10:0xd0a44728
frame pointer           = 0x10:0xd0a44730
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1053 (sshd)
[thread pid 1053 tid 100081 ]
Stopped at      pf_state_compare_lan_ext+0x18:  movzbl  0xf9(%esi),%eax
db> trace
Tracing pid 1053 tid 100081 td 0xc177e190
pf_state_compare_lan_ext(c176ca00,d0a447d8,d0a44758,c047c095,c176cac0) at 
pf_state_compare_lan_ext+0x18
pf_state_tree_lan_ext_RB_FIND(c176cac0,d0a447d8,0,c176ca00,d0a448e4) at 
pf_state_tree_lan_ext_RB_FIND+0x29
pf_find_state_recurse(c176ca00,d0a447d8,0,da7a0000,c0586400) at 
pf_find_state_recurse+0x45
pf_test_state_tcp(d0a4492c,2,c176ca00,c1746b00,14) at pf_test_state_tcp+0xb0
pf_test(2,c1586000,d0a44a1c,c19ff168,c1756720) at pf_test+0x981
pf_check_out(0,d0a44a1c,c1586000,2,c19ff168) at pf_check_out+0x4e
pfil_run_hooks(c07f05a0,d0a44aa8,c1586000,2,c19ff168) at pfil_run_hooks+0x15b
ip_output(c1746b00,0,d0a44a74,0,0) at ip_output+0x3ef
tcp_output(c1a02710,c1744900,c076ed93,280,0) at tcp_output+0x984
tcp_usr_send(c1b5fdec,0,c1744900,0,0) at tcp_usr_send+0x239
sosend(c1b5fdec,0,d0a44c84,c1744900,0) at sosend+0x62b
soo_write(c1c5c264,d0a44c84,c1b0f680,0,c177e190) at soo_write+0x49
dofilewrite(5,8081000,a0,ffffffff,ffffffff) at dofilewrite+0xac
write(c177e190,d0a44d14,c,431,3) at write+0x77
syscall(2f,2f,2f,8071d88,a0) at syscall+0x137
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0x282ef73f, esp = 0xbfbfddfc, ebp 
=0xbfbfde18 ---

Tell me how I can help, I'll later hand in the trace of the slef-lock when 
debug.mpsafenet is 1.

-Harry
>
> What version of FreeBSD are you running?  RELENG_5_3?  Could you try to
> move `src/sys/contrib/pf' to RELENG_5 instead.  There are some bugfixes in
> there, that might help you.  Specificly there was an endless loop in the
> state matching code.  Please tell me if that helped.
>
> > > Best regards,
> > >
> > > -Harry
> > >
> > > pf.conf: (note that the interface names are changed, so fxp0 is SDSL
> > > e.g.)
> > >
> > > lan_net="172.23.0.0/16"
> > > by_net="192.168.0.0/24"
> > > sdsl_net="a.b.c.d/29"
> > >
> > > sdsl_addr="a.b.c.d"
> > > lan_addr="172.23.0.1"
> > > #pppoe_addr="10.0.0.1"
> > > by_addr="192.168.0.1"
> > >
> > > proxy="a.a.a.a"
> > > mta="b.b.b.b"
> > > dns="c.c.c.c"
> > > web="d.d.d.d"
> > > dns2="10.0.0.2"
> > >
> > > set block-policy return
> > > scrub in all
> > >
> > > nat on SDSL from $lan_net to !$sdsl_net  -> $sdsl_addr
> > > rdr inet proto tcp from 62.245.232.135 to $sdsl_addr port 3389 ->
> > > 172.23.2.1 port 3389
> > > block in all
> > > block out all
> > > pass in on lo0 all
> > > pass out on lo0 all
> > > pass in on LAN from $lan_net to any keep state
> > > pass in on SDSL from 62.245.232.135 to any keep state
> > > pass in on SDSL proto tcp from any to $proxy port { 22, 80, 443 } keep
> > > state pass in on SDSL proto tcp from any to $mta port 25 keep state
> > > pass in on SDSL proto { udp, tcp } from any to $dns port 53 keep state
> > > pass in on SDSL proto tcp from any to $web port { 80, 443 } keep state
> > >
> > > pass out on SDSL from $sdsl_net keep state
> > > pass out on LAN from $lan_addr to $lan_net keep state
> > >
> > > P.S.: Why do I need the second line with the following rule? Shouldn't
> > > the 'keep state' open the internal interface for outgoing packets from
> > > the given IP?
> > > pass in on SDSL from 62.245.232.135 to any keep state
> > > pass out on LAN from 62.245.232.135 to 172.23.2.1
>
> For the normal forwarding path that's true, but not for the RDR case.  You
> can use "rdr pass" to circumvent this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050207/7c9fa812/attachment.bin