I wanted to share a project I’ve been working on that builds on the fantastic work by u/try_harder_later and u/daphreak from this Reddit post. Their script for handling DFS radar events was a lifesaver, and I’ve made some improvements to make it more robust and user-friendly.
Automatic 5G Radio and Interface Detection: The script now automatically identifies the 5G radio and its interfaces, so you don’t need to manually configure device numbers or interface names.
Simplified CLI: Just provide the primary channel, fallback channel, and optional backoff strategy (linear or exp), and the script handles the rest.
Configurable Backoff Strategy: Added support for both linear and exponential backoff strategies for retries after connectivity failures.
Improved Error Handling and Logging: Better error handling and detailed logging make it easier to debug and monitor the script’s behavior.
Service Setup Guide: Included a step-by-step guide to set up the script as a service, ensuring it runs automatically at startup.
I’ve also updated the README with detailed instructions, script descriptions, and explanations of the new features.
This project wouldn’t have been possible without the initial work by u/try_harder_later and u/daphreak, and I’m grateful for their contributions. I also used DeepSeek-V3 and DeepSeek-R1-Lite to help refine and optimize the script, which was a great experience.
If you’re dealing with DFS radar issues on your OpenWrt router, feel free to give this script a try! Feedback and contributions are always welcome.
First "fail over" can be easily handled by uci option "channels", i.e set primary channel while prmit unlimited secondaries, it will not return, so other half of script is an improvement.
As some feedback, the get_5g_radio could be made a little simpler by using uci calls (foreach etc).
Also lines 123-129, is there a risk this could false positive on the 6ghz range? If it’s only called on radios that were already confirmed as band = 5g then it doesn’t matter, but I suppose then why are we checking again?
I hadn’t initially considered the 6GHz range, but after checking the Wiki, you’re absolutely correct.
Simply checking the channel number could lead to false positives in the 6GHz range. It’s better to look at the frequency right after the channel number—for example, the 5.540 GHz in Channel: 108 (5.540 GHz).
I’ll create an issue on the GitHub repo and fix this in the near future when I’m less busy.
Regarding the question about why the channel is checked again: this script uses get_5g_radio and switch_channel to perform the actual channel switch on the 5G radio. In get_5g_radio, I rely on the information available from /etc/config/wireless, which doesn’t include details like phy#1-ap0.
The regular signal monitoring is done by iterating over the available 5G interfaces found via iwinfo, which is a separate set of information with no overlap to /etc/config/wireless except for the SSID. To simplify the process, I chose to look at the channel info instead of matching the 5G SSID.
This script was born out of curiosity and a passion for tweaking, rather than deep knowledge of the OpenWrt software stack. Much of the work was done with my limited understanding and some help from LLMs, so there’s definitely room for improvement.
