From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 10:10:20 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90197106579C for ; Mon, 4 Jun 2012 10:10:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A2ED68FC26 for ; Mon, 4 Jun 2012 10:10:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54AAHVv086786 for ; Mon, 4 Jun 2012 10:10:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54AAHsx086785; Mon, 4 Jun 2012 10:10:17 GMT (envelope-from gnats) Date: Mon, 4 Jun 2012 10:10:17 GMT Message-Id: <201206041010.q54AAHsx086785@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Daniel Hartmeier Cc: 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 Reply-To: Daniel Hartmeier 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: Mon, 04 Jun 2012 10:10:20 -0000 The following reply was made to PR kern/168190; it has been noted by GNATS. From: Daniel Hartmeier To: Joerg Pulz Cc: bug-followup@freebsd.org, freebsd-pf@freebsd.org Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) Date: Mon, 4 Jun 2012 12:08:29 +0200 I think I found what might happen in your case. When reading the ipfilter hook previously, I thought that it would return quickly due to fr_running not being enabled, but it's not an 'enabled' flag as set manually with pfctl -e! If you compile in ipfilter (as your kernel config does), it will run a lot of code, even if you don't enable it in rc.conf and configure a ruleset. I noticed that in all your traces so far, the packets always have ip_p=1 (ICMP) and a non-minimal length. There's a very suspicious m_pulldown() call here fr_check_wrapper() fr_check() fr_makefrip() frpr_ipv4hdr() frpr_icmp() for ICMP_SOURCEQUENCH|REDIRECT|TIMEXCEED|PARAMPROB fr_coalesce() fr_pullup() for len > MHLEN (around what, 150?) m_pulldown() where fr_pullup() subsequently even does this while (M_LEN(m) == 0) { m = m->m_next; } i.e. it seems to explicitely deal with the case where the mbuf starts with m_len==0 segments. The problem is, nothing else does, neither other pfil consumers (like ipfw or pf) nor bridge or any other networking code I can find. This could also explain the effects in ipfw (not updating byte order) and pf (panic you originally reported). There are barely any other m_pulldown() calls in the kernel, especially with offp=NULL, and its source is full of warning comments, see /usr/src/sys/kern/uipc_mbuf2.c. So I'm not sure if it's being used wrongly (ignoring its return value certainly looks wrong), or if it shouldn't be used at all. You can possibly trigger the problem by provoking an ICMP TTL exceeded error of size 150-200, either with traceroute -I packetlen or by manually crafting it (with dnet from ports or such). Alternatively, I suspect the problem will no longer show when you disable ipfilter. Daniel