also station wds mode after one day was down. need check regular station.
The major bug discussed in this thread has already had a fix included in recent masters and the 21.02 daily snapshots (hidden directory, not the official release), so you'll just need to test those first if you can't wait for the next official point release, and then get back with people here if you still have problems.
See my previous post for what to do. No, I haven't personally tested the builds with the fix included yet.
Tested the 21.02 snapshot from December 5th and wifi is working a lot better than in Openwrt 19. I used to start and stop the 5GHz wifi several times before it became active. With version 21.02 it will start correctly everytime. Wifi keeps accessable with several Apple devices (iPhone Xs, 6s, iPad Pro 2017, iPad Air 2020).
The only problem is I ended up with a read-only file system. It never happened with stable builds.
This is probably the answer, but hopefully someone with more experience with testing snapshot builds can confirm. At least we know it'll be good on next official release: Updating base-files remounts root as readonly and update fails - #7 by hnyman
Bad news. I've tested out the nightly builds for 21.02 (commit 2e5b2ab) and it still has an issue where the iPhone is unable to connect to the network.
For this latest test, I updated OpenWRT on the router in the AM, and the iPhone was physically out of the building for about 4 hours. Everything was working fine. The logs don't show anything interesting, except for a
radar detected by firmware in the first half hour or so of it being up, and a
DFS-NOP-FINISHED thirty minutes later. In response to the DFS channel switch three devices had to reconnect to the network but I think this is typical?
When the iPhone came into the building it was unable to connect to the wifi at all. Thinking that maybe it was some issue with DFS and switching I forced the wifi to channel 149 to avoid DFS. This let the iPhone re-join the network right away. I will keep an eye on it for the next day or so to see how well channel 149 does.
Yes, this is expected behavior, as mandated by regulations.
Perhaps your router changed to a channel forbidden in your region?
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.
Or, we figure out the cause, fix it, and everyone benefits.
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.
I was 3.5 days into testing mac80211 5.7.5 regarding the 5GHz band crashing when it did, indeed, crash.
So this particular problem with the 5GHz band crashing (requiring a reboot of the router to resolve) does not seem to be related to mac80211.
This seems far more complicated.
well, i do not use standard brands, i use 2 x turis omnia + AX cards update. Its a bit more expensive, but there are not much compromises.
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.