Jozsef Kadlecsik wrote: > On Wed, 20 Jan 2010, Patrick McHardy wrote: > >> Jozsef Kadlecsik wrote: >>> On Tue, 19 Jan 2010, Patrick McHardy wrote: >>> >>>> 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? > > I have only one case, but I think that's worth it: "sparse" conntrack > replication. Start replicating the conntrack entry after it reached the > ASSURED state and that way it's SYN-flood resistant. (Of course conntrack > could filter out the NEW/SEEN_REPLY state changes and wait for ASSURED, > but then the events are just sent unnecessarily.) Sounds reasonable :) I'll add back the IPCT_ASSURED bit and will post the entire series for review. -- 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
