Re: [RFC] conntrack event framework speedup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 15, 2022 at 11:07:48PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > On Tue, Mar 15, 2022 at 10:41:21PM +0100, Florian Westphal wrote:
> > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > > > > add new net.netfilter.nf_conntrack_events default mode: 2, autodetect.
> > > > 
> > > > Probably the sysctl entry does not make any sense anymore if you can
> > > > autodetect when there is a listener?
> > > 
> > > Hmmm, did not consider that.  I *think* we still want to allow to
> > > disable the feature because of xt_CT/nft_ct.
> > > 
> > > Someone might have nf_conntrack_events=0 and tehy could be using
> > > explicit configuration via templates (and then expect that only
> > > those flows that matched a '-j CT' rule generate events.
> > 
> > Maybe could you bump the ctnetlink_listeners counter when -j CT is
> > used with event filtering?
> 
> Hmmm, I don't think that will work.  The -j CT thing can be used to
> enable event reporting (including the event type) for particular flows
> only.

IIRC, it allows to filter what events are of your interest in a global
fashion.

> E.g. users might do:
> 
> nf_conntrack_events=0
> and then only enable destroy events for tcp traffic on port 22, 80, 443
> (arbitrary example).
> 
> If I bump the listen-count, then they will see event reports for
> for udp timeouts and everything else.

Are you sure? -j CT sets on the event mask. The explicit -j CT rules
means userspace want to listen to events, but only those that you
specified. So it is the same as having a userspace process to listen,
but the global filtering applies.

My understanding is that the listen-count tells that packets should
follow ct netlink event path.

What am I missing?

> IDEALLY we could ditch the sysctl, the autotuning and tell users they
> now need to configure events with nft/iptables but given the 'ct
> helpers' thing I'm sure we'll get lots of complaits about broken event
> reporting ;-)

It won't be flexible enough for all usecases. The ct event filter from
rule is global.

> > > @@ -691,11 +691,47 @@ static int nfnetlink_bind(struct net *net, int group)
> > >         if (!ss)
> > >                 request_module_nowait("nfnetlink-subsys-%d", type);
> > > +
> > > +       if (type == NFNL_SUBSYS_CTNETLINK) {
> > > +               struct nfnl_net *nfnlnet = nfnl_pernet(net);
> > > +
> > > +               nfnl_lock(NFNL_SUBSYS_CTNETLINK);
> > > +               nfnlnet->ctnetlink_listeners++;
> > > +               if (nfnlnet->ctnetlink_listeners == 1)
> > > +                       net->ct.ctnetlink_has_listener = true;
> > > +               nfnl_unlock(NFNL_SUBSYS_CTNETLINK);
> > > 
> > > and then check 'net->ct.ctnetlink_has_listener' when allocating
> > > a new conntrack.
> > 
> > LGTM.
> 
> Thanks.  I will work on a parototype along these lines and see where
> that leads.

Let me know,

Thanks



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux