soul4kills
New Around Here
Sharing this script that helps to maintain and recover the 160mhz connection for wifi 6 routers . There are other scripts in this forum that do something similar, but it disconnects the clients. This script does not disconnect the clients as it uses the built in broadcom command to trigger a pre-ism CAC check. It took a while to find that command. Before this, i was using the csa command to migrate the width of the channel.
It's set to run every 30 minutes, that's how long a DFS block lasts, with an offset of 1 minute to account for the routers own cac check and not interrupt it. It checks if you're already on 160hz, if so early exit. If not, it will trigger the CAC check for your current control channel, if clear, gets upgraded to 160mhz channel. If it fails, it will fallback to the other 160mhz block and do another cac check. Doesn't matter if it fails at this point as only 2 blocks are available for 160mhz in the US. 36/160 & 100/160. Then after 30 minutes, it will try again from the cron job.
It avoids the upper channels that are not 160mhz capable. The reason why is, when you are kicked off of the DFS channels, and you end up in the 149-165 block. The routers auto mode stops trying to connect to 160mhz because it's not capable in this range of channels. So you're just stuck there until you manually restart your radio. For the most part, my script allows the router to do it's own thing to get you back to 160mhz channel, that's the reason for the offset. It's weird that asus hasn't considered this. What's the point of auto if it gets stuck and doesn't wrap around again. It would be such a simple fix.
That's pretty much what it does. AI definitely helped me with this. I'm capable of doing on my own but, it would've taken me longer than a day to figure out. It's expected to run in the scripts folder. It has 3 levels of logging, none, events, verbose saved in the scripts folder. It will automatically add/remove a cron job and create/add/remove init-start depending on the flags you set for the script. You can set a preferred channel depending on which block is more congested in your area. 100/160 for me is clear as most routers default to channel 36.
So far, it seems to work without disconnecting the clients from my own testing when it comes to upgrading to 160mhz, but when moving channels it still seemed like it didn't disconnect, even though i though it might. Maybe it happens so quick that it's not noticeable.
It's set to run every 30 minutes, that's how long a DFS block lasts, with an offset of 1 minute to account for the routers own cac check and not interrupt it. It checks if you're already on 160hz, if so early exit. If not, it will trigger the CAC check for your current control channel, if clear, gets upgraded to 160mhz channel. If it fails, it will fallback to the other 160mhz block and do another cac check. Doesn't matter if it fails at this point as only 2 blocks are available for 160mhz in the US. 36/160 & 100/160. Then after 30 minutes, it will try again from the cron job.
It avoids the upper channels that are not 160mhz capable. The reason why is, when you are kicked off of the DFS channels, and you end up in the 149-165 block. The routers auto mode stops trying to connect to 160mhz because it's not capable in this range of channels. So you're just stuck there until you manually restart your radio. For the most part, my script allows the router to do it's own thing to get you back to 160mhz channel, that's the reason for the offset. It's weird that asus hasn't considered this. What's the point of auto if it gets stuck and doesn't wrap around again. It would be such a simple fix.
That's pretty much what it does. AI definitely helped me with this. I'm capable of doing on my own but, it would've taken me longer than a day to figure out. It's expected to run in the scripts folder. It has 3 levels of logging, none, events, verbose saved in the scripts folder. It will automatically add/remove a cron job and create/add/remove init-start depending on the flags you set for the script. You can set a preferred channel depending on which block is more congested in your area. 100/160 for me is clear as most routers default to channel 36.
So far, it seems to work without disconnecting the clients from my own testing when it comes to upgrading to 160mhz, but when moving channels it still seemed like it didn't disconnect, even though i though it might. Maybe it happens so quick that it's not noticeable.
