From owner-freebsd-net@FreeBSD.ORG Tue Dec 14 14:23:03 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 148D516A4CE for ; Tue, 14 Dec 2004 14:23:03 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B5C43D4C for ; Tue, 14 Dec 2004 14:23:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27088 invoked from network); 14 Dec 2004 14:11:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2004 14:11:54 -0000 Message-ID: <41BEF746.E8362858@freebsd.org> Date: Tue, 14 Dec 2004 15:23:02 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <20041213124051.GB32719@cell.sick.ru> <20041214085123.GB42820@cell.sick.ru> <20041214015603.A75019@xorpc.icir.org> <41BEE0E7.BD2316EB@freebsd.org> <20041214060341.A77720@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters [summary] 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, 14 Dec 2004 14:23:03 -0000 Luigi Rizzo wrote: > > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > ... > > > Implementationwise, the kernel side is evidently trivial as the > > > original code already supports the idea of multiple chains. All > > > you need is to extend the struct ifnet with a pointer to the chain, > > > or use some other trick (e.g. going through ifindex) to quickly > > > associate a chain to the input (and possibly output) interface. > > > > Nonononononononononononononononononononononono. > > andre you need to cool down a bit! I'm not angry but frustrated. In the network area it's too much 'lets quickly hack this in' instead of 'lets carefully design this in'. > i said "use some other trick" exactly to avoid changing > the struct ifnet. All i meant to say is that we want a unique > key, possibly in a small namespace, to quickly locate the per-if > private firewall info. How the key is used is not a business of > the rest of the kernel. But of course if it is an index in a > smallish array (such as ifindex) the thing is fast and clean. Ok, I'm fine with *this* approach. This can be done and handled inside ipfw_check_in|out() based on the interface pointer information passed in from pfil_run_hooks(). Then inside IPFW it can be implemented with multiple rule chains although I'm not convinced this would be the smartest approach. Wouldn't it be even better to have per-interface and global rules after each other? This way your problem with the general rule synching can be solved. -- Andre