[Script] 160mhz channel recovery for wifi 6 only routers

[lgkahn]

unfortunately even with the script which does get back to 160 withi9ng about a half hour.. the brothers trend and tp link ethernet bridges both drop out when it changes from 160 to 80..

 

[kidd232]

Do you realize you're not clever yourself because it doesn't do anything you are implying it does.

I'm well aware of why DFS exists and that regulations differ by region. The necessity of DFS isn't the point of contention.

The problem is the 'one-way' behavior in the ASUS implementation. After a DFS hit, the router frequently fails to switch back to 160MHz, leaving the status stuck at 'IDLE' forever. A robust firmware should be able to re-evaluate the environment and restore the configured bandwidth once the interference is gone, rather than requiring a manual reboot or toggle.

 

[soul4kills]

I'm well aware of why DFS exists and that regulations differ by region. The necessity of DFS isn't the point of contention.

The problem is the 'one-way' behavior in the ASUS implementation. After a DFS hit, the router frequently fails to switch back to 160MHz, leaving the status stuck at 'IDLE' forever. A robust firmware should be able to re-evaluate the environment and restore the configured bandwidth once the interference is gone, rather than requiring a manual reboot or toggle.

I don't think the "auto" setting works like how everyone else thinks it works. I believe auto just means, when it starts up or reboots, it will auto find the best channel. That's it. There is no more auto after that. So lets say it starts at 36/160, gets kicked off because of dfs. Then it will go to the next best, maybe 100/160. because dfs doesn't always block the whole dfs channels. Then it gets kicked off 100/160, so it uses 149-165. Then it just stays there just like how everyone in the forums describes it's behavior.

My script checks current channels, if it doesn't fit the conditions set, then it will nudge it back to where you want it. Which is a 160mhz capable channel. It always checks if it's clear before making the move, because that is how the dfs_ap_move command works. I don't know why you quoted that to reply to. It wasn't directed at you.

unfortunately even with the script which does get back to 160 withi9ng about a half hour.. the brothers trend and tp link ethernet bridges both drop out when it changes from 160 to 80..

I understood none of this. Please try again.

 

[Mikiya]

As long as you included proper credit, and it looks like you have, I have no issues with it. And how is it working for you? Is it doing it's job of maintaining the 160mhz band without disconnects?


I don't think there's any tuning needed, unless you see something I don't. Any type of adjustments needed are already at the top of the script. But how it is right now is perfect for how I intended it to work. There's also a simpler version for people with triband routers with no fallback.

Hopefully this finally provides relief for the people with 160mhz problems. I know it's one of the major pain points with these routers as there's a lot of threads on this problem.

And my "fork" version stick to a specific 160mhz channel if possible (100/160 for me because bandwidth is much better than 36/160). When DFS occurred, it periodically tries to return to a specific 160Mhz channel (defined at the beginning).

 

[soul4kills]

And my "fork" version stick to a specific 160mhz channel if possible (100/160 for me because bandwidth is much better than 36/160). When DFS occurred, it periodically tries to return to a specific 160Mhz channel (defined at the beginning).

That's what the simple "sticky_160" was made for. But it's fine that you modified the original for yourself. Just wanted to point that out if it suits you better.


On another note, some guy that didn't understand my code came in here insulting me and making accusations about my script bypassing regulations and what not. So I want to address that. So there are some missing replies that were deleted by the mods.

It does not bypass anything. It simply calls a command when certain conditions are met. That simple. It uses broadcoms own chip command. The command in question is a "wl" command, "dfs_ap_move". This is used by the firmware itself, periodically for it's own purposes. The command, by design, has the necessary protocols in place to follow regional restrictions. It will follow those protocols regardless if this command is called by the router itself or manually by a user or script. There is documentation online on it's functionality. Thank you have a nice day.

 

[sfx2000]

Do you realize you're not clever yourself because it doesn't do anything you are implying it does.

Doesn't remove the fact that forcing 160 takes the device out of regulatory compliance...

 

[soul4kills]

Doesn't remove the fact that forcing 160 takes the device out of regulatory compliance...

I know for a fact it doesn't because I tested it out myself during a DFS block and it doesn't make the move under that condition. So nothing is forced in how you think it works. I included verbose logging specifically to log it's behavior.

Until you can provide proof of the behavior your are implying, please stay out of this thread since you have nothing meaningful to offer.

 

[sfx2000]

Until you can provide proof of the behavior your are implying, please stay out of this thread since you have nothing meaningful to offer.

Look on the label for FCCID and/or EU-RED numbers - that means they were tested and certified...

Perhaps you're smarter than the regulatory testers and software dev engineers at both Asus and Broadcom.

If that's the case, you're in the wrong job...

 

[Tech9]

@sfx2000, the script is using built-in CAC check and doesn't force anything illegal.

 

[sfx2000]

@sfx2000, the script is using built-in CAC check and doesn't force anything illegal.

If he runs it once, that's fine, but go back up in the thread...

 

[Tech9]

I know the behavior on ASUS routers. Most basically stay on 80MHz forever and you have to reboot to trigger the built-in Auto with 160MHz enabled mechanism again. The script saves the reboot. ASUS routers are "reboot and reset" user experience. Whatever wrong happens you do one of the two.

 

[sfx2000]

I know the behavior on ASUS routers. Most basically stay on 80MHz forever and you have to reboot to trigger the built-in Auto with 160MHz enabled mechanism again. The script saves the reboot. ASUS routers are "reboot and reset" user experience. Whatever wrong happens you do one of the two or both.

Again - if one is getting a DFS hit...

 

[Tech9]

Again - if one is getting a DFS hit...

I understand what are you saying, but UniFi APs for example will check again over time and switch back to 160MHz. Most ASUS routers will just stay on 80MHz until reboot. Must be something Broadcom drivers related, I don't know. Stuck at 149-161 is also there for unknown reasons making Auto useless. It's just device specifics and @soul4kills is making an attempt to fix it. You perhaps haven't seen the issue and wonder why it's needed.

 

[soul4kills]

Again - if one is getting a DFS hit...

I hope you understand what you're implying. The fact that I can use this command means that all asus routers are all operating illegally.

This command runs on reboot, or wireless restart, or when a new client connects that is 160mhz capable. Anytime this happens consecutively, they are operating illegally according to what you believe.

You are also implying the devs are not competent enough to foresee someone using this command manually and didn't put safe guards in place to prevent it from being used illegally.

One of the metrics to meet regulatory compliance includes preventative measures. Since nothing is preventing me of using this command "illegally" in your eyes. It doesn't follow regulations.

 

[soul4kills]

Update:

- Fixed cron/ini-start add/removal as it was matching for a partial which may have led to unintended removals. Matching is more explicit now.
- Fixed logging when set to 0, it was still logging
- Reduced the logging so logs aren't so polluted
- Added ability to disable fallback (Not really needed as there's 2 version in this thread but added it anyways)
- When fallback is disabled, it becomes sticky. Sticky meaning it will make attempts to stay in the preferred channel set

_sticky_160 version
- Cleaned up simpler sticky_160 version with same fixes and also added simple logging to it
- Added an easy way to offset cron/ini-start additions/removals for convenience for triband users to try

Disclaimer:
If you genuinely believe this script is doing something illegal, that is a claim about Broadcom/ASUS’s own implementation and regulatory compliance, not about this script specifically, because it only calls their existing wl command and uses the built‑in DFS/CAC behavior. Please take that up with ASUS or the forum moderators. In the meantime, please stop derailing this thread with unsupported accusations so people who are actually interested in testing and improving the script can follow along

 

[ppfoong]

Thanks for the script.

I have made the following changes for Asus RT-AX86U:

IFACE="eth7" # eth6 is 2.4 GHz channel in my router.
LOG_FILE="/tmp/${SCRIPT_NAME}.log" # this is the more common place to put log files

 

[lgkahn]

I know for a fact it doesn't because I tested it out myself during a DFS block and it doesn't make the move under that condition. So nothing is forced in how you think it works. I included verbose logging specifically to log it's behavior.

you are wrong it doesnt make the move immediately even if you call the command.. it waits the requisite time before making the move... it just starts the process and says dfs is now in state 1 then 2 when the move actually occurs.