lkml.org 
[lkml]   [2002]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.181 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site