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?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
