From owner-freebsd-pf@FreeBSD.ORG Tue May 22 08:06:24 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 D0F5A1065672 for ; Tue, 22 May 2012 08:06:24 +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 3E7E18FC1C for ; Tue, 22 May 2012 08:06:23 +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 q4M86MAM029649 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 22 May 2012 10:06:22 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q4M86MvG026252; Tue, 22 May 2012 10:06:22 +0200 (MEST) Date: Tue, 22 May 2012 10:06:22 +0200 From: Daniel Hartmeier To: Joerg Pulz Message-ID: <20120522080622.GC29536@insomnia.benzedrine.cx> References: <201205220610.q4M6A3oY036772@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205220610.q4M6A3oY036772@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: Tue, 22 May 2012 08:06:24 -0000 On Tue, May 22, 2012 at 06:10:03AM +0000, Joerg Pulz wrote: > And i got another panic, this time without pf(4) involved at all. > Unfortunately "dump" in kdb is doing nothing but hang. :-( > > Here is what was displayed on the screen: > > panic: m_copym, offset > size of mbuf chain > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic_0x182 > m_copym() at m_copym+0x280 > ip_fragment() at ip_fragment+0x1e5 > ip_output() at ip_output+0xeab > ip_forward() at ip_forward+0x175 > ip_input() at ip_input+0x5fd > swi_net() at swi_net+0x15a > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > ithread_loop() at ithread_loop+0xaf > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > - --- trap 0, rip = 0, rsp = 0xfffff8000241d00, rbp = 0 --- > KDB: enter: panic > [ thread pid 12 tid 100008 ] > > Any thoughts about this one? It's pretty clear that ip_fragment() gets called because a packet has ip_len in the wrong byte order. The packet is smaller than mtu, it shouldn't get fragmented at all. The problem is not related to fragmentation itself. While the stack trace above doesn't show pf, it's still possible (and I'd say likely) that it's pf leaving the byte order wrong. There are several places in pf where the byte order of ip_len is swapped, some are local patches (#ifdef __FreeBSD__). I'd also guess that it's related to a more obscure functionality (like route-to, or double route-to), otherwise more people would see this. Another lead is interface checksum (or fragmentation) offloading, there are code paths that swap byte order depending on these features. You could try disabling them with ifconfig. If you look at egrep -i '[hn]to[nh]s\(.*ip_len\)' /usr/src/sys/netinet/* /usr/src/contrib/pf/net/* you'll see that it's quite a mess, because byte order is expected to be different depending on context. I'm still looking ;) Daniel