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. >> 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. :-) -- 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
