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.) Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- 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
