Probably the similar change needs to be done in mwlwifi, too.
( Ps. That might also explain why wpa3 and optional management frames have been a no-go with wrt3200acm.)
Unfortunately mwlwifi has no API interface for cfg80211 in the current driver. My cursory analysis is that a complete driver rewrite would be necessary to properly upstream the driver.
Someone may be able to hack it but I don't have enough knowledge nor the documentation to even start.
The driver itself is a hack judging by the comments from the attempts at upstreaming the driver years ago.
Yeah, I think that they put lots of the functionality into the closed-source "firmware blob" and only exposed a smaller part of the functionality in the open driver.
All in all, the mwlwifi driver (and thus the mvebu routers regarding wifi) have been a dead duck since 2018, when the driver development was stopped. And in the whole time from early 2015 onward, there was pretty much just one coder doing driver fixes in the git repo. Somehow they first thgouht to launch this "popular" opensource series, but then they did not want to actually provide enough resources to keep it viable.
I'm beginning to remember why I stayed stock on this router now. Anyways, I remember some real old advice for OpenWRT on this router being to lock the channel to 36 or 40. On 36 I seem to have almost no issue. Didn't remember this until a reboot pushed my channel to 100. Then I started having connection problems with my phone. Locked at 36 now.
The DFS was fixed but the problems with wifi have persisted. I can't speak for all the 19 builds but as for the two 21 builds released so far, there are problems with the wifi when it comes to handheld devices.
This means that right now, our current testing indicates the offending commit was ed2015c38617ed6624471e77f27fbb0c58c8c660:
commit ed2015c38617ed6624471e77f27fbb0c58c8c660 (HEAD)
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sat Jun 20 23:11:17 2020 +0200
mac80211: Update to version 5.8-rc2-1
The following patches:
* 972-ath10k_fix-crash-due-to-wrong-handling-of-peer_bw_rxnss_override-parameter.patch
* 973-ath10k_fix-band_center_freq-handling-for-VHT160-in-recent-firmwares.patch
are replaced by this commit in the upstream kernel:
* 3db24065c2c8 ("ath10k: enable VHT160 and VHT80+80 modes")
The following patches were applied upstream:
* 001-rt2800-enable-MFP-support-unconditionally.patch
* 090-wireless-Use-linux-stddef.h-instead-of-stddef.h.patch
The rtw88 driver is now split into multiple kernel modules, just put it
all into one OpenWrt kernel package.
rtl8812au-ct was patched to compile against the mac80211 from kernel
5.8, but not runtime tested.
Add a patch which fixes ath10k on IPQ40XX, this patch was send upstream
and fixes a crash when loading ath10k on this SoC.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [ipq40xx/ map-ac2200]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In the name of good science, I'm going to flash my own WRT3200ACM with both 13923 and 13922 to confirm that the former is BAD and the latter is GOOD. I'll likely sit on 13922 for a week to realllly make sure it's rock solid.
But I have little trouble believing the 5.8 mac80211 upgrade was the issue. I'm not personally sure what to do next. I might try @slh's suggestion to see if we can get lucky to produce a pretty recent build with an older mac80211:
Another test would be checking 50f456b46cbae27ed13badfe7b2976cd01b67a57 with kernel 5.4 manually selected and mac80211 downgraded to the last known-good "with mac80211 5.7.5-1 update" - with a little luck that compiles (and works).
I'll see about making my flashes tonight, will keep the thread posted on that and how making a new build with @slh's suggestion goes.
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.
