I am running 21.02.1 currently. To be honest, I don’t think we need to do bisecting yet because I need to gather more details. I am actually thinking now that this is a previously known mwlwifi issue where the 5GHz band just craps out and stops working for any devices on that band. The 2.4GHz band continues fine.
So I don’t think this is an issue specific to your patch.
I tried the wifi command this time hoping that it would recover the 5GHz band but it did not. The only way to recover the 5GHz band was a full reboot of the router.
For now, I think I will just keep my wife on the 2.4GHz band because she has been getting frustrated with it.
@WildByDesign , the following could be yet another issue, but even going back to David's last build (I haven't tested anything newer yet), I've experienced a weird issue on a WRT1200AC where if I applied certain settings on the 2.4GHz radio, the 5GHz radio would die and I'd have to reboot the router to get it working again. This could just be a separate bug, but what you wrote reminded me of it. When I have a chance to test these latest builds, I'll follow up on this.
Awesome, that worked great! Wasn't sure that was the case to even activate the interface; I use radio2 for IoT devices; still need to enable legacy 802.11b to be able to activate but other than that it looks good!
looks like mwlwifi compiled from master today is not able to work as sta+ap on 5ghz radio.
edit: sorry my mistake, need edit the mac address of ap interface
so, I noticed one other issue with ARP on devices which are connected to the same WLAN after some time (~1day working).
But meanwhile ARP is working between devices connected to different interfaces(WLAN, Ethernet)
The picture is next:
Devices connected to WLAN(5GHz) DO NOT respond to ARP requests from devices on the same WLAN(5GHz)
Devices connected via ethernet respond to any ARP requests from WLAN(5GHz) or WLAN(2.4GHz) and vice versa!
Devices connected to WLAN(2.4GHz) respond to ARP requests from devices connected to WLAN(5GHz)
@mmortal03 could it be related to the used master snapshot instead of 21.02?
@stamak , I plan on testing both snapshots, but haven't had the chance yet (my WRT1200AC is at another house in the family, so there hasn't been a good opportunity to test it yet). Are you asking about your ARP issue? I can't say -- all I can suggest is that you try that 21.02 snapshot and see if you get the same result as with the master! Let me PM you.
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.
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.
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.
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.
