Your comments are always short and concise, yet valuable like gold. I appreciate it.
Let's assume for a moment that this suggestion works well. Would it make sense at some point to create a patch for 21.02.x series to downgrade mvebu (or mwlwifi) to kernel 5.4?
mac80211 is a generic wifi subsystem for (almost) all drivers, not just mwlwifi. Downgrading it to the mac80211 5.7.5-1 state would thereby affect all other wireless chipsets as well (with a huge regression potential, apart from ath10k-ct and mt76 hard-depending on the v5.10 era mac80211); keep in mind that there are even mvebu devices with non-mwlwifi wireless (Turris Omnia, ath10k-ct). This wouldn't even be reasonably possible for 21.02, but for master it's out of the question.
Finding the reason what caused the regression in mwlwifi can only help in getting ideas what might be needed to fix in mwlwifi, mac80211 and the rest of the kernel are 'fine' (problems with out-of-tree drivers need to be fixed in these drivers, upstream linux doesn't care - either get it mainline, or keep working on your own).
I have just achieved some interesting success. I decided to try playing around with AMSDU again. This success seems to be legitimate on all bad (affected) builds, including 21.02.x series.
Basically, 5GHz band exhibits the wireless cutouts regardless of AMSDU enabled/disabled. The 2.4GHz band is successful, but only when AMSDU is disabled.
I am done testing for the day. I spent a few hours learning as much as I could about hostapd. Tomorrow, I plan on testing hostapd_options with with various options with regard to frame management and frame sizes. Plus, I plan on doing more testing with option vht_max_mpdu and it's several choices.
I have some ideas planned to test but I am too tired right now. I will see what I can do tomorrow.
The way that I understand it is that WRT3200ACM/WRT32X has a max MPDU of 11454, while WRT1900AC/ACS and WRT1200 have a max MPDU of 3895.
Also, I noticed through the mwlwifi commit history that there were a few times in which the max MPDU value was decreased due to issues, and increased at other times throughout development of the driver.
Maybe anecdotal as evidence but I am able to reliably cause my wifi to hang up on my Android s9 by walking past the router (within 5 feet of antenna) and within 3 minutes it will be hung up. The same symptoms as discussed here in that the wifi is connected but no data passes.
Excuse my ignorance, but is 5.10 snapshot affected by this issue? Is it only to wrt32 series, or armada-385 in general? and what is the best way to reproduce the issue?
Hello friends, I'm experiencing same wifi issues on multiple devices, mainly apple devices - iphone, 2 macbooks as they're my main devices.
I suspect it's related to WPA3/wpad-* package, because once I've upgraded openwrt to 21 (from 19), the issues started, also, 1 android phone wasn't able to even find wifi APs (with WPA2/WPA3 mixed mode enabled on router). I changed it to "pure" WPA2, but issues started on apple devices (wifi is connected, network does not work including connection to router). I tried to change multiple settings e.g. 802.11w/Disassociate On Low Acknowledgement etc.., but issues continued. The really annoying thing is that wifi is still connected, works on other devices, but network does not work on the impacted device.
I know that some users tried to remove wpad-basic-wolfssl (some of them were successful, some not), I did the same and installed wpad-basic (in order to use with WPA2 only).
Another weird fact is that when wpad-basic-wolfssl was installed, but wifi APs were set to WPA2 only, macbooks saw these wifi networks as WPA2/WPA3 capable. -> this changed once I replaced it with wpad-basic and therefore forced WPA2.
So far, so good. I'll inform you later and if such issues reappear, I'll try to install other wpad package - wpad/wpad-mini/wpad-basic-openssl/wpad-openssl and maybe wpad-wolfssl. Once I exhaust some options, I'm seriously thinking of downgrading to openwrt 19.x unless it's fixed.
Good to luck to each of you and thank you for valuable tips and big thanks to openwrt developers. My WRT1900ACS was such a useless device (with constantly dropping wifi connection) on their stock firmware
Agreed. Something about the drivers being incapable of running it from what I remember. I wish they would just make the drivers open source. Linksys makes a big deal of these routers being able to use open source software but keeps the drivers locked up. Makes perfect sense!
Out of curiosity, yesterday I decided to try switching radio0 (5GHz) from Wireless AC to Wireless N just to see if I could avoid the wireless cutouts. It was not 100% successful.
However, I was only able to reproduce the wireless cutouts once about every 20-30 minutes with Wireless N and that was consistent. Whereas with Wireless AC, I could reproduce the cutouts every 2-3 minutes.
I also tested using wpad-basic instead but that did not make any difference to prevent the wireless cutouts, unfortunately.
In my particular network, yes. There's something like 4 iPads and 5 or 6 iPhones. The laptops on the network have zero issues. And it's only a few of the iPhones that seem to trigger the issue consistently. I assume it depends on which wifi chipset is inside the iPhones because that can very quite a bit.
This feels like mainline Linux including subsystem mac80211 upstream has moved on compared to the firmware and driver here which has been abandoned and not updated since a year plus ago. Are we flogging a dead horse with these devices?
It's just weird that it's those and my Android but other devices seem fine. At least in my case. I keep looking for settings on my phone that would cause this. I think it may have to do with energy saving features but I can only speculate.
I hate to say it but I think you may be right. If the drivers were open source then it would be a different story. In any case, I'm shopping for a new router.