Re: [RFC] conntrack event framework speedup

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

 



Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > 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.

The filtering isn't global, its per flow.  Provided
nf_conntrack_events=0, then only flows where the first packet matched
a -j CT rule will generate events, AND only those events that were
specified in its event mask.

So, flows that did not match any CT rule never generate an event, and,
therefore, changes to the kernel should not auto-add the extension for
them.

I don't see how that mechanism can be preserved without the ability to
set nf_conntrack_events=0.

When a new conntrack is generated, the test is (in current kernels):

'add the event cache extension if the template has an event cache
 extension OR if the sysctl is enabled'.

So, changing it to
'add the event cache extension if the template has an event cache
 extension OR if we have a listener' is not the same, unfortunately.

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

Yes, thats correct, it tells kernel there is an active subscriber for
events.

> What am I missing?

I can't tell the following two cases apart:

1. templates are active and user wants events ONLY for the chosen flow,
   e.g. tcp.
2. templates are active and user wants only particular events for the
   chosen flows, but all events for the rest.


1) is done by templates + setting the sysctl to 0.
2) is done by templates + setting the sysctl to 1.

With 'assume 1 if listener active', we can only provide functionality of 2).

I finished testing of a prototype and it appears that functionality is ok,
I've pushed this here:
https://git.breakpoint.cc/cgit/fw/nf-next.git/log/?h=nf_ct_events_02

(only the top-most 4 changes are relevant).



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

  Powered by Linux