Unfortunately, my testing into previous firmware blobs was unsuccessful in the end. I apologize if I had gotten any hopes up over this. Firmware 9.3.1.2 was successful for approx. 3 hours, but every attempt after that has failed within 10 minutes. It seems that 3 hours without wifi cutouts on 21.02.0 was comparable to winning the lottery.
I ended up testing firmware 9.3.2.3 after that and, of course, it failed within 10 minutes. So it is clear that my quest for a temporary workaround does not exist within previous firmware blobs.
Sorry everyone.
I think that @adworacz is on the right track to pinning this down in a more definitive method and also that the issue must be within the kernel or possibly mac80211.
One interesting thing that I wanted to point out, though, is that I never lost wireless connectivity on my laptop during all of my testing. It was always the iPhone Xr with the wifi cutouts continuously and had to always toggle the wifi off/on to resolve the cutouts. So over the course of some 40-50 wifi cutouts during my testing, my laptop never cutout.
It seems that a large percentage of devices that trigger this issue are iPhones and iPads. I've seen others saying some Android devices as well. So mobile devices seem particularly affected.
It's a shame that Marvell/Linksys/NXP couldn't simply leave one developer on mwlwifi for occasional patches. Especially for a device that retails for $399 here in Canada at the time that I purchased mine.
Thank you for confirming. As always, I appreciate the time and effort that you are putting into this.
Since I had kept builds of r15878 from March 6, 2021, I finally had time to give it a try last night. My hope was that I could help narrow down a timeline for you. I was hoping that it would not trigger the wifi cutouts, and that would put the bad commit somewhere between March 6, 2021 and April 23, 2021 (RC1).
However, r15878 did trigger the issue of wifi cutouts within 10 minutes on my iPhone Xr that seems especially prone to triggering this issue. Each time, as usual, required toggling the wifi off/on. Therefore the bad commit is before March 6, 2021, not after. Unfortunately still a large time period for your bisecting.
As I understand it, you are testing each build for approx. 3-5 days for thoroughness. If you want to build some images ahead of time, while you are still in testing, I am willing and happy to do some testing of your other builds. Particularly, since my iPhone Xr seems to trigger the issue rather quickly. I can commit to testing of 3-4 hours each night per build and provide you with some feedback. And then depending on which ones trigger issues or not, it might help us to narrow down a bit and at that point do the more thorough 3-5 days testing on less builds.
Let me know what you think. I would like to help if possible. At least as much as I can help as a non-developer.
Thanks for the offer of help, @WildByDesign I will definitely accept it.
The 3-5 days is just for the initial build, or any builds that don't exhibit hanging issues. If we install a build and notice a hanging issue, then that's a "bad" build, and we'll continue the bisect. That might mean we can get through several bad builds in rapid succession.
So far my initial build is proving to be stable, so things are looking good. Once a few more days pass, I'll create a new build of the bisect and we can start testing there. It's still a little bit of a manual process to get the builds working properly.
I'll be sure to post the bisect build here for everyone to try.
Just so I know in advance, are there any special packages you need for your testing @WildByDesign? We can't really install packages on these custom builds after the fact, since we don't have a reliable source to pull from. So I just need to build in all specific packages into the image, or build them as modules so we can install them individually + manually.
You're welcome. I am feeling very optimistic about this approach.
The only package that is really crucial for me when testing various 21.02.x builds is luci-app-advanced-reboot. That way, once things go sideways I can always reboot back into David's last build on the other partition because I need stable wifi during the day for my family. Night time is when I get a chance to do more testing.
I'm sure you have seen this post before, but I found it just a few weeks ago... I had success using this setting with no disconnects on a WRT3200ACM. The script disables AMSDU. Stability for >2 weeks on the 21.02 release. Without this, I had the same issue everyone else describes, with iPhone X, iPad, etc. showing connected to WiFi but having no response for several minutes.
I'm not sure what this points to other than a possible incompatibility with iPhone and the firmware, or maybe a kernel issue with handling this AMSU setting.
I just tried RMilk's suggestion regarding AMSDU on a WRT3200ACM with 21.02.0. Unfortunaltely, Wifi still has dropouts. As described above, Wifi becomes stable on my WRT3200ACM, when I disable WMM (but this prevents some clients to connect at all).
Maybe there are several different issues, all leading to Wifi instability, and having different causes.
Yes master still has WiFi cutouts. For me anyways.
And Divested’s build has a patch that explicitly disables AMSDU using these same commands, and there’s still cutouts on my WRT3200ACM. This was on master and 21.02, I patched both.
@adworacz Thank you for confirming that Master and Divested are both still have cutouts as well. I generally don't use Master for daily use, with the exception of back when Davidc502 used to share his builds from master.
I just tested those AMSDU commands on my WRT3200ACM with 21.02.0 out of curiosity. I supposed I was hoping for anything that could be considered an improvement. The commands worked successfully, however, the wireless cutouts were exactly the same and exactly as often. Therefore zero benefit to disabling AMSDU specific to this issue.
I get approx. 3 wireless cutouts per 10 minutes on my iPhone Xr. That is pretty consistent during all of my testing thus far. Then I switch back to Davidc502's last build on my other partition and it's smooth sailing with no interruptions.
I'm wishing that OpenWrt cut a stable build in 2020 around the time of Davidc502's last build. 19.07.x series was pretty good with WRT3200ACM, yet sometimes a bit finicky. 21.02.x series is simply not usable with WRT3200ACM at all. Davidc502's last build was quite literally the sweet spot because it was more stable and much more reliable in comparison to 19.07.x.
However, we cannot go backwards. We can only go forward. Fingers crossed for a working 21.02.x release in the near future.
that was in master for a period of time before being backed out, which is not to be seen in your link. From a current master image on a rango can be seen the Max Payload Size, but I have actually reversed the commit in my build, so values will be different on a current default build.
I assume that is from 5.4 image, so what would be seen on 21.x. At any rate, it is not clear what may be happening on prior kernels regarding this setting.
I just started using 21.02.0 stable and stumbled into this thread when I couldn't figure out why my Android phone couldn't get internet on the 5Ghz band. Switching from WPA2/WPA3 mixed to WPA2 got me on the internet. Seems stable with WMM on.