Messages in this thread | | | Date | Thu, 24 Oct 2002 10:16:56 +0200 | From | Harald Welte <> | Subject | Re: [netfilter-core] [RFC] place to put bridge-netfilter specific data in the skbuff |
| |
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 [unhandled content-type:application/pgp-signature] | |