Can anyone here provide a basic rundown of what hardware this is supported on, how to enable it, and how it should behave if working correctly?
Since seeing it mentioned with respect to the OpenWrt One, I've been intensely curious about it but there's almost no discussion so far. I would have expected it to be an extremely popular feature, as it should theoretically open up the entire DFS channel range for day-to-day use.
Thank you in advance for any helpful information.
Please post output of
ubus call system board
from your OpenWrt system.
basic rundown:
option background_radar 1
You mean legally, correct?
Would be nice if we could use an old 4/16MB device acting as scanner and companion for another router only for that feature :- )
Apart from the obvious that you will neither fit the most slimmed down OpenWrt into 4 MB, nor finish booting with 16 MB RAM...
What are the chances that your hypothetical 4/16 device physically has the radio hardware for:
That totally ignores the 'small' problem of establishing a communication channel between two completely different devices - and the tiny problem that bcm47xx/ b43 and ath25/ ath5k, the kind of targets which had 4/16 devices are 17++ years old and rather stagnant, to phrase it positively.
Common sense has a very clear answer to this.
What exactly does that option do? I tracked down the effect it has on hostapd, where it does set enable_background_radar in its config, but even there, the description of the effect (https://marc.info/?l=hostap&m=165058240513281 et al.) of that option being set seems lacking. What benefit does it incur, and how exactly does it change DFS-related behavior of my 5GHz AP?
Answered in another thread:
(I realized you weren't the original poster. If you have an issue, it might help to create a thread for it.)
docs
-- https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n228
mt76 ax and ath10k wave2 (10.4 fw) supports it, does not hurt to try on others
Unlikely that does any dfs
Thank you; I did find that, but my trouble is that I do not understand it 
Iirc, having requested a DFS channel from the radio, there's a scanning period at the beginning of the uptime, where the radio decides if it's worth trying to configure itself for that particular channel selection. That means wifi will be available only AFTER that has been completed successfully. Does the "background scanning" change that, so that the radio becomes available instantly, and then reactively evades any radar interference by switching channels?
I've also had 5GHz APs turn off their wifi because of some radar interference detected after the initial scanning came up OK. Will that behavior be impacted by setting this flag?
It listens to other channels for dfs and disables them accordingly. Yes, 2 min wait at start anyway, but channels switch instantly after. You can set
option channels '36 52 100 116 132 149 165' (excluding non-dfs and weak ones, consult iw list for your place) and watch radio jumping around radars without delay.
Thank you for the information, everyone.
You mean legally, correct?
Yes, that's the idea.
mt76
I was looking to use this on a BPI-R3 but I'm guessing it's not supported. When you say "mt76", do you mean the MT7976x series of radios? The R3 uses MT7975P for 5 GHz.
I'll run the system call later today when I have time, unless someone confirms in the meantime that the R3 doesn't have support.
Meraki MR18 had a radio just for this
Just set it to jump only around dfs channels and knowingly set one where radar has ben seen, youll see in the ligs how dfs cac is resolved instantly.
@slh @hecatae Is it possible with an e.g. popular ath10k and the ct-driver to ignore/disable DSF scan on the host, plugin a cheap USB openwrt driven wifi stick to the host and use this one for dsf-scan and signaling to the host?
Or is the dsf-scan on the host chipset beyond reach of the driver?
Addendum:
Probably the solution for disabling DFS background scan on the host but which openwrt Wifi USB stick as companion? Linux supported chipset information.
Maybe smb adfs a wishlist item, unlikely to land in v24 old scripts anyway, probably worth testing till next release anyway.
Notably ath10k wave1 fakes background scan so that normal wifi operation stutters. Mt76 better.
so on my Meraki MR18, could I use that on the third radio and would it be able to inform the primary 5GHz radio?
ath9k is extensively documented in kernel wiki
Unlikely i mean
Hilarious!
I enabled this on my BPI-R3 but I don't think it's functional. When enabled on my OpenWrt One, I see periodic DFS-CAC entries in the log marked as "background", but not on the BPI-R3. Unfortunately (well, not really!) I don't appear to have any radar hitting the DFS channels locally so I have never observed a kick or a switch over several weeks of running 80 MHz wide channels in the DFS range.
One annoying issue with using DFS channels on either device is that the radio seems to require a manual restart after the first CAC check is complete. Otherwise it just stays down indefinitely (and LuCI displays a weird 6 GHz frequency instead of the correct one). On a couple of occasions I even had to restart the radio twice to get it to come up. When it does, it stays up and seems fine, but that initial start is frustrating.