Channel and Width not following settings

[Jordan123]

Log a new issue on github: https://github.com/gnuton/asuswrt-merlin.ng/issues

Seems like somebody had an issue like mine "AX82U v2 Control Channel Issue #509" at the backend of last year on a different router but nothing else after this which may be pointing to a me issue; so I'll follow through with the guidance posted above before I put anything on GitHub.

Thanks again everyone

 

[Tech9]

then I've updated to the newer version

You upgraded from stable release to alpha intended for testing purposes only. Have patience and give GNUton time to look at it.

 

[samirchagan]

I have a similar problem, not sure if not following the actual settings is an expected behavior for an AX6000 on latest release.
5G network is forced to 160MHz and channel 128, but randomly it changes to a different width and channel without actually changing the settings or rebooting. And it explicitly shows on the wireless log tab "Channel cleared for radar: 128/160"

 

[ColinTaylor]

I have a similar problem, not sure if not following the actual settings is an expected behavior for an AX6000 on latest release.
5G network is forced to 160MHz and channel 128, but randomly it changes to a different width and channel without actually changing the settings or rebooting. And it explicitly shows on the wireless log tab "Channel cleared for radar: 128/160"

This is not the same as the problem described above. What you're observing is normal behaviour. If the router detects radar interference on the channels it's using it will switch to another channel. It usually picks a non-DFS channel between 36 and 48 with a bandwidth of 80 MHz. Even after the original DFS channels have become clear of radar the router doesn't switch back to those channels.

You'll probably get better results if you change the channel bandwidth to 20/40/80/160. That way the router will operate at 80 MHz bandwidth (thereby reducing the chance of interference) and only switch to 160 MHz for the times a client with that capability is connected to it.

 

[samirchagan]

This is not the same as the problem described above. What you're observing is normal behaviour. If the router detects radar interference on the channels it's using it will switch to another channel. It usually picks a non-DFS channel between 36 and 48 with a bandwidth of 80MHz. Even after the original DFS channels have become clear of radar the router doesn't switch back to those channels.

Thanks for clarification.

So the only way to switch back to the original channels is to reboot?

 

[ColinTaylor]

So the only way to switch back to the original channels is to reboot?

You could make some change to the Wi-Fi settings and apply it. That would force a restart of the Wi-Fi subsystem. Or you could do that manually from the command line:

service restart_wireless

Or you could automate the process with a custom script like the one I posted here: https://www.snbforums.com/threads/rt-ax86u-doesnt-switch-back-to-dfs-channel.77728/post-784233

Bear in mind that this will mean that all Wi-Fi devices on both bands will be momentarily disconnected.

 

[dev_null]

Thanks for clarification.

So the only way to switch back to the original channels is to reboot?

I use @ColinTaylor 's script posted here: https://www.snbforums.com/threads/rt-ax86u-doesnt-switch-back-to-dfs-channel.77728/post-784233

I tweaked it to email me when the channel changes, and because it seems that all of my false channel changes occur around 10 minutes after the hour, I created a cron job to run it at 20 minutes after the hour.

Create the script from the link above, make it executable (chmod +x channel-ck.sh) and add a cron job to your services-start script. I use two cron jobs because I don't want wifi to restart during work hours on weekdays, but don't care on weekends:

cru a channel_ck "20 0-6,18-23 * * 1-5 sh /jffs/scripts/channel-ck.sh" #ColinTaylors check channel number and restart
cru a channel_ck-we "21 * * * 0,6 sh /jffs/scripts/channel-ck.sh" #ColinTaylors check channel number and restart on weekends

This happens very infrequently for me, but I am renting in an area where the only free channels are DFS so I want my routers to keep to those channels.

EDIT: ha, it seems the man himself @ColinTaylor replied as I was typing my message,

 

[bluzfanmr1]

Big thanks for this script. I live in a highly congested area and I'm able to use DFS channels, mostly channel 132. Every once in awhile it will get kicked down to a non-DFS channel, but no more.

 

[samirchagan]

Thanks @ColinTaylor and @dev_null for such swift replies, the scripts and cru schedules are the cherry on top of the cake!

Well, since i use a combination of channel 128 and 160mhz for width my "momentarily" disconnect lasts exactly 10 minutes, only after that scanning time the 5G wifi becomes available. Just like @ColinTaylor shared https://www.snbforums.com/threads/rt-ax86u-doesnt-switch-back-to-dfs-channel.77728/post-784233 (I'm in Portugal, so... 10 minutes.)

Think i'll test this out: https://www.snbforums.com/threads/rt-ax86u-doesnt-switch-back-to-dfs-channel.77728/post-749293

 

[Jordan123]

Hey folks,

I've downgraded and followed a clean slate approach but it seems to be an unexpected feature I'll post it on GitHub when I get a second.