From owner-freebsd-pf@FreeBSD.ORG Thu May 24 09:43:56 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DB311065672 for ; Thu, 24 May 2012 09:43:56 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id DC00C8FC18 for ; Thu, 24 May 2012 09:43:55 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q4O9hsKL026924 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 11:43:54 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q4O9hsXD000340; Thu, 24 May 2012 11:43:54 +0200 (MEST) Date: Thu, 24 May 2012 11:43:54 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120524094354.GK29536@insomnia.benzedrine.cx> References: <201205240910.q4O9A4rt044627@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205240910.q4O9A4rt044627@freefall.freebsd.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:43:56 -0000 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