Re: [PATCH 4/4] netfilter: xtables: merge registration structure to NFPROTO_UNSPEC

[Patrick McHardy <kaber@trash.net>]

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.