Date: Thu, 28 May 2015 11:29:03 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-net@freebsd.org Subject: Re: Crash with GRE und IPFW fwd Message-ID: <55668B7F.9010509@freebsd.org> In-Reply-To: <20150528013135.GR95600@strugglingcoder.info> References: <5566565A.7030200@tzi.de> <20150528013135.GR95600@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/28/15 9:31 AM, hiren panchasara wrote: > On 05/28/15 at 01:42P, Julian Kornberger wrote: >> Hi, >> >> I have recurring crashes if I forward GRE packets using IPFW with fwd: >> - The first fwd rule forwards incoming traffic into a GRE interface. >> - The second fwd rule forwards GRE packets to a gateway. >> >> If there is no GRE traffic, the system is stable. As soon as there is >> GRE traffic i takes araound one to five minutes until is crashes. >> If I omit the second fwd rule, it never crashes. >> >> I use a FreeBSD 10.1 on a PC Engines APU.1D board. >> Any Ideas how to debug this? >> >> Kind Regards >> Julian >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x7c >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80a58105 >> stack pointer = 0x28:0xfffffe00957335e0 >> frame pointer = 0x28:0xfffffe00957336e0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 1707 (tcpmssd) > Where is this from? net/tcpmssd port/package? > > If so, try disabling/uninstalling it and see if that helps. no it's inherrent kernel behaviour. Julian, I am guessing (with no actual information) that something in gre processing is assuming that the packet id going where it normally would go. (and not where fwd is sending it). you really need to use objdump or gdb to look at the gre module and work out where gre_output+0x467 is in the function. that should give you a clue on the problem. not too helpful I know... but you have a reproducible case at least. kgdb may be your friend if you have a serial cable or firewire cable. > > cheers, > Hiren >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff80963000 at kdb_backtrace+0x60 >> #1 0xffffffff80928125 at panic+0x155 >> #2 0xffffffff80d258df at trap_fatal+0x38f >> #3 0xffffffff80d25bf8 at trap_pfault+0x308 >> #4 0xffffffff80d2525a at trap+0x47a >> #5 0xffffffff80d0b142 at calltrap+0x8 >> #6 0xffffffff81a15797 at gre_output+0x467 >> #7 0xffffffff80a59024 at ip_output+0x11b4 >> #8 0xffffffff819b257a at div_send+0x33a >> #9 0xffffffff8099e0b5 at sosend_generic+0x475 >> #10 0xffffffff809a4425 at kern_sendit+0x245 >> #11 0xffffffff809a4749 at sendit+0x129 >> #12 0xffffffff809a460d at sys_sendto+0x4d >> #13 0xffffffff80d26211 at amd64_syscall+0x351 >> #14 0xffffffff80d0b42b at Xfast_syscall+0xfb >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55668B7F.9010509>