On Mon, Oct 14, 2002 at 09:59:49PM +0200, Bart De Schuymer wrote:
> Hello netfilter team and others,
Hi Bart.
> DaveM suggested I talk to you (netfilter team) about this.
Thanks, unfortunately there was this huge delay before your email was answered. Sorry for this inconvenience.
> What's bridge-netfilter: the mapping of the IPv4 onto the bridge hooks, to
> make a powerful bridging firewall.
Yes, I am aware of this project. In fact, Lennert did a presentation about
this on the netfilter developer workshop in Nov 2001
> The solution I like best (and David seems to not mind) is adding one pointer
> to a struct nf_bridge_info in the skbuff. So, adding one new member.
That would be acceptable.
> Another suggestion by David is this:
>
> struct nf_ct_info {
> union {
> struct nf_conntrack *master;
> struct nf_bridge_info *brinfo;
> } u;
> };
>
> But I don't think this will not work because master will be in use while we
> need brinfo.
no, it will not work. It clashes as soon as you want to use connection
tracking on a bridging firewall.
> So another solution could be this:
>
> struct nf_ct_info {
> struct nf_conntrack *master;
> struct nf_bridge_info *brinfo;
> };
This is, of course, possible.
> But I don't know anything about the intricacies of adding this.
I don't see any big problems. If master stays the first member in struct
nf_ct_info, it should even work if there is a mis-use somewhere in the code,
referencing directly to nf_ct_info instead of nf_ct_info->master.
> Do you have any other suggestions? Comments? Help?
It's great seeing that the bridging stuff finally gets included.
> Also, could you have a look at the current patch, to spot any other
> obstacles/things you don't like?
> The patch is available at:
> http://users.pandora.be/bart.de.schuymer/ebtables/br-nf/bridge-nf-0.0.10-dev-pre1-against-2.5.42.diff
I have read the new (2.5.44) patch.
The only issue that comes to my mind is:
ip_packet_match is getting a way too long argument list. Can't you write the
matching against physical in/out devices as iptables match extension? (like
ipt_physdev.c?)
> Another question:
> I've been told it is the general concensus that this bridge firewall should
> be compiled in the kernel if CONFIG_NETFILTER=y. Or should it be a user
> option?
> It is predicted that using a user option will give alot of questions about
> the bridge firewall not working.
> Do you have any strong opinion about this?
Mh. Since bridging firewall is cool, but not something everybody will
use by default [and it adds code as well as enlarges the skb], I think it
should be a compiletime kernel config option.
> cheers,
> Bart
-- Live long and prosper - Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/ ============================================================================ "If this were a dictatorship, it'd be a heck of a lot easier, just so long as I'm the dictator." -- George W. Bush Dec 18, 2000
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:22 EST