Hi Pablo, On Tue, 12 May 2009, Pablo Neira Ayuso wrote: > >> BTW, I don't like using connmark for this. > > > > You mean the CONNMARK target? I deliberately avoided using the connection > > marks. Or "marking" the connections by the eventmask? But that is the most > > effective way to filter the events. > > I see, but something similar to nfnetlink_queue/NFQUEUE (per-process) > together with an extended version of the `conntrack match' for events > would be more flexible. The match solution cannot cover cases when the actual event happens at confirmation while the target can "see" all. But I agree, that "matching" events would be more natural for the users than marking. > > Another very simple choice can be to add more multicast groups > > according to the sort of events. We can get more fine grain event > > selection while keeping it per-process. Currently, there's only three > > sort of events: NEW, UPDATE and DESTROY. We can add more netlink > > multicast groups to allow user-space to select what kind of events > > they are interested. > > netlink doesn't seem to support overlapping event groups, and UPDATE and > ASSURED groups would overlap. Thus, we'll need to call > netlink_broadcast() twice. I still don't find a non-intrusive way to do > some non-BPF-based filtering :( Why don't we introduce groups like nflog and nfqueue? res_id is unused in ctnetlink, so we could use it to pair the application and the event flow. The CONNMARK target with the approach I suggest could easily be extended to cover the res_id too and store it in the conntrack entry. That'd still just amount 32 bits (eventmask + res_id) in nf_conn which is required. 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
