Bug 143543

Summary:	[pf] [panic] PF route-to causes kernel panic
Product:	Base System	Reporter:	Slava <slava>
Component:	kern	Assignee:	freebsd-pf (Nobody) <pf>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	cmb, kp
Priority:	Normal
Version:	8.0-RELEASE
Hardware:	Any
OS:	Any

Description Slava 2010-02-04 10:00:02 UTC

When using PF route-to on my router, to pass packets to different channels based on their source address, after enabling PF with route-to rules, kernel panics in 5-10 minutes. 

If i'm not using PF route-to (for now i'm using ipfw fwd instead, but need to switch to PF-nat and to use PF route-to) everything works fine.

route-to rule example:

pass in quick on vlan2 route-to ( vlan5 XXX.XXX.XXX.XXX ) inet from 10.253.0.0/16 to any no state


Dump information is below:

router.domain.ru dumped core - see /var/crash/vmcore.5

Thu Feb  4 11:10:35 MSK 2010

FreeBSD router.domain.ru 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Wed Feb  3 13:22:07 MSK 2010     root@router.domain.ru:/usr/src/sys/i386/compile/ROUTER  i386

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address	= 0x34
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc09c6e4b
stack pointer	        = 0x28:0xc537f990
frame pointer	        = 0x28:0xc537f9c8
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 12 (swi1: netisr 0)
trap number		= 12
panic: page fault
cpuid = 1
Uptime: 20h10m1s
Physical memory: 2000 MB
Dumping 344 MB: 329 313 297 281 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 25 9

Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/kernel/if_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_vlan.ko
Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_netflow.ko...Reading symbols from /boot/kernel/ng_netflow.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_netflow.ko
Reading symbols from /boot/kernel/ng_vlan.ko...Reading symbols from /boot/kernel/ng_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_vlan.ko
Reading symbols from /boot/kernel/ng_ksocket.ko...Reading symbols from /boot/kernel/ng_ksocket.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ksocket.ko
Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_tee.ko
Reading symbols from /boot/kernel/ng_one2many.ko...Reading symbols from /boot/kernel/ng_one2many.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_one2many.ko
#0  doadump () at pcpu.h:246
246	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) #0  doadump () at pcpu.h:246
#1  0xc08d6ef7 in boot (howto=260) at ../../../kern/kern_shutdown.c:416
#2  0xc08d71e9 in panic (fmt=Variable "fmt" is not available.
) at ../../../kern/kern_shutdown.c:579
#3  0xc0b9a58c in trap_fatal (frame=0xc537f950, eva=52)
    at ../../../i386/i386/trap.c:933
#4  0xc0b9a7f0 in trap_pfault (frame=0xc537f950, usermode=0, eva=52)
    at ../../../i386/i386/trap.c:846
#5  0xc0b9b1a9 in trap (frame=0xc537f950) at ../../../i386/i386/trap.c:528
#6  0xc0b7e39b in calltrap () at ../../../i386/i386/exception.s:165
#7  0xc09c6e4b in arpresolve (ifp=0xc5a4d000, rt0=0x0, m=0xcaac8000, 
    dst=0xc537fa5c, desten=0xc537f9f0 "\032&#1040;&#1085;&#1052;", lle=0xc537f9fc)
    at ../../../netinet/if_ether.c:363
#8  0xc097f92c in ether_output (ifp=0xc5a4d000, m=0xcaac8000, dst=0xc537fa5c, 
    ro=0xc537fa54) at ../../../net/if_ethersubr.c:200
#9  0xc050ae0d in pf_route (m=0xc537fc0c, r=0xcb34133c, dir=1, 
    oifp=0xc5a51400, s=0x0, pd=0xc537fb3c)
    at ../../../contrib/pf/net/pf.c:6277
#10 0xc050a7f5 in pf_test (dir=1, ifp=0xc5a51400, m0=0xc537fc0c, eh=0x0, 
    inp=0x0) at ../../../contrib/pf/net/pf.c:7173
#11 0xc050f976 in pf_check_in (arg=0x0, m=0xc537fc0c, ifp=0xc5a51400, dir=1, 
    inp=0x0) at ../../../contrib/pf/net/pf_ioctl.c:3646
#12 0xc0987438 in pfil_run_hooks (ph=0xc0d9d6c0, mp=0xc537fc5c, 
    ifp=0xc5a51400, dir=1, inp=0x0) at ../../../net/pfil.c:81
#13 0xc09e6865 in ip_input (m=0xcaac8000) at ../../../netinet/ip_input.c:517
#14 0xc0986fdf in swi_net (arg=0xc1025800) at ../../../net/netisr.c:716
#15 0xc08b04db in intr_event_execute_handlers (p=0xc55337f8, ie=0xc5579d80)
    at ../../../kern/kern_intr.c:1165
#16 0xc08b1a7b in ithread_loop (arg=0xc55320c0)
    at ../../../kern/kern_intr.c:1178
#17 0xc08ae221 in fork_exit (callout=0xc08b1a10 <ithread_loop>, 
    arg=0xc55320c0, frame=0xc537fd38) at ../../../kern/kern_fork.c:843
#18 0xc0b7e410 in fork_trampoline () at ../../../i386/i386/exception.s:270
(kgdb) 


I saw another message about this problem on 7.2-RELEASE-p4, but without any comments:
http://old.nabble.com/PF-route-to-on-7.2-RELEASE-p4-td26230682.html

How-To-Repeat: Enable pf route-to rules and wait for some time.

Comment 1 Mark Linimon freebsd_committer

2010-02-04 10:21:23 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-pf

Over to maintainer(s).

Comment 2 Nick Leuta 2010-03-14 00:34:50 UTC

I have the similar problem but in a bit different situation...

the rule is:
  pass out quick route-to (vlan2 192.168.0.1) from 192.168.0.2 to any
where 192.168.0.2 is binded to the vlan2 interface. The default gateway 
is 192.168.1.1 and is accessible through another interface.

The "ping -S 192.168.0.2 192.168.0.1" command is used for test purposes, 
and (sic!) the 192.168.0.1 is unreachable (really down...).

Without that rule we have:

PING 192.168.0.1 (192.168.0.1) from 192.168.0.2: 56 data bytes
<some timeout there>
ping: sendto: Host is down
<this message is repeated until Ctrl-C is pressed>

With the rule we obtain the kernel panic (in "ping" process) instead of 
the "ping: sendto: Host is down" message after the same timeout as in 
the case without rule.

Comment 3 Slava 2010-03-14 16:00:25 UTC

I'm now using ipfw setfib command as workaround, PF as NAT + ipfw
works fine for me.


--=20
=D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC,
 =C1=E5=EB=EE=E3=F3=F0=EE=E2 =D1=E2=FF=F2=EE=F1=EB=E0=E2
 8 (81555) 7-40-99
 =D0=E5=EB=E0=ED=F2, http://www.relant.ru
 mailto:slava@aprec.ru

Comment 4 Nick Leuta 2010-03-14 20:20:44 UTC

Hmm... Im my case "ipfw fwd" command doesn't work too - it forwards 
locally generated packets using the routing table (???)... but yes, it 
has some effect - it changes the interface where the packets are 
originated. PF's "route-to" command works fine, but only if the 
destination host is reachable...

Comment 5 cmb 2015-12-12 05:26:46 UTC

The examples provided here definitely work fine on all currently supported FreeBSD versions. This is safe to close unless there's some unusual edge case not detailed here.

Comment 6 Kristof Provost freebsd_committer

2015-12-12 12:32:45 UTC

Closing based on the report in comment #5.