From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:54:13 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 1083E16A4CE; Tue, 22 Jun 2004 09:54:13 +0000 (GMT) Received: from mailbox.rainbownet.com (mailbox.rainbownet.com [213.174.191.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96B7F43D4C; Tue, 22 Jun 2004 09:54:11 +0000 (GMT) (envelope-from aturetta@commit.it) Received: from nbangx ([151.38.10.253]) (authenticated user aturetta@rainbownet.com) by rainbownet.com (rainbownet.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 24-md50000000667.tmp; Tue, 22 Jun 2004 11:53:58 +0200 Message-ID: <006901c4583e$b651fe60$5a2ba8c0@lan> From: "Angelo Turetta" To: References: <40D754D5.1070805@freebsd.org> Date: Tue, 22 Jun 2004 11:52:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: aturetta@rainbownet.com X-Spam-Processed: rainbownet.com, Tue, 22 Jun 2004 11:53:58 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 151.38.10.253 X-Return-Path: aturetta@commit.it cc: freebsd-net@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion 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: Tue, 22 Jun 2004 09:54:13 -0000 ----- Original Message ----- From: "Andre Oppermann" Sent: Monday, June 21, 2004 11:36 PM > This patch significantly cleans up ip_input.c and ip_output.c. > > The following is included in this patch: > > o Remove all ipfw related cruft from ip_input() and ip_output() > o New ip_fw_pfil.c file which contains all ipfw/pfil_hooks logic IIRC, I had once a problem with a mixed setup where I used IPFILTER NAT & IPFW DUMMYNET. Basically, there was an asymmetry in the order the two filters were called, because the code in ip_input.c called IPFILTER before entering the IPFW code, and ip_output.c did the same, while it should have called first IPFW then IPFILTER. (beware, it might have been the opposite WRT what was first in which function, I don't remember exactly). Does your new code take this ordering issue into account? I suppose it would be nice to be able to control the order filters are processed: I may like IPFW to be 'wrapping' IPFILTER (that is, called before it during input, and after it during output), while others might prefer the opposite. And anyway, am I right the filter list should be traversed in opposite directions during input versus output (maybe it's already so). Ciao, Angelo.