Jan Engelhardt wrote: > On Wednesday 2010-03-31 11:45, Patrick McHardy wrote: > >>>>>> >>>>>> >>>>>>>>> This will work because x_tables scans for NFPROTO_UNSPEC, >>>>>>>>> and arp/ebtables just using x_tables :-) >>>>>>>>> >>>>>>>>> >>>>>>>> I'm not sure I'm parsing this correctly. Both will find the match, >>>>>>>> however the nf_ct_l3proto_try_module_get() call will fail >>>>>>>> >>>>>>>> >>>>>>> It won't fail - it is using par->family, not par->match->family. >>>>>>> >>>>>>> >>>>>> That's broken then. >>>>>> >>> Also, NFPROTO_BRIDGE is special anyway - it does not refer to an L3 >>> protocol actually, but to L2 - so, well, it's kinda moot to muse >>> about the possibility of calling nf_ct_get(NFPROTO_BRIDGE). >>> >> I assume you mean nf_ct_l3proto_try_module_get(). Just as I was saying, >> it *will* fail for NFPROTO_BRIDGE/ARP, so everything should be fine. You >> disputed this however. >> > > Ah... genuine mixup. I took the "both" in "Both will find the match" > as iptables and ip6tables because they used to find it before. > OK, so we're fine. >>> If you >>> _really_ wanted to support state matching at the ARP/EB level, you >>> would anyhow have to add a separate ->check function that loads all >>> possible L3 trackers. Which is not a big problem per se >>> (see patch - no touching of NFPROTO_UNSPEC was needed). >>> >>> >> That doesn't really work since bridge netfilter is (partially) invoked >> before conntrack. >> > > Not everywhere, indeed. But there are three theoretically usable blue boxes > (input, forward, output) in http://jengelh.medozas.de/images/nf-packet-flow.png > that come after conntrack. :-) > Maybe, but since bridge netfilter would have to invoke the IPv4/IPv6 hooks anyways for conntrack, it doesn't seem to be very useful. What I'd like a lot more would be if ebtables could run conntrack/NAT and other useful modules directly so we could get rid of most of "integration" mess. Not sure if that's really possible though. -- 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
