From owner-freebsd-pf@FreeBSD.ORG Mon Jun 4 10:08:34 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 2784D106566C; Mon, 4 Jun 2012 10:08:34 +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 845488FC12; Mon, 4 Jun 2012 10:08:30 +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 q54A8Tkn009989 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 12:08:29 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q54A8TVn002927; Mon, 4 Jun 2012 12:08:29 +0200 (MEST) Date: Mon, 4 Jun 2012 12:08:29 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120604100829.GB13069@insomnia.benzedrine.cx> References: <201205271830.q4RIU9fA039893@freefall.freebsd.org> <20120529064910.GA12508@insomnia.benzedrine.cx> <20120604065344.GA13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120604065344.GA13069@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.12-2006-07-14 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?) 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: Mon, 04 Jun 2012 10:08:34 -0000 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