From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 18:08:51 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 E546316A4CE for ; Mon, 29 Nov 2004 18:08:51 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15FCB43D4C for ; Mon, 29 Nov 2004 18:08:49 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 3413 invoked from network); 29 Nov 2004 18:00:21 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 18:00:21 -0000 Message-ID: <41AB65B2.A18534BF@freebsd.org> Date: Mon, 29 Nov 2004 19:08:50 +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> <41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org> <41AB3A74.8C05601D@freebsd.org> <20041129174954.GA26532@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 18:08:52 -0000 Joost Bekkers wrote: > > On Mon, Nov 29, 2004 at 04:04:20PM +0100, Andre Oppermann wrote: > > Joost Bekkers wrote: > > > > > > On Mon, Nov 29, 2004 at 11:14:46AM +0100, Andre Oppermann wrote: > > > > > > > > > > The attached patch is against 5.3R > > > > > > > > Please post unified diffs. > > > > > > > > > > Ok, here you go. > > > > While this way of 'fixing' the IPSEC problem works it is rather gross > > and not very stylish. I prefer not to have this in the tree as makes > > maintainance a lot harder. > > > > I totaly agree that it is not pretty. I was trying to avoid duplicating > the code (so every change would have to be made twice) and making it a > function didn't sit right for some reason. Hints/tips for dealing with > this kind of situation are welcome, but maybe better off-list. As things currently are with IPSEC code weaved directly into ip_input() and ip_output() there is no better way than what you have proposed. > > I have some stuff wrt [Fast]IPSEC and your problem in the works and > > it should become ready around christmas time (loadable [Fast]IPSEC, at > > least for IPv4). > > > > Looking forward to it. It will solve it much more nicely. :) -- Andre