WiFi 160MHz

[dlukanidin]

The RT-AX88U itself switches Wifi to 80MHz from 160MHz.
Can't find a reason.

Test stand:
Master AiMesh router - RT_AX88U (160 MHz - on, channel - 48, width - 20/40/80/160)
Node - RT-AC86U ( 5 meters from master)
No meteo or other radars.

Experiment:
1. >service restart_wireless /on master/ All clients switch to node, master swith to 160MHz
2. waiting for a few minutes: WiFi scanner show width is 160MHz
3. >service restart_wireless /on node/ All clients switch to master, master swith to 80MHz, Log - only shows messages like: wlceventd: wlceventd_proc_event(540): eth7: ReAssoc C0:A6… and wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind C0:A6…

Please help me to understand why master router switch channel width to 80Mhz after clients connect to it?

 

[heysoundude]

AiMesh is designed to provide consistent wifi, right? Here's what I would suggest might be happening:
the AC86 maxes out at 80MHz on 5GHz band; mixing and matching AX and AC routers like that, the AX will "slow itself down" so the AC "keeps up"
for a 160MHz 5Ghz wifi mesh consistently, you'll need to retire the ac86 and replace it with a...ax58 maybe
(aren't the master and node awfully close to each other @ 5m? wireless or Ethernet backhaul?)
you could also relocate the AX88 to a more central location in your home, deactivate the AC86/mesh and see if the router defaults to 160MHz.
If not, look up ChannelHog in the Addons subforum - that was built to help, iirc.

ChannelHog - Monitor And Force Maximum 5GHz Bandwidth

v1.1.1 Updated - 28th June 2022 ChannelHog - Monitor and force maximum 5GHz bandwidth About; Tired of badly configured neighbours and DFS cutting your wireless bandwidth in half? Then this is the script for you! ChannelHog will monitor your current 5GHz channel bandwidth on a daily basis...

www.snbforums.com

 

[RAH-66]

width - 20/40/80/160

use only 160

 

[dlukanidin]

you'll need to retire the ac86 and replace it with a...ax58 maybe

I turned off the AC86 router and got exactly the same result after restart_wireless.
Log fragment:

ChannelHog - will does not work in my situation. It will restart WiFi in loop and block it as a result.

 

[dlukanidin]

use only 160

How it will work with AC clients?

 

[RAH-66]

@dlukanidin

use only 160, not auto 20/40/80/160

How it will work with AC clients?

customize AX88, clients don't matter.

 

[heysoundude]

I turned off the AC86 router and got exactly the same result after restart_wireless.

ChannelHog - will does not work in my situation. It will restart WiFi in loop and block it as a result.

have you checked out what the airwaves around you are like with Wifi Radar?

 

[drinkingbird]

The RT-AX88U itself switches Wifi to 80MHz from 160MHz.
Can't find a reason.

Test stand:
Master AiMesh router - RT_AX88U (160 MHz - on, channel - 48, width - 20/40/80/160)
Node - RT-AC86U ( 5 meters from master)
No meteo or other radars.

Experiment:
1. >service restart_wireless /on master/ All clients switch to node, master swith to 160MHz
2. waiting for a few minutes: WiFi scanner show width is 160MHz
3. >service restart_wireless /on node/ All clients switch to master, master swith to 80MHz, Log - only shows messages like: wlceventd: wlceventd_proc_event(540): eth7: ReAssoc C0:A6… and wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind C0:A6…

Please help me to understand why master router switch channel width to 80Mhz after clients connect to it?

160mhz requires 8 sequential channels which is almost guaranteed to have at least a couple with congestion or noise causing it to fail back. There is an 80+80 mode that will use the first 4 and last 4 channels (skipping DFS bands) but even then, you're using up most of the available spectrum and asking for interference. Not sure if Asus supports the 80+80 mode or not.

Similar to 40mhz 2.4ghz, sometimes you're just asking for too much.

 

[dlukanidin]

have you checked out what the airwaves around you are like with Wifi Radar?

>wl -i $(nvram get "wl1_ifname") radar_status
NO RADAR DETECTED

>wl -i $(nvram get "wl1_ifname") dfs_status
state IDLE time elapsed 0ms radar channel cleared by dfs none

use only 160, not auto 20/40/80/160

It works. I test it now. But what means 20/40/80/160 if 160 only works the same?

 

[RAH-66]

what means 20/40/80/160

it`s idiotism ) - based on unknown selection algorithms

List of WLAN channels - Wikipedia

en.wikipedia.org

 

[dlukanidin]

it`s idiotism ) - based on unknown selection algorithms

List of WLAN channels - Wikipedia

en.wikipedia.org

What is better 160 or 20/40/80/160 in terms of communication quality and different devices compatibility works in practice

 

[RAH-66]

@dlukanidin,
better width 160 and primary channel from popular 36-48

For example, not all clients "can" 149-165. And recently, they began to cut out 100-128 in some regions.

 

[dlukanidin]

Thank you all and especially RAH-66. I will be glad also to see another opinions.

 

[OzarkEdge]

Thank you all and especially RAH-66. I will be glad also to see another opinions.

Consider the router's bandwidth setting to be the max permitted bandwidth for client connections. And know that clients should connect at their max capable bandwidth, 20, 40, 80, or 160, subject to the router's current max bandwidth.

If you fix the router's max bandwidth setting, it won't change except to fall back from 160 to 80MHz to avoid RADAR per DFS by law.

If you allow the router to vary its max bandwidth setting by setting 20/40/80/160MHz, then the router may fall back to a lower max bandwidth to avoid interference, restricting client connections accordingly. Consider this 'Auto' max bandwidth, similar to Auto control channel to avoid interference.

Opinions are cheap; mine could be wrong.

OE

 

[dlukanidin]

If you allow the router to vary its max bandwidth setting by setting 20/40/80/160MHz, then the router may fall back to a lower max bandwidth to avoid interference, restricting client connections accordingly. Consider this 'Auto' max bandwidth, similar to Auto control channel to avoid interference.

Thanks, it's more clear. The algorithm itself, I think, in the Broadcom proprietary code.

 

[heysoundude]

>wl -i $(nvram get "wl1_ifname") radar_status
NO RADAR DETECTED

>wl -i $(nvram get "wl1_ifname") dfs_status
state IDLE time elapsed 0ms radar channel cleared by dfs none

It works. I test it now. But what means 20/40/80/160 if 160 only works the same?

No, do a wifi site survey of what may be interfering:

I may be under the mistaken understanding that it's part of all supported router's firmware. This is on my AC86 and it has helped me find space in the airwaves among my neighbours and their wireless footprints

 

[dlukanidin]

No, do a wifi site survey of what may be interfering:

I don’t have any other networks nearby at all. Only two my networks: first for clients - AiMesh on AX88 and AC86 (fixed channel 48), and second for transport to remote building - on two Ubiquiti Nano Station (fixed channel 149/40 MHz (Upper)). So no interfering from other networks. I use WiFi Explorer to check, not only at the location of the main router, but also 100m around.

 

[bigpcjunky]

I'm having the same problem with a RT-AX86U. I checked my logs and it isn't radar detection causing the switch from 160MHz to 80MHz. For me It looks like firmware after 186.5_2 and equivalent ASUS firmware causes the switch from 160MHz to 80MHz after Windows does a reboot/boot after shutdown or wake after sleep.

I don't think it's the Intel bluetooth wifi drivers not correctly saving/restoring the state as downgrading to Merlin 186.5_2 solved this problem for me.

 

[Shino]

I'm having the same problem with a RT-AX86U. I checked my logs and it isn't radar detection causing the switch from 160MHz to 80MHz. For me It looks like firmware after 386.5_2 and equivalent ASUS firmware causes the switch from 160MHz to 80MHz after Windows does a reboot/boot after shutdown or wake after sleep.

I don't think it's the Intel bluetooth wifi drivers not correctly saving/restoring the state as downgrading to Merlin 386.5_2 solved this problem for me.

I'm sure AX86U still has this problem on 388.2_2, once the bandwidth drops to 80MHz, it won't switch back to 160MHz.

 

[drinkingbird]

I'm sure AX86U still has this problem on 388.2_2, once the bandwidth drops to 80MHz, it won't switch back to 160MHz.

You need to check if it is radar detection causing it for you or the same bug as being discussed. If radar detection, it is normal and there are scripts available in the forums to have it retry 160 every so often. But that can result in downtime each time it does it.

In reality, for many users 160 just isn't practical since so much will cause it to fail back to 80. Considering you can get close to a gig on 80mhz AX and 160 has shorter range, do you actually need 160 and the headache that comes with it?