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.