It's been a few days now and the network, including the iPhone, has been stable. The ONE exception was some issues with the entire 5 ghz WiFi network going down roughly 24 hours after the firmware was flashed. However, a reboot of the router got everything working and the issue hasn't been repeated.
So if you are updating to the tip of 20.01 on these devices and force your network on to non-DFS channels things seem to be pretty stable. Maybe it's worth a pre-emptive reboot after you install your packages and configure everything.
I still don't have an answer to the DFS regression, though. I may start bisecting with the mac80211 patch.
This morning I had my 5GHz band crash for the fifth time since this fix has been applied. Luckily, I switched my wife over to the 2.4GHz band after the third time. It seems that the 5GHz band crashes approx. once every 2-4 days from what I have seen so far.
I think what I am going to do right now is install the old mac80211 5.7.5 (and related drivers) on the same OpenWrt 21.02.1 release and test it for a solid week or more and see if I can reproduce this issue there. I just want to see if I can rule that out or not first and then I'll see what steps to take after.
Just get the $100 U6-Lite-US and PoE injector combo and connect it to an ethernet port on your WRT router and let it be your access point, that's what I run. I only use wifi on the WRT32X for testing now, although it works fine for me, Thinkpad, iPhone, etc. no issues really on 5GHz (just not as fast/low latency as the Ubiquiti wifi 6 AP). It's not worth the headaches if you're having that many issues.
I have seen this as well, but to be honest saw it from time to time on 19 code too. for a while on 19, I wa scheduling nightly reboots because of it, but on 19.08 I believe it was it got better to the point where I just restarted the 5GHz radio when needed, which became rare. I assumed I had an issue with hardware, perhaps I assumed wrong.
I certainly agree and appreciate that, but there are limits to what WRT routers will achieve with wifi since the mwlwifi driver has been abandoned for years and wifi 5 is obsolete.
No doubt about the driver, but we have past evidence that shows @WildByDesign 's experience with the 5GHz band is not inherent to the driver, so it all depends on finding the bug.
Regarding WiFi 5, people will be using it for years to come. It's not obsolete.
Flashed a 21.02-SNAPSHOT build some days ago on my WRT1900ACS and configured an iPad to only use this AP. Not a single connection drop in 3 days whereas it used to stop working after an hour at most with 21.02.1
Other clients (laptops, phones, etc.) never had such extensive issues, so I didnāt really care about it and just used the secondary UBNT APs for this client.
Thought about replacing the WiFi module (2 mini PCIe cards, although the original one is one double-sized board) with two Atheros WiFi6 cards, but dropped the idea as suitable cards are not really cheap and thereās no guarantee - choosing a different router is certainly the mainstream solution.
Sadly, I'm also considering chucking away $500 worth of hardware but it's not clear what router would be safer nowadays. To make matters worse, I use WDS which means I need to buy 2 identical routers and pray that they don't have further compatibility problems.
On a WRT1200AC running Davidc502's last build, I added a script in the Scheduled Task (crontab) section to reboot the router at 4:30am each day. (I'm using the following method: https://openwrt.org/docs/guide-user/base-system/cron#references )
In my case, it's a router at a family member's house, so nothing mission critical would be happening at 4:30am. People who require literally zero downtime will have to find some other solution.
I don't remember any specific reason that I did it -- it was more just to cover all bases -- but I also haven't had any persistent complaints from them about 5GHz going down or anything like that.
This is a good idea and something that I may end up having to implement. Especially since the 5GHz band seems to crash between 2-4 days, although generally not less than 24 hours. So this is likely what I will have to do.
Other suggestions to buy a separate wireless access point are solid recommendations as well. But itās not something that I can afford right now. That would be a good choice for a lot of people, though.
I personally have too much stubborn determination to not give up on this yet. I was lucky enough to have $400 ($450+ after taxes) a few years ago to buy my WRT3200ACM, thinking of it as a good investment.
But this 5GHz band crashing may be out of reach. There is no logging of the crash. Iāve read previous bug reports suggesting that it could mean that the crash might be happening on the wifi chipset itself or within the non-open-source firmware blob.
The 2.4GHz band remains fantastic and reliable. So using only that may be an option. Or setting the router to reboot every 24 hours as another option but no guarantee that the 5GHz band wonāt crash under 24 hours.
If you wanted to bisect this, you'll need to create a debug build with extra logging to narrow which line number(s) the crash happens around. Perhaps log entering/exiting each function?
Yep, but I don't think this 5GHz band bug was always present, as many people saw stability with David's builds, so it might not actually be a bug in the firmware. I could be wrong. We'll have to have someone go back far enough to see, of course, which is time consuming.
Iām on day 3 now of uptime which seems to be the average amount of days for when my 5GHz band would crash.
Interestingly, my 5GHz network disappeared briefly and I thought for certain that it crashed as per usual. Plus I was actually expecting it to happen today.
The 5GHz band came back up this time on its own which surprised me and reconnected automatically.
The logs contained several lines with hostapd error:
STA-OPMODE-N_SS-CHANGED
These never showed up during normal circumstances for me over the past few days.
I am wondering if this is the situation that happens and usually causes the 5GHz band to crash (at least on WRT3200ACM). However, possibly, in this rare exception it went down briefly and came back up without the band crashing entirely (requiring reboot).
These are just my current thoughts at the moment, but the timing of it seems on par with when my 5GHz band crash usually occurs on average.
I donāt know exactly what hostapd error STA-OPMODE-N_SS-CHANGED means so I am still searching and doing some research about it.
EDIT: I am looking into hostapd.conf possibilities for disabling or restricting AP power saving capabilities.
Also, I recall Brainslayer over at mwlwifi GitHub issues mentioning many times in the past that mobile device power saving features cause lots of issues for mwlwifi driver.
@WildByDesign you are using the new patched version right? Do you recommend disabling 5GHz for people who need wifi to work reliably? Isn't there an alternative driver to mwlwifi?
No, there is no alternative driver - Marvell in their ultimate wisdom decided to write mwlwifi instead of adding the new chipset support to the existing in-kernel mwifiex driver. As a result, it's either mwlwifi or nothing.
