Re: [RFC] bridge-nf -- map IPv4 hooks onto bridge hooks, vs 2.5.42

[Bart De Schuymer]

On Monday 14 October 2002 20:01, David S. Miller wrote:
Hello,

These are probably stupid questions to you, but here it goes.

> These changes cannot go in:
>
> 1) There is no reason the 'okfn' you use cannot be the
>    function doing the MAC header copy.
>
>    This is how this is supposed to work.
>
>    I explained in that long thread a few weeks ago how
>    this copy may not be placed in the generic IP code.
>    This is final, you must find a way to make this copy
>    without touching ipv4/*.c

I've checked the skb->dst->hh field and it (or skb->dst itself) was NULL for 
purely bridged packets. So we'd have to fill this in ourselves. Can the 
bridge code go fill in a skb->dst and skb->dst->hh? Is this considered clean?

> 2) The netfilter changes need to be approved by the netfilter
>    team.
>
>    I suspect, like myself, they will barf at the phys{in,out}dev
>    additions to sk_buff.  We already have enough junk sitting
>    in sk_buff making it larger than it needs to be.

I added a third member as well... It's needed too, in my opinion.
There could ofcourse be added a pointer to a struct containing these three 
values (and a copied Ethernet header). Then we go from 3 to 1 extra member...
Anyway, it's not like Lennert and me like adding new members, but we need to 
save those things somewhere...

>    Perhaps you can hang this off the nf_conntrack pointer and
>    specify a destructor.
>
> 3) The bridging layer changes need to be approved by Lennert.
>    But I'd suggest working out #1 and #2 first.

So if I change
struct nf_conntrack {
	atomic_t use;
	void (*destroy)(struct nf_conntrack *);
};

into this:

struct nf_conntrack {
	atomic_t use;
	void (*destroy)(struct nf_conntrack *);
	struct brnf_data *brnf;
};

I can keep the copy of the Ethernet header in the struct brnf_data too (then I 
don't have to touch skbuff->dst).
The skbuff->nfct field can already be in use by an IP connection tracker (or 
something), so I can't use my own destroy function.
So I'd have to go do something in 
net/ipv4/netfilter/ip_conntrack_core.c::destroy_conntrack() and I don't know 
that stuff.
I sure don't like this solution more than the current situation.

Anyway, mapping the IPv4 hooks onto the bridge hooks is in my opinion by 
definition a hack. But a very useful hack. So if you want this in the kernel 
you'll have to be forgiving. Or present a nice solution, because I and 
probably Lennert really don't see a nice(r) solution.

So, the best solution I can think of is adding a skbuff->brnf pointer to a 
struct brnf_data. This will get rid of the copy in ip_output.c. Is that 
enough? This will uglify the ip_tables.c patch however.

-- 
cheers,
Bart