Mt7622 hardware flow offload bug?

For Developers
1

Hi, just a small question. I'm having recurring problems where my OpenWRT firewall loses a UDP conntrack between an IPv6 host inside my network and one outside. Firewalling is pretty straightforward.

What happens is that conntrack -E -o timestamp -p udp -f ipv6 does not show a connection between a host inside the network and outside. There is however an older conntrack entry with a different port. I.e. the one that is there:
udp 17 src=2a02:XXXX:13eb dst=2a01:XXXX:14a2 sport=40678 dport=37625 packets=297355 bytes=70650880 src=2a01:XXXX:14a2 dst=2a02:XXXX:13eb sport=37625 dport=40678 packets=487724 bytes=97575028 [HW_OFFLOAD] mark=0 use=2

The one the machine tries to setup is all the same, but coming from UDP 50021.

Now I was going to send a message to the netfilter mailing list but I'm actually suspecting the "HW_OFFLOAD" part of the visible connection. Is there a way to test this? (Apart from turning off the HW Offload, as I just did, and wait a few weeks?)

2

Please post output of

ubus call system board

If other conntrack entry is with different ports it does not interfere in any way, can you post it too?

Also add ethtool -i <adapter name> driver information of offload-enabled devices.
nft list ruleset | head -20

table inet fw4 {
        flowtable ft {
                hook ingress priority filter
                devices = { eth0, eth5 } <--- these
                counter
        }

Does the observation occur with soft offload only?

3

Hi,
kernel 5.15.137
system: ARMv8 Processor rev 4
model: Netgear WAX206, board_name: netgear,wax206
OpenWrt 23.05.2, revision r23630-842932a63d
mediatek/mt7622

I have HW flow offloading unchecked now for a while, and no more connection issues. Turning it "on" will stop a wireguard connection from one of the hosts behind this openwrt gateway.

devices = { lan1, lan2, lan3, lan4, pppoe-wan, wl0-ap0, wl1-ap0 } but that's not the whole story, as most of these are switch ports attached to eth0:

# ethtool -i eth0
driver: mtk_soc_eth
version: 5.15.137
firmware-version: 
expansion-rom-version: 
bus-info: 1b100000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
root@gateway:/var/log# ethtool -i lan4
driver: dsa
version: 5.15.137
firmware-version: N/A
expansion-rom-version: 
bus-info: platform
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

If you want me to turn on HW flow offloading again, please say so. As far as I remember, the firewalling problem will occur after some 24 hours - I'm not entirely sure, but it kept coming up.

4

Yes, try to reproduce with sw offload.
will not hurt (nor change anything in regard of offload) to sysupgrade to 23.05.3.

i'd bet blindly on 30s udp state timeout which also hurts http3, but try first with defaults.

5

Several months ago, you had to config-tweak HW offloading on Mediatek mt7621 devices, to properly work in some corner cases.

in /etc/sysctl.conf add:
net.netfilter.nf_conntrack_tcp_no_window_check=1

see also How to check if hardware NAT (flow offloading) is enabled? - #8 by Pico (there were some more older threads about "conntrack")

In the past (and probably still today) the HW offload checkmark in LuCi would not take care of that additional config file setting. But I donno, if this is still required to do or how mt7622/mt79.. behaves.

6

That is fixed in 23.05.3 and that parameter is not present anymore.
You can cherry-pick some patches from main firewall4

namely mssfix is critical to pppoe or non-1500 MTU interfaces
and vmap dispatch makes slowpath faster
Every file is interchangeable from 23.05.0 to master branch.

7

I'm not sure what you mean by this. Do I need a special MSS-fix? My wan interface does run PPPoE and has its mtu advertised as 1504, is that the culprit? Having flow_offloading_hw '1' makes my Wireguard VPN halt randomly, after a /etc/init.d/firewall restart it works again.
As far as I'm seeing, UDP WG packets are simply blocked.

8

flow offload does not per se affect locally running services.
Create mssfix.nft file in: /etc/nftables.d/

chain mangle_postrouting {
                type filter hook postrouting priority mangle; policy accept;
              oif $wan_devices tcp flags syn / syn,fin,rst tcp option maxseg size set rt mtu
}

roughly equals:

Sudden packet loss is horifying, please check packets are still arriving with tcpdump.

1 Like