Re: [netfilter-core] [RFC] place to put bridge-netfilter specific data in the skbuff

[Harald Welte <laforge@gnumonks.org>]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]