Patrick McHardy wrote: > Pablo Neira Ayuso wrote: >> I link this BSF-based solution, however, would they be flexible enough >> for my needs? Another question that comes to my mind, isn't this >> filtering coming to late? I mean, we have to invest time to build the >> netlink message and then decide if we want to replicate it or not. > > Its quite flexible, but you're right that it only takes place > after the message has already been constructed. The advantage > over selective unicast delivery is that if messages are consumed > by multiple receivers we only need to construct them once. On most system the number of listener would be usually 2: ulogd and conntrack-daemon. I remember that someone told during the workshop that building netlink messages is resource consuming. > The downside is that messages that will get filtered on all > sockets are constructed completely unnecessary. More concerns, if we go BSF, I'll have to implement some kind of "compiler" to translate user options from conntrackd.conf to BSF code. Using iptables for this seems to be more user-friendly? I have a patch here that I'll send you as I have some spare time. It introduces a nfevent field in the skbuff by using a 2 bytes free hole in it. Thus, I only have to insert one hook for the 'events' table. -- "Los honestos son inadaptados sociales" -- Les Luthiers -- 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
