Pretty much this should be enough. Put these three lines into /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
1 Like
Those were exactly my thoughts when I first posted here. My wifi issues with my WRT1900ACS where strangely similar, including the trigger being mostly Apple devices. However I was able to solve it with this.
I am not familiar with OpenWRT's maintainership and policies. Is it possible to upstream the mac80211 version revert just for the WRT3200ACM?
No, it is a global package, common to all devices.
1 Like
Thanks to adworacz for providing build r16335.
I installed AdubWrt 21.02-SNAPSHOT r16335-4b0f87729c / LuCI openwrt-21.02 branch git-21.314.39479-e1ccb66 on my Linksys WRT3200ACM and Wifi now works flawlessly without any cutouts so far.
I also could install several additional packages without any issues and will do further tests, but things look great.
Is it likely, that adworacz's solution will be incorporated into future master builts in the neaar future?
1 Like
Glad to hear your testing is going well!
Is it likely, that adworacz's solution will be incorporated into future master builts in the neaar future?
At this point, no, this fix will never be pushed upstream, as @hnyman states above.
The issue is caused by an incompatibility between the WRT3200ACM / WRT32x firmware + driver and mac80211 5.8+ (which is why I'm using 5.7.5 in this test build). Considering that OpenWRT master is on mac80211 5.10+ and will continue to upgrade moving forwards, we'll never see this fixed upstream.
Either myself or other community members can continue to maintain builds (especially against 21.02) that fix this issue for a while, but the WRT3200ACM and WRT32X's days are numbered unless by some miracle the driver/firmware blobs get updated by the owning company (unlikely at this point).
4 Likes
A big part of me wants to jump straight into the miracle build from today, r16335 (21.02.1 - kernel 5.4.158 - mac80211 downgraded to 5.7.5), and move on from the issue at the heart of this thread. It looks like a few users are already testing this build which is great. I am ridiculously excited to use this build since that is the fruits of the labor from the many users on this thread.
However, I'm going to take one for the team and play with the dirty builds for another day or two because I have some more ideas for hopefully finding the issue that triggers this wireless cutout bug.
My laptop that has not been affected by this bug throughout all of this testing has an Atheros wireless card in it. I actually have an older Intel wireless AC card that I have swapped in my laptop now so that I can test later tonight.
If I can reproduce the issue on this laptop, that would be fantastic. My Atheros card only had one advanced wireless capability setting to modify in Windows. My Intel wifi card driver has 21 or 22 advanced wireless settings that I can fiddle with. So my first goal is to reproduce the issue. The second goal is to see if any of those advanced wireless card driver settings might help to figure out what the issue is. I will have to test various things while only changing one of those settings at a time.
Apple's iPhones and iPads had no real low-level settings to toggle for testing purposes. So hopefully I will be able to reproduce the wireless cutout issue on my Windows laptop that now has an Intel wireless card in it for the purpose of testing.
I wonder if it would be possible to spot the differences between mac80211 5.7.5 and 5.10 (or 5.8).
This can help either fix it upstream or make a patch in OpenWRT to fix it
This is a great idea. However, I am not a developer myself. Some of the more experience developers have suggested that the bug is more than likely in the mwlwifi driver itself, and that is unfortunately abandoned. It has been suggested that the driver would likely have to be rewritten from scratch.
My goal is to find out exactly where its failing and hopefully find some sort of workaround. If we can figure out a workaround, then we can possibly get a patch for a simple workaround into the mwlwifi driver codebase.
The reality is that there are so many uncertainties right now because of all of this. But this latest build of @adworacz 's work may end up serving as some sort community build or fork to keep mwlwifi-based WRT routers alive. And possibly patches and package updates can still occur to a certain degree.
Austin,
Any insight how long a build like this can keep taking updates via opkg without reverting the wifi stability?
I would assume only a sysupgrade from a new mainstream release would overwrite the 5.7.5 version of mac80211?
Thanks!
I also got to this thread when my WRT1900ACS had similar 21.02 problems: 5 Ghz disconnects from iPhones/Mac and my Dell laptop with intel chipset. I didn't realize the chipset differences, and am glad to see the info posted.
1 Like
@kevdel In theory it can take updates via opkg for a long time. The only package effected is kmod-mac80211, so that will need to be specifically held back if any updates come along that might overwrite it.
But it would be easy to re-install the downgraded package from my site. You could just download a file like the following and then run an opkg install <file> on it: https://openwrt.austindw.com/linksys-wrt/working-wireless/r16335/packages/kmod-mac80211_5.4.158+5.7.5-1-1_arm_cortex-a9_vfpv3-d16.ipk
We're probably safe though, since many of the kmod packages are tied to the kernel version, and the kernel doesn't update via opkg, only sysupgrade (new flash).
1 Like
Forcing 5.7.5 on a 21.02 build (and beyond) could be the holy grail of a support bulletin for this issue!
Thanks for the great efforts!
this problem is also common in ddwrt with iPhones / Mac !
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=329061&sid=92522c838c272167e5baacae697b7bf9
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=328995&postdays=0&postorder=asc&start=90
1 Like
Thank you for your recommendation!
I copied here I saved and reboot and there is an improvement in stability in the speed test ...
it is correct how I proceeded ?
Speaking of packages. We could probably point the distfeeds to official OpenWrt 21.02.1 stable package repo for general packages. Obviously, kmods would absolutely have to point to your server though because they are very specific. This is something to think about.
No, it's a temporary workaround, whose real intention would be to pin point what change in upstream mac80211 is a problem for mwlwifi, so the change can be done (properly) for mwlwifi as well, fixing the issue for good.
mac80211 5.7.5 is only usable up to kernel 5.7, it does not work with newer kernels (and we're already at 5.10 in master, with 5.15 in preparation). So while this can keep your device working for the next few months, you will be faced with the very same issue when 22.x.y with kernel 5.10.x gets released next year - unless you really fix mwlwifi 'now'. Also keep in mind that 5.7 isn't an LTS kernel, security support for it has already ended over a year ago and wireless security issues will remain unfixed in mac 5.7.5.
Bisecting kernel/ wireless issues beyond the rough steps of mac80211 versions isn't easy, but may be necessary unless anyone spots (and then confirms) a smoking gun somewhere in the changes between those kernel versions (or mwlwifi's version dependent ifdef zoo).
1 Like
That’s exactly what I did with this build - point to 21.02.1 repos.
You have a good point about the kmod packages though…. I can either pick the exact same commit that point releases for 21.02 are built against, which should ensure kernel compatibility, or build all packages and point the repos at my own server, which is what David did.
I’m kind of leaning towards the former, which keeps the load off my server and aims for perfect compatibility with each 21.02 point release.
1 Like
Hello Peter, so I can assume, that I can update my WRT3200ACM without any WLAN instabilities by flashin it with 21.02.0 ? That would make me happy... if these problems are now fixed 
