OpenWRT radio check (solves 5 GHz DFS bug in hostapd)

Recently there have been issues with DFS around me. Personally I think it is being misused to free up space in 5 GHz range - someone shoots radar signals and it kills my wi-fi 5 GHz radios until restart. It happens once a week and then I find out about it few days later after people yell at me it's working too slow (only on 2.4 GHz range).

To deal with this I've come up with this script:

I am going to need this fix until hostapd gets fixed and try the same DFS channels again after reasonable time.


Interesting hypothesis, 'I think it is being misused to free up space in 5 GHz range '. I always wondered if the DFS functionality could/would be used as a denial of service method.

To be clear, the wait time after a radar hit is 10 minutes, as defined by many of the regulatory bodies (especially in the US/North America and the EU).

If your approach is to restart the radio such that it shortens the wait time to the 1-minute 'listen' time when the interface is enabled, that is likely a violation of the regulations. If, on the other hand, there is a bug that causes the radio to be disabled for longer than 10 minutes (without another hit) or indefinitely, a script like yours would be a logical fix.,wait%20time%20is%2010%20minutes.

It is executed by cron every 15 minutes, so this rule might be upheld, but might not. In each case, there is that one minute DFS scan wait time before interface goes up.
The problem was the radio was off - not trying any DFS checks indefinitely. I've seen it happen mostly on Unifi devices, so the DFS signals might even be a hardware bug.