Linksys E8450 (MT7622): Enabling software flow offload causes erratic wired network failures

[robhancock]

With:
Model: Linksys E8450 (UBI)
Target Platform: mediatek/mt7622
Firmware Version: OpenWrt SNAPSHOT r19435-c5f113c43f / LuCI Master git-22.089.43958-7110635
Kernel Version: 5.10.110

Enabling Software Flow Offload seems to basically kill all wired network traffic. From running tcpdump, it appears the router is receiving packets but not sending any (or at least what is sent doesn't actually go out), so it is unable to obtain an WAN IP address properly or communicate with LAN devices. The router is still reachable over wireless.

Not sure what other debug info would be useful here?

[Matthaiks]

I've noticed a similar problem but with the PPPoE, Hardware Flow Offloading nad MT7621.

#9420 (comment)

[robhancock]

I was trying to verify that software flow offload was the cause here, as it seems like after some initial tests it might not be the case. There were two issues causing confusion:

-I'm not sure if enabling software flow offload is supposed to take effect without a reboot, however at least the bad effects it (sometimes) causes only seem to happen after a reboot

-It doesn't seem like it ALWAYS fails when it is enabled, sometimes it seems to work?

It seems like the actual symptoms caused may also be somewhat random - in some cases it seems like the router is unable to receive packets properly, in other cases it seems like what it is transmitting is not actually sent. But in general, it seems that enabling this option on current snapshot builds (now running r19487-3f2d0703b6) has a high likelihood of causing all hell to break loose with the wired ports on E8450, at least in my setup.

If anyone has some suggestions for troubleshooting, I can try them out.

[atiensivu]

I had issues like this during the transition from fw3 and fw4 in snapshot. I ended up doing a complete reset of the configurations and it ended up working solid again. If you're taking an older config setup, this might be related. Just another datapoint. 'firstboot' and try a simple setup and see if it repeats.

[Matthaiks]

Using a fresh config didn't help in my case.

[robhancock]

I created this setup after the transition would have happened, so I don't think that is a factor in this case.

[robhancock]

I confirmed this still occurs using snapshot r19583-4e8d095013 which uses kernel 5.15.35. After enabling software flow offload and rebooting, things seemed to work well. After rebooting again, I couldn't get access via the LAN ports. After power cycling, I could get in on the LAN but the WAN couldn't get an IPv4 address. So the random/flaky behavior still persists.

Strangely enough, after then disabling flow offload and rebooting, I also had to reboot my cable modem before the WAN would get an IPv4 address again. Almost like it had been sending DHCP requests from a different MAC and the modem was locking out DHCP requests because it was only allowing one local device to get an IP?

I'm wondering if something is going haywire in the switch driver when flow offload is enabled, at least sometimes. Based on my experience, I would say one should only conclude it is fully working if it survives multiple reboots and power cycles with no failures.

[Matthaiks]

Commits from May 6, 2022 fixed my problem.

[robhancock]

I tested a snapshot r19615-580723e86a with the changes @Matthaiks mentioned, with no improvement here. In fact, it seemed possibly worse, as on the first reboot after upgrading it got into the "bad" state before even enabling flow offload? Eventually after resetting to defaults and reloading the previous configuration I was able to get things working with offload turned off.

I also poked around a bit more with it in the "bad" state via a wireless connection to the device. "ip -s link" was showing zero RX packets on any of the lan or wan ports. It seemed like TX packets from the device were going out, but it wasn't processing anything coming in.

I'm wondering if this is related to the fact I've got a guest network set up, with separate SSIDs on both bands as well as wired port 4 split onto it. /etc/config/network contains:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdc1:36aa:9133::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '64'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix '60'

config interface 'guest'
	option proto 'static'
	option device 'br-guest'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option ip6assign '64'
	option ip6hint '1'

config device
	option type 'bridge'
	option name 'br-guest'
	list ports 'lan4'

I saw another mention in #9854 about software offloading in bridge configurations, maybe this is related?

[schuettecarsten]

On my Linksys E8450, I also run into connection drops and download interruptions on large files when software flow offloading is active. But after #9854, at least hardware flow offloading works.