WRT1900ACS v1 hangs frequently on OpenWrt 21.02.0-rc3

Installing and Using OpenWrt
1

I upgraded my router to OpenWrt v21. Router settings were discarded, so it should be like new. Intermittently, I cannot connect to the internet or the router.

I know there have been some stability issues regarding mwlwifi mostly on WRT3200ACM. I wanted to report this issue might also affects other chipsets in the release candidate.

Do we know what the problem is yet? Are there any workarounds that can ensure a stable connection for Zoom meetings? E.g., can I change any settings (disabling 802.11w didn't help)? Would using another radio (e.g., N) or frequency (i.e., 2.4 GHz) avoid the problem? Is the Belkin AX3200 more stable or expected to be better supported in the future?

Thank you!

System overview

Model: Linksys WRT1900ACS
Architecture: ARMv7 Processor rev 1 (v7l)
Firmware Version: OpenWrt 21.02.0-rc3 r16172-2aba3e9784 / LuCI openwrt-21.02 branch git-21.163.64918-ba57ec5
Kernel Version: 5.4.124

Intermittent pingability of 8.8.4.4 
% ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
64 bytes from 8.8.4.4: icmp_seq=11 ttl=57 time=982.527 ms
64 bytes from 8.8.4.4: icmp_seq=12 ttl=57 time=31.617 ms
64 bytes from 8.8.4.4: icmp_seq=13 ttl=57 time=24.787 ms
64 bytes from 8.8.4.4: icmp_seq=14 ttl=57 time=23.658 ms
64 bytes from 8.8.4.4: icmp_seq=15 ttl=57 time=24.258 ms
64 bytes from 8.8.4.4: icmp_seq=16 ttl=57 time=31.223 ms
64 bytes from 8.8.4.4: icmp_seq=17 ttl=57 time=24.244 ms
64 bytes from 8.8.4.4: icmp_seq=18 ttl=57 time=22.392 ms
64 bytes from 8.8.4.4: icmp_seq=19 ttl=57 time=27.963 ms
64 bytes from 8.8.4.4: icmp_seq=20 ttl=57 time=25.464 ms
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
64 bytes from 8.8.4.4: icmp_seq=27 ttl=57 time=827.852 ms
64 bytes from 8.8.4.4: icmp_seq=28 ttl=57 time=23.010 ms
64 bytes from 8.8.4.4: icmp_seq=29 ttl=57 time=30.094 ms
64 bytes from 8.8.4.4: icmp_seq=30 ttl=57 time=23.668 ms
64 bytes from 8.8.4.4: icmp_seq=31 ttl=57 time=38.992 ms
64 bytes from 8.8.4.4: icmp_seq=32 ttl=57 time=23.989 ms
64 bytes from 8.8.4.4: icmp_seq=33 ttl=57 time=20.278 ms
64 bytes from 8.8.4.4: icmp_seq=34 ttl=57 time=24.645 ms
64 bytes from 8.8.4.4: icmp_seq=35 ttl=57 time=26.231 ms
Request timeout for icmp_seq 36
Request timeout for icmp_seq 37
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40
Sometimes can ping 8.8.4.4 but not the router 
% ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 56 data bytes
64 bytes from 8.8.4.4: icmp_seq=0 ttl=57 time=25.535 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=57 time=23.753 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=57 time=21.986 ms
^C
--- 8.8.4.4 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.986/23.758/25.535/1.449 ms

% ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
2
Logs during connection problem 
Fri Jul 30 08:06:23 2021 kern.debug kernel: [37887.798590] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:23 2021 kern.debug kernel: [37887.858590] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:24 2021 kern.debug kernel: [37888.494507] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.629479] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.678487] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.738482] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.798491] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.858479] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.918476] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37893.978480] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37894.326743] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:29 2021 kern.debug kernel: [37894.368474] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.428467] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.488468] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.548462] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.608464] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.668464] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.728463] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx
Fri Jul 30 08:06:30 2021 kern.debug kernel: [37894.788459] ieee80211 phy0: Mac80211 start BA xx:xx:xx:xx:xx:xx

Any thoughts?

3

If you do not already have the following, try adding:

/etc/rc.local 
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu && echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu && logger "AMSDU Disabled"
6 Likes
4

This seems to be working so far. My network traffic has changed, so I'll experiment to see if it's fixed.

It looks like this has been a workaround for the WRT1900ACS for over 5 years. Is this problem specific to this router or chipset, or does OpenWRT need more developers?

5

It was identified as a bug in the 88W8864 radio FW (BLOB) and never resolved; of course upstream mwlwifi development has ceased. This issue is not indicated as existing on the 88W8964 FW of the venom or rango.

1 Like
6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.