Date: Wed, 15 Dec 2004 11:50:55 +0100 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <41C0170F.95449D19@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C0170F.95449D19>