Skip site navigation (1)Skip section navigation (2)
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>