The assessment of "mesh being incompatible with DFS" is of course wrong, because the supposed behavior is that if one mesh point has a DFS event, the other mesh points are supposed to scan follow its frequency change, so the mesh doesn't break down. This is how it it's implemented in commercial wireless solutions based on Linux.
This behavior is obviously not implemented in OpenWrt, making it pretty much nonviable for 5 GHz single radio mesh networking. But it doesn't have to stay this way, or does it?
The mesh11sd package supports channel tracking (but the current version has issues with some wireless driver / DSA implementations, fixed in the upcoming v4.0.0 release).
This channel tracking is not specifically intended as a fix for DFS issues, but should work as long as the radio actually does come back up on a different channel after a radar detection. Unfortunately this is not always the case.
Be aware though, in every country as far as I am aware, DFS channels are restricted to indoor use and limited power. So using the normal "unlicenced" spectrum is never going to be much use even for normal AP use, let alone 802.11s mesh.
Well, sort of wrong but also sort of right. Basically the chunk of spectrum allocated for 5GHz wifi is not ideal as it is mostly shared with other things.
Commercial systems usually involve the use of licenced spectrum, where the operator is required to apply-for/pay-for an operating licence.
OpenWrt does not support the use of licenced spectrum, although it can with non-open-source drivers.
Well, as I said, the mesh11sd package supports channel tracking.
But for DFS / spectrum sharing reasons, I doubt if 160MHz channels will be viable, at least on 5GHz.
It will be a different story though once 6GHz becomes more readily available.
You can see useful charts of channel availability here:
mesh11sd 3.0 was bricking my devices. They don't boot up at all with it installed.
Hardware issues are not the topic here. If a device loses 5 GHz completely on every DFS event, then it's just broken and needs to go into the trashbin.
That's how all commercially available Wi-Fi mesh access points operate. They share spectrum with everything else.
Commercial Wi-Fi 5/6 solutions with commercial closed source operating systems are not using specifically licensed spectrum, they are also just operating on publicly licensed spectrum as well. They are available on retail.
The question is if OpenWrt is able to replicate that functionality.
160 MHz is not the issue of this thread, DFS mesh doesn't properly with 80 MHz channels either with OpenWrt. And the other frequencies are very low power and licensed only for indoor use.
It won't, because most of the 6 GHz spectrum is only licensed in the US, and that is not where I live. Wi-Fi 6E is not the solution, so there is no point in buying more unsupported hardware.
For the ETSI region the DFS spectrum the only (!) spectrum licensed for outdoor use (everything else indoor only) and only spectrum licensed with maximum power (everything else is low power only).
That, unfortunately, is how DFS is supposed to work if events keep happening with 160MHz bandwidth.
Yes indeed, they must share with everything else and immediately turn of on DFS events and passively scan and wait for the priority (eg radar) events have ceased.
Yes it does, as I already stated.
Indeed, that is the problem with 5GHz, any mode in fact, not just mesh.
Who told you that? Did you even look at the link I posted?
On 6GHz in the ETSI region (Europe for anyone wondering), you can use 160MHz bandwidth on channels 15, 47 and 79
Not really true, is it? I think you need to do a bit of reading before having a rant.
DFS stands Dynamic Frequency Selection. APs are not supposed to turn off the 5 GHz radio completely, they are supposed to switch frequencies with every client and mesh point following the switch.
And this is exactly what every properly implemented closed-source firmware is doing.
Newer radios then can scan in the background to return to the original/better frequency after the cool down period. Older APs have to disable 5 GHz for 60 seconds (usually during low traffic conditions) to scan the DFS range again. These usually band-steer their clients to 2.4 GHz while doing that.
OpenWrt doesn't do any of this, it's just stucks with low throughput on channel 36 forever when one single DFS event occurs.
Capacity-wise that's pretty much as worse as 2.4 GHz, once this band is populated. There is only one (!) 320 MHz channel available. Not worth even bothering purchasing, that isn't allowed to send on the up to 7,1 GHz it supports.
They are supposed to cease transmitting immediately then listen for a timeout period. Then after that interval if no "radar" is detected, it will switch back on. If the event continues on that channel, it will switch to the next channel and repeat the listening for the timeout interval. If not clear for that channel it will try the next etc, rotating around the available channels for the bandwidth selected.
Depending on the nature of the event, transmitting can be inhibited for a long time.
It does do all of this. Channel 36 is the fallback DFS-free channel so yes you will often end up there if events are common.
Events are not just radar, they are anything not recognised as a "wifi" signal.
So 160MHz is essential for you on 5GHz, but worse than 2.4GHz if you are on 6GHz?
Well there we have it. You will never be satisfied no matter what becomes available....
This is not what OpenWrt does. It just switches to channel 36 and stays there. It won't ever run another scan.
Even spurious Wi-Fi noise by other stations.
6 GHz is low power indoor-only, not viable for mesh networks. And only the FCC is licensing 1,2 GHz of spectrum to Wi-Fi, making it worth purchasing 6 GHz hardware right now.
The whole situation probably won't improve before Wi-Fi 7 which is putting away with "channels" altogether.
Under ETSI regulations the DFS frequencies are the ONLY ones licensed for outdoor use. So while near an airport outdoors, a device is REQUIRED to use those frequencies and jump away as need. FCC regulations do not apply, those are a continent away.
Most client devices made for international markets just violate regulations, for example by putting an hotspot AP on channel 36, which is simply not legal outside the US while being outdoors.
OpenWrt is also not up to the task, using a regdb intended for Wi-Fi clients, unable to run a mesh network on the only 5 GHz frequencies licensed for running an outdoor AP.
OpenWrt is doing just fine without any wireless interfaces enabled. WRT1200AC is a powerhouse with it (just never dare to enable the Marvell Wi-Fi).
There are lots wireless routers with OEM firmware based on OpenWrt, they don't seem to use hostapd though, which is seemingly missing all the essential features to run a regulation-conformant 5 GHz 802.11 radio.
So the interim solution might be extracting the binaries from the OEM firmware and run them on vanilla OpenWrt.