Users needed to test Wi-Fi stability on Linksys WRT3200ACM & WRT32X on OpenWrt 21.02

There are a number of notes on the bottom of the WRT3200ACM page https://openwrt.org/toh/linksys/wrt3200acm#general based on past recommendations. This includes the use of channel 36 for 5GHz.

Ah perfect, I thanks!

Even after the fix, I started seeing instability on both 2.4 and 5 GHz bands. Nothing worked for 2.4GHz, I only got 5GHz to function properly on channel 149.

I eventually gave up on the 2.4GHz band and bought an AP. Had to lay cat6 cable around the house (because the AP doesn’t support channel 149) which was a long and painful job but finally, I have no issues with Wi-Fi anymore.

1 Like

22.03 was just released, so it'll be interesting to see if these issues persist.

I've been using the release candidates for a month or two on my WRT3200ACM and it's been perfectly stable with no change in functionality from 21.02.

2 Likes

Same with my WRT32X, runs great zero issues on 22.03 had a 30 day uptime on rc6 before a clean flash for the final release. Use a lot of added packages too.

I've been watching this thread for a while, and I'm still on 19.07. I tried upgrading on an earlier 22 release, but it had lots of issues, and WiFi stability is a huge priority for me. I may give 22.03 a try on a weekend I have more time.

I deferred upgrading to 21.02 for a long time on my WRT3200ACM, but after 21.02.2 I did. I still found issues with the 5.0 GHz band despite the wireless fix. After around 20 days or so the 5.0 GHz band would not allow connections to clients anymore and restarting the wireless radio didn't work.

I found disabling AMSDU seems to resolve this issue and 5.0 GHz band works reliably continuously. You can add this to 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"

I didn't need to do it on 19.07, but whatever works given mwlwifi issues and lack of development now.

I'm not updating to 22.03 for now to give time for iptables and nftables to mature and also for me to plan migrating properly.

The mwlwifi driver developer suggested that's only needed for wrt1200 and wrt1900 series routers (88W8864 wifi chip), not the wrt3200 and wrt32x which have the newer 88W8964. I'm not sure it does anything good for your router, I've never had to disable amsdu on my wrt32x.

1 Like

Interesting, it seems to have had some effect at least for me as uptime is better with it off. It is quite possible it was something else configuration wise, although I don't know what as I haven't changed anything else wireless related in a long time.

Maybe, for refence here is the original bug report thread from a few years ago where it started:
[https://github.com/kaloz/mwlwifi/issues/313]

Sadly mwlwifi project has been abandoned for years. U6-Lite wifi 6 ap took care of that.

Sadly mwlwifi project has been abandoned for years. U6-Lite wifi 6 ap took care of that.

Same here, this is still my main router and can't find anything with such good hardware, but the WIFI runs on U6-Lite now

1 Like

Upgraded to 22.03.0 yesterday, and my WRT32X is now having trouble on 5GHz. It was running flawlessly on 21.02.3. I did a clean upgrade (didn't preserve any settings), and reconfigured by hand to reproduce the same settings I had before: 5GHz only on radio0, channels 36/149, WPA2-PSK only. No other tweaks.

It seemed to work initially, but when I woke up today all my WiFi devices were disconnected and wouldn't reconnect. Tried restarting radio0 several times and changing some settings, no help.

Just restarted the router entirely and it's fine again, at least for now.

1 Like

Having the same problem:

5Ghz was unstable on my Linksys WRT1900ACS with OpenWrt 21.02 on channel 36.

Changing the channel to anything higher than channel 36 rendered 5Ghz unusable.

I had hopes, that upgrading to OpenWrt 22.03.0 would solve this, but it didn't.

My Questions:
What are actually possible ways to fix this ?
Are there other drivers that could be used ?

Thanks for info and help on this.

sklerotraficon

Unfortunately the no one have the source for the WIIF firmware/driver, last commit to the WIFI driver was 3 years ago: https://github.com/kaloz/mwlwifi

some background info, wont solve your problem, but gives some context:

All that said, having access to the unknown code underlying the binary driver shouldn't be strictly necessary, given we know that past versions of OpenWRT did not cause this problem. Someone with knowledge of OpenWRT code and one of these routers on hand should be able to, given time, first, reproduce the issue, and then at least narrow down which specific code change was where the 5GHz problem started.
This sort of bisecting is exactly what @adworacz did to find the source of the other problem that was discussed in this thread last year.

1 Like

Following up on my experience with 22.03.0 so far -- after almost a week, the 5GHz issues haven't returned on my WRT32X. (I previously reported that all my devices got disconnected and couldn't get back on until I did a full reboot.)

Not sure what changed since that first day I initially installed & configured 22.03.0. I'm using the same 5GHz channels, WPA2-PSK, and the 2.4GHz radio is still disabled just like I had it with 21.02.3. No mods or tweaks to drivers or other settings. I did do a channel scan and a couple of reboots to configure SQM and the firewall, but those shouldn't have affected WiFi.

Again, other than that first day, my 5GHz network has been stable so far.

Given the open issue history of that device family since v19 (the non-fixable and probably fixable), I guess there are less and less someones left who are willing to invest time to do that. Could be that most developers and bisectors have turned to different devices.

1 Like

It’s sad that the binary file has an explicit license that reverse engineering it is not allowed. So any attempts at providing an open source driver derived from the binary would probably merit a lawsuit, but no one at Linksys wants to give up the code.

I wonder if there are ways to reverse from the actual hardware itself, as that should be allowed last I checked. But that task seems to be almost impossible..