From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 10:14:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A148416A4CE for ; Mon, 29 Nov 2004 10:14:55 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC19043D3F for ; Mon, 29 Nov 2004 10:14:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 223 invoked from network); 29 Nov 2004 10:06:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 10:06:30 -0000 Message-ID: <41AAF696.6ED81FBF@freebsd.org> Date: Mon, 29 Nov 2004 11:14:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joost Bekkers References: <20041129100949.GA19560@bps.jodocus.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 10:14:55 -0000 Joost Bekkers wrote: > > Hi > > A while ago there was a discussion about passing packet through pfil before > they are processed by ipsec. I've posted a rough patch back then and I've > finally had time to polish it. > > Although the changes seem very invasive at first glance, the .o files created > are identical as long as IPSEC_FILTERGIF is not defined. With FAST_IPSEC diff(1) > will tell you otherwise, but that is due to changed linenumbers which are used > as arguments in two places. I've checked for differences by disassembling (objdump -d) > the .o files. > > The attached patch is against 5.3R Please post unified diffs. > I'm running it myself with FAST_IPSEC. The combination of this patch and the kame > ipsec could do with some more testing. -- Andre