Date: Wed, 15 Dec 2004 04:15:10 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Gleb Smirnoff <glebius@freebsd.org>, Andre Oppermann <andre@freebsd.org>, vova@fbsd.ru, freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <20041215041510.A85138@xorpc.icir.org> In-Reply-To: <20041215115709.GK54307@cell.sick.ru>; from glebius@freebsd.org on Wed, Dec 15, 2004 at 02:57:09PM %2B0300 References: <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> <41C0170F.95449D19@freebsd.org> <20041215115709.GK54307@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 15, 2004 at 02:57:09PM +0300, Gleb Smirnoff wrote: > On Wed, Dec 15, 2004 at 11:50:55AM +0100, Andre Oppermann wrote: ... > A> Secondly the stuct ifnet would have to be extended with a pfil_head pointer > A> for every protocol family in the system. This would be non-dynamic and > A> would require a recompile of all drivers etc. when a protocol is added or > A> removed. Struct ifnet is not a dynamic structure. > > Yes, it needs to be extended. An alternative is handling a table of > interfaces vs chains inside firewalls. We are speaking a lot of design, > which of above designs is better? Is it going to be easy to edit all these > tables when an interface is destroyed? No. Would it be possible to know > which chains/filters are used on interface via ifconfig? No. Would it be > possible to avoid entering firewall functions when processing interfaces > without ACLs? No. gleb, andre is perfectly right here. struct ifnet should have as little protocol/module specific information as possible. The correct way to design things here is that each module (ipfw, netgraph, routing, ...) which is interested to interface-specific events (such as them being created, deleted, modified, printing the module-specific info related to the interface, etc.) should register a callback with ifconfig and be notified of the event, but store the module-specific information internally. Only in this way you can have loadable modules etc without making a mess. If you are worried about replicating the code that does the lookup from the interface-id to the module-specific info, this is a valid concern but could be worked around by providing a system-wide subsystem by which a module (e.g. a firewall) asks the system "please attach to the interface a chunk of 544 bytes with ID=0xff3022a0" and then can reply to requests such as "give me the pointer to the chunk with ID=0xff3022a0 for interface fxp12" This logically implements an extension of ifnet, but without all the disadvantages of adding fields for each new protocol/module/feature. I am not sure if the event signalling from ifconfig to the interested parties is already there, but that is trivial anyways to set up. Same for the module-specific if-related lookup. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041215041510.A85138>