Since release 19.07 I had one 5GHz router that once in a while has 5G band radio locked out. Restating adapter or network services has no effect, resolved only by cold reboot. This is consistent through all software releases. I though about possibility of hardware defect and limped disregarding this being serious problem.
Jumping years forward: Many different routers tried and always the same problem with 5GHz: once every few week I loose 5G and need cold reboot.
Reading about similar problems I have changed authentification from Mixed WPA2/WPA3 to plain WPA2. That appeared to reduce frequency of lockouts by :3 to :4, but never eliminated them.
Now I have my primary router:
Linksys EA7300 v2/MediaTek MT7621 ver:1 eco:3/OpenWrt 23.05.5 r24106-10cc5fcd00 / LuCI openwrt-23.05 branch git-24.264.56413-c7a3562
and the second:
Linksys WHW01/ipq40xx/generic/OpenWrt 23.05.5 r24106-10cc5fcd00 / LuCI openwrt-23.05 branch git-24.264.56413-c7a3562
802.11r setup on both and working pretty well, when 5GHz working. Because problem existed before I got fast roaming and frequency of lockouts did not change - I do not think it is related.
Recently I had event when both routers lost 5GHz the same moment! Once again: restarting adapter or whole network service has no effect, 5G staying down and refused to wake up. Same time not a single glitch with 2.4GHz or the rest of services running on either router.
The fact that two very different hardware routers lost 5GHz the very same moment I found strange and pointing not at hardware but at common part of the code.
Anybody else having problems with only 5GHz radios? Any idea what it can be? Is there a solution?
You may be using a DFS channel... let's take a look at your complete config to understand the wireless setup as well as the rest to ensure there aren't any other issues.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
Yup.... you're on a DFS channel. And with 160MHz channel width, you can't avoid DFS unless you go to channel 149. However, 160MHz channels may also be problematic in general since they are more susceptible to noise/interference. I'd recommend using 80MHz instead.
Try channel 36 w/ 80MHz width.
Also, you should not be using the cell density and distance parameters unless you actually need to and understand exactly what they do. This is not necessary in the vast majority of enviroments.
Further, it is best to select channel 1, 6, or 11. Channel 9 is intended as a guard band.
Moving on, you have 802.11r which can cause more problems than it solves, so I'd recommend that you get rid of that, as well as the reasociation deadline and the 802.11w line, too since it is only really relevant for WPA3.
VHT160 (or even worse, VHT80+80) on 5 GHz is veeery suspective to DFS events and ordinary interference being misinterpreted as potential DFS events, hardcoding the channel is not very helpful in this context either. On top of this mt7615 is one of the first mt76 chipsets that support DFS in the first place, I would not expect it to be as refined in this chipset generation than it is for >=mt7915 (your other ipq40xx device might have a slight edge over the EA7300 here), but again - for 5 GHz (and <filogic 8x0) 80 MHz channel bandwidth is the most you can realistically expect in practice.
Why DFS can be the problem?
OK, I will disable 160, will stay with 80. Second router is only 80 anyway,
My second router is on 80MHz channel and went out the same moment.
Fast roaming for me is essential, otherwise walking around the house I loose connection for a few seconds. It appeared that fast roaming works as it should.
Any other advises?
OK I will try some changes and will report. Probably in a month. That is how long it takes for me to catch lockup.
By regulation, the radio must shut down if it gets a "radar hit" -- DFS is shared spectrum with government radar (weather, military, etc.), so consumer equipment must immediately shut off all transmissions if there might be a conflict.
The 80MHz DFS-free channel is actually channel 42 so for best results actually specify channel 42. If you leave it at 56 you will actually end up on 58, slap bang in the middle of DFS range. (see the wikipedia page linked by @psherman)
To add on this, the regulations require that no AP must ever miss or ignore radar events on DFS channels - it doesn't stipulate anything about false positive (just that there mustn't ever be false negatives).
A legally 'valid' DFS implementation would be not to check anything, but to cry wolf (reporting DFS events) all the time. Obviously this is not a useful implementation, but the requirements mandate to err on the side of caution and recognizing radar events is not trivial (so any interference (the wider your channel bandwidth, the more interference you get - and the harder it becomes for your AP to distinguish between noise and potential radars) can easily misinterpreted as DFS event). Fine tuning this system is an ongoing process, which favours the newer chipset generations (because they are better designed for this, have updated silicon/ algorithms) and because wifi7 relies on it work more than wifi6, which relied on it more than wifi5 - which in turn relied on it more than wifi4 (which only started to dabble into this topic).
I just educated myself on DFS. Fascinating. I can confirm that both of my routers being set on channels that overlaps with DFS range. I select them as least-occupied, per OpenWRT "Channel Analysis" tool. Now I know there is more criteria than just free spectrum.
I guess it is a good possibility that my area got hit with that radar frequency and that tripped both of my routers into DFS protection mode. I think it would be nice to know if my 5G router is in DFS lockout mode.
That bring the idea to improve LuCI by adding to first/status page DFS status display of 5GHz. Maybe even provide warning during channel selection on Wireless Network Properties setup page that some specific selection maybe forced into lockout by the environment. I am sure that most people are unaware of this.
I've changed channels to out of DFS range. Will see if I ever get lockout again.
