Conntrack sometimes not reporting UDP connections properly

Installing and Using OpenWrt
1

Openwrt conntrack sometimes does not report an established udp connection. And then it comes back.

It is an ASSURED bidirectional udp connection with regular 25 second keepalive. I am looking at conntrack db using grep udp /proc/net/nf_conntrack | grep sport=56566

If you look at the details, you see the connection has "packets=92 bytes=10892" before the empty sample, and then "packets=94 bytes=11128" immediately after the empty sample, so the connection record still exists, but it is not being reported at the sample time.

This happens on old v21 openwrt, and also on v24 openwrt, so it is not a new problem.

Are we doing anything special to conntrack on openwrt? Or is this something to report to the netfilter team directly?

net.netfilter.nf_conntrack_udp_timeout = 60
net.netfilter.nf_conntrack_udp_timeout_stream = 180
Linux opentest 5.4.238 #0 Mon Apr 17 13:15:36 2023 mips GNU/Linux

previous state (from 61 seconds ago):
ipv4     2 udp      17 154 src=192.168.1.29 dst=67.23.134.63 sport=56566 dport=57887 packets=92 bytes=10892 src=67.23.134.63 dst=192.168.1.29 sport=57887 dport=56566 packets=299 bytes=21308 [ASSURED] mark=0 zone=0 use=2

at sample time (61 seconds later):
   connection not reported

immediately (approx 10ms) following sample time it is again visible:
ipv4     2 udp      17 179 src=192.168.1.29 dst=67.23.134.63 sport=56566 dport=57887 packets=94 bytes=11128 src=67.23.134.63 dst=192.168.1.29 sport=57887 dport=56566 packets=303 bytes=21608 [ASSURED] mark=0 zone=0 use=2
2

"empty" sample still has some bytes in the headers which are properly accounted.
Suggest you do measurements on modern (nftables/fw4) OpenWrt like 24.10.5, even if there was a problem 5 years ago it will not be addressed.

3

When I say and "empty sample", I mean that I did grep udp /proc/net/nf_conntrack | grep sport=56566 and got nothing back. So that single query produced nothing. But 10ms later, the entry was again visible when doing that same query.

I have the same problem on 24.10.5

4

From the upstream documentation:

The conntrack utility provides a replacement for the limited /proc/net/nf_conntrack interface.

1 Like
5

I understand that the utility is preferred in full Linux.

Do you know if there have been any OpenWRT specific changes to conntrack, and the interface which is available through /proc?

6

See https://github.com/search?q=repo%3Aopenwrt%2Fopenwrt%20netfilter&type=code

1/ support echo f > nf_conntrack
2/ support for flow offload from newer upstream / downstream patches
3/ struct alignment on some platforms....

You name it.
None directly alters debug output.

Which part of "limited functionality" is so hard to understand?

7

Just a wild guess, maybe that happens when your query overlaps with an update of the debug output?

1 Like
8

Could it be that established related is somehow involved? And then when it's suddenly no longer established the packet will hit the actual udp rule again and then again its handled by established related? Also just a wild guess...

Related question. Why isn't there a full conntrack package available? Like with ip-full?

9

The connection entry is definitely the same. You can see approximately the same number of bytes and packets in the before and immediately after. So it is definitely not being seen as a "new" connection

1 Like
10

I suspect not. There is not a lot of network traffic happening on this machine, and the "briefly missing" connection happens 3-6 times per hour