From owner-freebsd-net@FreeBSD.ORG Tue Jan 2 14:13:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32F5516A40F for ; Tue, 2 Jan 2007 14:13:54 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E8CB713C459 for ; Tue, 2 Jan 2007 14:13:53 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id 0B6D63F38 for ; Tue, 2 Jan 2007 15:13:51 +0100 (CET) Received: by jayce.zen.inc (Postfix, from userid 1000) id 337112E2C4; Tue, 2 Jan 2007 15:13:52 +0100 (CET) Date: Tue, 2 Jan 2007 15:13:52 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070102141351.GA1604@jayce.zen.inc> References: <20070102105959.94227.qmail@web51909.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070102105959.94227.qmail@web51909.mail.yahoo.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 14:13:54 -0000 On Tue, Jan 02, 2007 at 02:59:59AM -0800, ashoke saha wrote: > Hi , Hi. > just joined the mailibng list. I was implementing > NAT traversal based on the patch and my kernel was > panicking because of wrong ipsec config, which it > should not whatever be the config. > > Looks like there is a small issue in the code > http://ipsec-tools.sourceforge.net/freebsd6-natt.diff > which might already be fixed. > > Look at the call of the function > udp4_espinudp () in udp append. Now under certain > circumstances it is possible that udp4_espinudp () > calls m_pullup() and it would add a new pkt header to > the mbuf chain. But udp_append() is still holding the > old head, whose PKTHDR flag is now off. It then sends > the pkt further up and kernel does as panic as it does > not see PKTHDR flag. I already fixed "something like that" a few months ago. Are you using the latest version of the patch ? MD5 sum of the patch file should be 510ac07e6aa95d34e1e05da0695e4059, is that what you get ? Yvan. -- NETASQ http://www.netasq.com