Re: machine locks with PF (without using user dependent rules)
Am Dienstag, 8. Februar 2005 14:18 schrieb Max Laier: > On Monday 07 February 2005 16:52, Emanuel Strobl wrote: [...] > Do you have pfsync compiled in? Is it up? If that's the case, can you try No, I don't have pfsync in the kernel, also I don't have modules on that box. > to reproduce with a kernel without "device pfsync", please? Can you also > please try the attached diff and see if it turns up anything - though I > certainly doubt that. Really except to see pfsync being the culprit here. I tried your patch, no changes. I can panic the box with "pfctl -F all -f /etc/pfconf" regardless of the debug.mpsafenet state. But I don't get any panics with debug.mpsafenet=1 while normal operating. And I also cannot see any rule behaviour difference any more. For now it looks to me as if it's only the pfctl command which can panic the box, but I'll see the next days. Here is the latest traceback with your patch: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b748 stack pointer = 0x10:0xcc6948fc frame pointer = 0x10:0xcc694904 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax db> trace Tracing pid 35 tid 100031 td 0xc1515190 pf_state_compare_ext_gwy(c17ed000,cc6949ac,cc69492c,c047c2f2,c17ed0c4) at pf_state_compare_ext_gwy+0x18 pf_state_tree_ext_gwy_RB_FIND(c17ed0c4,cc6949ac,0,c17ed000,cc694ab8) at pf_state_tree_ext_gwy_RB_FIND+0x29 pf_find_state_recurse(c17ed000,cc6949ac,1,c1045ae0,c1743300) at pf_find_state_recurse+0x72 pf_test_state_tcp(cc694b00,1,c17ed000,c18aaa00,14) at pf_test_state_tcp+0xb0 pf_test(1,c1585800,cc694bf0,0,c174d260) at pf_test+0x981 pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48 pfil_run_hooks(c07edc20,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b ip_input(c18aaa00,0,c0768929,e6,c07edce0) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c2ca0,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c075d0e9,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c075ceca,31e,0) at ithread_loop+0x1ff fork_exit(c055d000,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- > I'm a bit busy these days so I can't do extensive testing myself. It'd be > a great help if you could verify that I am looking at the right thing. Feel free to ask me whaetever you want me to do, at the moment I have the machine semiproductive and spare time :) Just lacking hacking knowledge :( -Harry pgpvqBGWymdd0.pgp Description: PGP signature
Re: machine locks with PF (without using user dependent rules)
On Monday 07 February 2005 16:52, Emanuel Strobl wrote:
> 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 0xf, 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,da7a,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,,) 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.
Do you have pfsync compiled in? Is it up? If that's the case, can you try to
reproduce with a kernel without "device pfsync", please? Can you also please
try the attached diff and see if it turns up anything - though I certainly
doubt that. Really except to see pfsync being the culprit here. Tell me if
removeing it helps. Thanks.
I'm a bit busy these days so I can't do extensive testing myself. It'd be a
great help if you could verify that I am looking at the right thing.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.26
diff -u -r1.26 pf.c
--- pf.c 20 Jan 2005 18:07:35 - 1.26
+++ pf.c 8 Feb 2005 13:10:32 -
@@ -862,6 +862,7 @@
{
struct pf_src_node *cur, *next;
+ PF_ASSERT(MA_OWNED);
for (cur = RB_MIN(pf_src_tree, &tree_src_tracking); cur; cur = next) {
next = RB_NEXT(pf_src_tree, &tree_src_tracking, cur);
@@ -889,6 +890,7 @@
{
u_int32_t timeout;
+ PF_ASSERT(MA_OWNED);
if (s->src_node != NULL) {
if (--s->src_node->states <= 0) {
timeout = s->rule.ptr->timeout[PFTM_SRC_NODE];
@@ -923,6 +925,7 @@
{
struct pf_state *cur, *next;
+ PF_ASSERT(MA_OWNED);
for (cur = RB_MIN(pf_state_tree_id, &tree_id);
cur; cur = next) {
next = RB_NEXT(pf_state_tree_id, &tree_id, cur);
pgpvd39NW0YEk.pgp
Description: PGP signature
Re: PANIC: Re: machine locks with PF (without using user dependent rules)
Am Montag, 7. Februar 2005 17:32 schrieb Emanuel Strobl: > Am Montag, 7. Februar 2005 16:52 schrieb Emanuel Strobl: > > 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 > > [...] > > > Tell me how I can help, I'll later hand in the trace of the slef-lock > > when debug.mpsafenet is 1. > > Like promised, here it is: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xdeadc1d7 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc047b518 > stack pointer = 0x10:0xcc694954 > frame pointer = 0x10:0xcc69495c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 35 (swi1: net) > [thread pid 35 tid 100031 ] > Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax Here's another one: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc2 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047adcb stack pointer = 0x10:0xcc6975fc frame pointer = 0x10:0xcc697604 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 36 (swi5: clock sio) [thread pid 36 tid 100032 ] Stopped at pf_state_tree_lan_ext_RB_FIND+0xb: movl0(%eax),%ebx db> trace Tracing pid 36 tid 100032 td 0xc1515320 pf_state_tree_lan_ext_RB_FIND(c2,cc69788c,0,cc697a20,cc697998) at pf_state_tree_lan_ext_RB_FIND+0xb pf_find_state_recurse(c176c300,cc69788c,0,c08118f4,c1514e20) at pf_find_state_recurse+0x45 pf_test_state_icmp(cc6979ec,2,c176c300,c1743000,30) at pf_test_state_icmp+0xb8 pf_test6(2,c1586000,cc697ac0,0,c17565a0) at pf_test6+0xe30 pf_check6_out(0,cc697ac0,c1586000,2,0) at pf_check6_out+0x35 pfil_run_hooks(c07f3980,cc697b58,c1586000,2,0) at pfil_run_hooks+0x15b ip6_output(c1743000,c07f59c0,cc697bdc,0,cc697c4c) at ip6_output+0xb9a mld6_sendpkt(0,c07a5ab0,c07a59a0,c05af360,cc697ca0) at mld6_sendpkt+0x207 mld6_fasttimeo(c07c5680,1,c0767584,100,6) at mld6_fasttimeo+0x83 pffasttimo(0,8,c076302f,f7,38fd) at pffasttimo+0x85 softclock(0,0,c075f8fb,269,0) at softclock+0x12f ithread_loop(c1526280,cc697d48,c075f6d4,31e,0) at ithread_loop+0x1ff fork_exit(c055fcb0,c1526280,cc697d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc697d7c, ebp = 0 --- db> pgp5TOkXBwQCx.pgp Description: PGP signature
PANIC: Re: machine locks with PF (without using user dependent rules)
Am Montag, 7. Februar 2005 16:52 schrieb Emanuel Strobl: > 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 [...] > Tell me how I can help, I'll later hand in the trace of the slef-lock when > debug.mpsafenet is 1. Like promised, here it is: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b518 stack pointer = 0x10:0xcc694954 frame pointer = 0x10:0xcc69495c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax db> trace Tracing pid 35 tid 100031 td 0xc1515190 pf_state_compare_ext_gwy(c1748300,cc6949ac,cc694984,c047c0c2,c17483c4) at pf_state_compare_ext_gwy+0x18 pf_state_tree_ext_gwy_RB_FIND(c17483c4,cc6949ac,c1748300,cc694af8,cc694ab8) at pf_state_tree_ext_gwy_RB_FIND+0x29 pf_find_state_recurse(c1748300,cc6949ac,1,c076341c,255) at pf_find_state_recurse+0x72 pf_test_state_udp(cc694b00,1,c1748300,c1856c00,14) at pf_test_state_udp+0x90 pf_test(1,c1585800,cc694bf0,0,c1768720) at pf_test+0xb78 pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f05a0,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b ip_input(c1856c00,0,c076b16d,e6,c07f0660) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c5640,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c075f8fb,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c075f6d4,31e,0) at ithread_loop+0x1ff fork_exit(c055fcb0,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- db> > > -Harry > pgpO2GmhMkNt8.pgp Description: PGP signature
Re: machine locks with PF (without using user dependent rules)
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 0xf, 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,da7a,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,,) 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
Re: machine locks with PF (without using user dependent rules)
Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier: > 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. Right, but I meant that at least a note would pop up which tells me to modify loader.conf ar the script would do it itself ;) Like you say, it's not intended :) > > 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? Please find the dmesg at bottom. I'll see that I can get physical access and change the CF-Card with a witness and INVARIANTS kernel > 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. I'm running -stable from January 4th, but haven't tried mpsafenet since RELENG_5 from mid Dezember, alas the lockup occured with RELENG_5 short before christmas. Best regards, -Harry [...] > > > 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. Thanks a lot for that hint! phobos:~>30: dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #4: Tue Jan 4 17:57:01 CET 2005 [EMAIL PROTECTED]:/builder/obj/builder/src/sys/GA-6IEML WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1300MHz (1339.16-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 Features=0x383fbff real memory = 267321344 (254 MB) avail memory = 251875328 (240 MB) ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x4000-0x40bf,0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe600-0xe607,0xe000-0xe3ff irq 16 at device 2.0 on pci0 pcib1: at device 30.0 on pci0 pci1: on pcib1 em0: port 0xc000-0xc03fmem 0xe500-0xe501,0xe502-0xe503 irq 18 at device 0.0 on pci1 em0: [GIANT-LOCKED] em0: Ethernet address: 00:0e:0c:65:21:40 em0: Speed:N/A Duplex:N/A em1: port 0xc400-0xc43fmem 0xe506-0xe507,0xe504-0xe505 irq 21 at device 1.0 on pci1 em1: [GIANT-LOCKED] em1: Ethernet address: 00:0e:0c:65:20:6e em1: Speed:N/A Duplex:N/A em2: port 0xc800-0xc83fmem 0xe50a-0xe50b,0xe508-0xe509 irq 22 at device 2.0 on pci1 em2: [GIANT-LOCKED] em2: Ethernet address: 00:0e:0c:65:21:a5 em2: Speed:N/A Duplex:N/A fxp0: port 0xcc00-0xcc3f mem 0xe50c-0xe50c0fff irq 20 at device 8.0 on pci1 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:20:ed:47:b5:c9 fxp0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xd000-0xd01f irq 19at device 31.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ichsmb0: port 0x5000-0x500f irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xd800-0xd81f irq 23at device 31.4 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] npx0: [FAST] npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xcc000-0xc,0xc-0xc9fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <8 virtua
Re: machine locks with PF (without using user dependent rules)
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?
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.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpjLwFoZqzll.pgp
Description: PGP signature
Re: machine locks with PF (without using user dependent rules)
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.
>
> 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.
Thanks,
Robert N M Watson
>
> 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
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
machine locks with PF (without using user dependent rules)
Dear all,
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.
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.
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
pgpCLXDB1D0Gr.pgp
Description: PGP signature
