Re: Ebtables hook order anomaly

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Wednesday 2008-04-09 16:36, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> It explains things, but having the feature removed is not nice.
>>> I cannot deny that the previous code was real a hook spaghetteria,
>>> but how could it be done better?
>> Good question. The order on output is logically correct, so I
>> wouldn't change it. I never liked the invocation of IP hooks
>> from bridging at all, so long-term we could consider making
>> the features people want to bridging available "natively"
>> (like conntrack/NAT/...).
> 
> Can't quite imagine what you mean. Bridging is currently
> implemented using a separate netdevice, much like bonding
> or gre/ipip/tun/tap tunnels.
> 
> Well bridging is essentially a few pieces:
> 
>  - "forward" packets without changing MAC
> 
>  - arpreply engine

A pure bridge doesn't need ARP. I don't get your point,
but my suggestion might not make much sense, I haven't
really thought about this.

> I have often come across needing a bridge device with a single port and
> brouting=drop only because of ebt_arpreply; I have immediate plans
> to remove this limitation.
> 
>  - STP
> 
> I seem to remember ideas about a userspace daemon were floating
> around..
> 
>  - filtering on L2
> 
> there has been a L2-hooks back in the 2.4 days (at least the context
> looks like it), and given that the ebtables targets now use
> xtables, the l2hooks patch would actually be real easy.

They were used for the kernel ct_sync implementation. Why
would you use them for briding, it has its own hooks?