Date: Thu, 24 May 2012 11:43:54 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Joerg Pulz <Joerg.Pulz@frm2.tum.de> Cc: freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Message-ID: <20120524094354.GK29536@insomnia.benzedrine.cx> In-Reply-To: <201205240910.q4O9A4rt044627@freefall.freebsd.org> References: <201205240910.q4O9A4rt044627@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 24, 2012 at 09:10:04AM +0000, Joerg Pulz wrote: > panic: ipfw_check_hook:281 ASSERT_HOST_BYTE_ORDER 45056 176 > ipfw_check_hook() at ipfw_check_hook+0x511 > pfil_run_hooks() at pfil_run_hooks+0xf1 > ip_output() at ip_output+0x6de > ip_forward() at ip_forward+0x19e > ip_input() at ip_input+0x680 > swi_net() at swi_net+0x15a OK, this convinces me that the problem is in ipfw. You enabled it with options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT but say you're not using it? The above will actually enable ipfw's packet inspection with a default pass rule. And a non-trivial amount of code runs, unlike pf (and ipfilter), which must first be enabled (like with pfctl -e) first. Could you rebuild a kernel without the above options, just to confirm the theory that the problem is related to ipfw? We can try to find the problem within ipfw, maybe asking the ipfw developers for help. Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120524094354.GK29536>