Re: Most optimal method to dump UDP conntrack entries

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Nov 11, 2024 at 01:09:46PM +0100, Florian Westphal wrote:
> > 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?

Yes.

> 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.

We could add a || ct->master to the is_reply test.

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

What about adding a CT template option to control the behaviour?

More work, but would avoid any compat concerns.