Pablo Neira Ayuso wrote:
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.
Yes, the question is how many messages will be filtered.
Since with unicasting and two listeners we potentially
have to construct messages twice, with anything > 50%
delivery rate the socket filtering should be more efficient
(not counting filtering overhead itself).
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?
That should be fairly simple since you're usually only
looking at addresses, ports and protocol states. For
a start this could be hardcoded in a few templates.
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.
I wasn't aware that we still have holes in the skb. Anyway,
adding new skb members is a hard sale for something that
really only a very small subset of users need.
--
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
