Re: Most optimal method to dump UDP conntrack entries

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

On Mon, Nov 11, 2024 at 01:09:46PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > This is how it is implemented today and it works, but it does not
> > > handle process restarts per example, or is not resilient to errors.
> > > The implementation is also much more complex because we need to
> > > implement all the possible edge cases that can leave stale entries
> > 
> > It should also be possible to shrink timeouts on restart via conntrack -U
> > which would be similar to the approach that Florian is proposing, but from
> > control plane rather than updating existing UDP timeout policy.
> 
> The time and effort needed to make something as basic as NAT
> work properly is jus silly.
> 
> Lets fix conntrack so this "just works".

Ok, then...

+static bool udp_ts_reply(struct nf_conn *ct, enum ip_conntrack_dir dir)
+{
+       bool is_reply = READ_ONCE(ct->proto.udp.last_dir) != dir;
+
+       if (is_reply)
+               WRITE_ONCE(ct->proto.udp.last_dir, dir);
+
+       return is_reply;
+}

... if packet in the other direction is seen, then...

+       if (udp_ts_reply(ct, dir))
+               nf_ct_refresh_acct(ct, ctinfo, skb, extra);

... conntrack entry is refreshed?

Will this work for, let's say, RTP traffic which goes over UDP and it
is unidirectional? Well, maybe you could occasionally see a RCTP
packet as reply to get statistics, but those could just not be
available.

I am not sure we can make assumptions on the direction like this, any
application protocol could run over UDP.