Am Samstag, 12. März 2005 06:07 schrieb Pyun YongHyeon: > On Fri, Mar 11, 2005 at 05:12:31PM +0100, Emanuel Strobl wrote: > > Am Freitag, 11. M?rz 2005 16:19 schrieb Emanuel Strobl: > > > Am Freitag, 11. M?rz 2005 14:52 schrieb Daniel Hartmeier: > > > > block return-rst in on wi0 reply-to (wi0 10.1.1.1) inet proto tcp > > > > all > > > > > > > > This is valid syntax and pfctl loads the rule, but the functionality > > > > is not implemented in kernel yet, i.e. the reply-to option is simply > > > > ignored. > > > > > > Thanks, I tried a very similar rule and after that the box vanished. > > > I went on location (the box paniced but didn't reboot) and installed a > > > console-server so I can access the box from here and currently I'm > > > baking a debug kernel. > > > I'll notify you if I have a trace! > > > > Here's the original panic message (the non debug kernel) with 5.4-PRE > > one week old: > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xc > > fault code = supervisor read, page not pre > > instruction pointer = 0x8:0xc05ac722 > > stack pointer = 0x10:0xcc6919ac > > frame pointer = 0x10:0xcc6919e0 > > code segment = base 0x0, limit 0xfffff, type > > = DPL 0, pres 1, def32 1, gran > > processor eflags = interrupt enabled, resume, IO > > current process = 34 (swi1: net) > > trap number = 12 > > panic: page fault > > Uptime: 1d1h20m33s > > GEOM_MIRROR: Device web: provider mirror/web destroyed. > > GEOM_MIRROR: Device web destroyed. > > ... > > The machine didn't reboot! > > > > > > The following rule panickes the machine: > > block return-icmp(13) in on $SDSL route-to ($SDSL $sdsl_gw) from any to > > $sdsl_net > > > > Here's the trace from 5.4-PRE today: > > panic: m_copym, offset > size of mbuf chain > > KDB: stack backtrace: > > panic(c076ab9a,c174d500,100,cc694a30,0) at panic+0x13c > > m_copym(c1621b00,5dc,5c8,1,14) at m_copym+0x1c7 > > ip_fragment(c1642010,cc694a74,5dc,6,f01) at ip_fragment+0x168 > > pf_route(cc694bf0,c1a10d20,1,c1585000,0) at pf_route+0x767 > > pf_test(1,c1585000,cc694bf0,0,c17554e0) at pf_test+0x7b1 > > pf_check_in(0,cc694bf0,c1585000,1,0) at pf_check_in+0x48 > > pfil_run_hooks(c07f3e60,cc694c9c,c1585000,1,0) at pfil_run_hooks+0x15b > > ip_input(c1621b00,0,c076e621,e6,c07f3f20) at ip_input+0x20f > > netisr_processqueue(cc694cd8,246,c07c8ee0,2,c1508d40) at > > netisr_processqueue+0x15 > > swi_net(0,0,c0762ddc,269,0) at swi_net+0x8d > > ithread_loop(c1526300,cc694d48,c0762bbd,30e,0) at ithread_loop+0x1ff > > fork_exit(c0560640,c1526300,cc694d48) at fork_exit+0xa9 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- > > > > If you need more info, on http://www.schmalzbauer.de/statics/phobos you > > can find dmesg and the whole pf.conf > > Hmm, Max and I had seen these kind of traces when pf porting > was in progress. But now I believe we fixed all possible > cases. > > I can't sure but your trace indicates there is a bug in > ip_fragment(). If a packet already set IP_MF flag in ip header, > we would get invalid ip_off in fragmented packet. > And it seems that there is another bug in pf. Since ip_fragment() > can change passed mbuf, we should not use saved copy of it. > Untested patch for CURRENT attached.
Hello, I tested your patch against BETA1 (RELENG_5 from today). It applied and compiled but unfortunately doesn't solf the panick. Here's the latest trace: login: panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 35 tid 100031 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> trace Tracing pid 35 tid 100031 td 0xc1515190 kdb_enter(c0765289,c07ca240,c076a9a8,cc6949d8,c1515190) at kdb_enter+0x32 panic(c076a9a8,c1751600,100,cc694a48,0) at panic+0x14d m_copym(c1619b00,5dc,5c8,1,14) at m_copym+0x1c7 ip_fragment(c163a010,cc694a88,5dc,6,f01) at ip_fragment+0x168login: panic: m_copym, offset > size of mbuf chain KDB: enter: panic [thread pid 35 tid 100031 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> trace Tracing pid 35 tid 100031 td 0xc1515190 kdb_enter(c0765289,c07ca240,c076a9a8,cc6949d8,c1515190) at kdb_enter+0x32 panic(c076a9a8,c1751600,100,cc694a48,0) at panic+0x14d m_copym(c1619b00,5dc,5c8,1,14) at m_copym+0x1c7 ip_fragment(c163a010,cc694a88,5dc,6,f01) at ip_fragment+0x168 pf_route(cc694c04,c1a13d20,1,c1588000,0) at pf_route+0x761 pf_test(1,c1588000,cc694c04,0,c1758b20) at pf_test+0x7b1 pf_check_in(0,cc694c04,c1588000,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f3d00,cc694c9c,c1588000,1,0) at pfil_run_hooks+0x15b ip_input(c1619b00,0,c076e42f,e6,c07f3dc0) at ip_input+0x205 netisr_processqueue(cc694cd8,246,c07c8d60,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c0762bea,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c07629cb,30e,0) at ithread_loop+0x1ff fork_exit(c0560290,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- db> pf_route(cc694c04,c1a13d20,1,c1588000,0) at pf_route+0x761 pf_test(1,c1588000,cc694c04,0,c1758b20) at pf_test+0x7b1 pf_check_in(0,cc694c04,c1588000,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f3d00,cc694c9c,c1588000,1,0) at pfil_run_hooks+0x15b ip_input(c1619b00,0,c076e42f,e6,c07f3dc0) at ip_input+0x205 netisr_processqueue(cc694cd8,246,c07c8d60,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c0762bea,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c07629cb,30e,0) at ithread_loop+0x1ff fork_exit(c0560290,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- db> Thanks, -Harry P.S.: Shall I file a PR? Do you think this will be fixed before 5.4?
pgpBStn3xK5RF.pgp
Description: PGP signature
