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