Re: [RFC PATCH 0/1] xtables: allow to monitor table update event

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Nicolas,

On Fri, Oct 26, 2012 at 10:05:25AM +0200, Nicolas Dichtel wrote:
> Le 25/10/2012 19:19, Pablo Neira Ayuso a écrit :
> >Hi Nicolas,
> >
> >On Thu, Oct 25, 2012 at 02:52:48PM +0200, Nicolas Dichtel wrote:
> >>Le 15/10/2012 15:10, Nicolas Dichtel a écrit :
> >>>Le 02/10/2012 15:06, Nicolas Dichtel a écrit :
> >>>>The following patch is an example of a userspace tools (in fact, iptables)
> >>>>that use the new netlink API to monitor tables activity.
> >>>>
> >>>>I will also send a patch against libnfnetlink to update linux includes with
> >>>>this new feature.
> >>>>
> >>>>Maybe another API can be used for this feature: adding a setsockopt() on an
> >>>>iptc socket to enable monitoring. When a table is updated, a packet (built with
> >>>>CMSG_* macro for example) can be sent over all sockets that monitor tables
> >>>>acitivity (like km sockets in IPsec). I know that this socket was used only with
> >>>>[g|s]etsockopt(), but this can avoid adding another netlink API.
> >>>>
> >>>>Comments are welcome.
> >>>Any feedback about this patch or the other proposed API?
> >>
> >>Still no comment about this feature? Maybe another option to solve the problem?
> >
> >Adding a new nfnetlink subsystem to just reports table updates seems
> >a bit too much to me.
>
> What about the second proposal? Sending messages through the iptc socket?
> If you have some other ideas, we can change the design of the
> implementation, it's not a problem.

It's been four weeks since you posted your patch and you've been
asking for feedback *every single week* with no results at all. So,
nobody cares.

I see no existing FOSS projects using using this (apart from you
iptables change to report events).

And I already told you, I don't think it makes sense to maintain more
than one firewalling subsystem using netlink as interface.

Please, stop.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html