Re: RFC: netfilter: xtables: add CT target

[Patrick McHardy <kaber@trash.net>]

Jozsef Kadlecsik wrote:
> Hi Patrick,
> 
> On Tue, 19 Jan 2010, Patrick McHardy wrote:
> 
>> Jozsef Kadlecsik wrote:
>>> On Tue, 19 Jan 2010, Patrick McHardy wrote:
>>>
>>>> The attached two patches add a 'CT' target to specify parameters
>>>> used during conntrack creation. This can be used to manually attach
>>>> a helper to a connection. A couple of patches I'm still working
>>>> on will additionally use this for the "conntrack zones" classification.
>>>>
>>>> I'm wondering if anyone has further ideas of parameters that might
>>>> make sense to support. We could for example move parameters like
>>>> sip_direct_signalling and sip_direct_media into the helper structure
>>>> and allow to set them dynamically for each connection. Or perhaps
>>>> selectively enable netlink events.
>>> Selectively enabling netlink events (not only per connection but per event 
>>> type) would be cool! Last year I used the CONNMARK target for that purpose 
>>> - maybe it fits better to the CT target.
>> I think it would be a good fit since you probably would want to specify
>> the events to be delivered before the conntrack is created.
>>
>> Adding an event mask to the ecache extension also looks unproblematic.
>> You could then use a rule like this:
>>
>> iptables -t raw .. -j CT --ctevents new,related,protoinfo,helper
>>
>> or something like that. Are the existing event types fine grained
>> enough for this?
> 
> The possible events were cut back strongly and now the conntrack state 
> changes ASSURED and SEEN_REPLY cannot be distinguished. In my opinion 
> either SEEN_REPLY should not trigger an event at all or IPCT_ASSURED 
> should be put back.

I think it makes sense to generate an event for SEEN_REPLY since
its a synchronizable event (ctnetlink can also set the SEEN_REPLY
bit). I'm not opposed to add back IPCT_ASSURED, but I'm wondering,
in what case would userspace be interested in only one of both
updates?

>> Also, should the CT target override the global sysctl setting?
> 
> Yes, definitely.

Thanks.