From owner-freebsd-net@FreeBSD.ORG Wed Dec 15 10:50: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 73DF616A4CE for ; Wed, 15 Dec 2004 10:50:55 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EDBA43D53 for ; Wed, 15 Dec 2004 10:50:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34611 invoked from network); 15 Dec 2004 10:39:37 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Dec 2004 10:39:37 -0000 Message-ID: <41C0170F.95449D19@freebsd.org> Date: Wed, 15 Dec 2004 11:50:55 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net> <20041213104200.A62152@xorpc.icir.org> <20041214085123.GB42820@cell.sick.ru> <1103017203.1060.25.camel@localhost> <41BEE281.607DD0A8@freebsd.org> <1103035345.1060.55.camel@localhost> <41BF008D.AD79C9B@freebsd.org> <20041215081810.GA53509@cell.sick.ru> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: vova@fbsd.ru cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters 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: Wed, 15 Dec 2004 10:50:55 -0000 Gleb Smirnoff wrote: > > On Tue, Dec 14, 2004 at 04:02:37PM +0100, Andre Oppermann wrote: > A> > Ÿ ??, 14/12/2004 ? 13:54 +0100, Andre Oppermann ?????: > A> > > It's about HOW to implement it. I think the ways proposed so far are > A> > > hackish, too complex and outside of our framework which was very well > A> > > designed and allows this kind of feature without any of the hacks and > A> > > extentions discussed here. > A> > > > A> > > We have to properly DESIGN these feature instead of just hacking them > A> > > in. > A> > > A> > Well, I agree, that it is about how to design it. > A> > But I do not think that proposed solution is hackish, and I not alone > A> > with it. > A> > A> It breaks the PFIL_HOOKS API. > > None of prototypes in pfil.h are changed. Where is API breakage? You call > "API breakage" the fact that I'm going to *use* this API not the way you > use it. First you change the way pfil_hooks is used in a multiprotocol incompatible way. Lets have a look at ip_input(): pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL); ^^^^^^^^^^^^^^ PFIL_HOOKS is a generic API with clear semantics. You can't just replace this inet_pfil_hook with an interface specific one. That would be INET only and you'd have to do the same for IPv6, IPX and whatever other protocols may come. Secondly the stuct ifnet would have to be extended with a pfil_head pointer for every protocol family in the system. This would be non-dynamic and would require a recompile of all drivers etc. when a protocol is added or removed. Struct ifnet is not a dynamic structure. Thirdly have the modules that are hooked into the pfil_hooks no idea that they have to register multiple times with multiple chains and so on. This means that all firewall packages in FreeBSD need to be adjusted to deal with these changes, often in a non-trivial way, to continue to function. And we lose the compatibility with NetBSD where the PFIL_HOOKS API comes from. I hope you understand now that you change the PFIL_HOOKS API not in the binary or structure way but in use and semantics. So please put the PFIL_HOOKS discussion to a rest now as it simply won't happen. There are perfect alternatives to change IPFW to fit your needs within IPFW itself and with the information supplied by the PFIL_HOOKS API. -- Andre