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