On Wednesday 2008-04-09 16:36, Patrick McHardy wrote: > Jan Engelhardt wrote: >> On Tuesday 2008-03-25 13:57, Patrick McHardy wrote: >> > > > which means ebtables actually comes after iptables, and hence, >> > > > your mark 3 will not show up as you expected. >> > Indeed, on output bridge netfilter will run after IPv4 netfilter. >> > Does that explain things? >> >> 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 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. -- 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
