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