Asus DFS algorithm

[fast08]

Hello,

Long time lurker just got around to make an account to post a question. I learned a lot from the forums but just never got to a point where a search won't turn up the answer I need Anyway here's the issue:

I have a double AX11000 pro AiMesh setup (latest stock firmware) where everything works consistently with 160MHz backhaul at the unii4 channels (I73)

The 5G-1 interface can be set to 160MHz (and surprisingly my neighbors also use Asus routers and use 160MHz channels). At my location every few days there will be radar detected and the router moves to 80MHz. But the problem is that I haven't seen it ever moving back. From the older posts I see folks mention that they also don't see router moving back to 160MHz. But Asus's help articles do say the router "might" go back.

Here's a sample log:

Feb 27 02:18:13 wlceventd: wlceventd_proc_event(831): eth7: Radar detected
Feb 27 02:18:13 kernel: In wl_dfs_cac_notify_status chanspec 0xe932 DFS state 3
Feb 27 02:18:13 cfg_server: cm_updateChanspec call wl_chanspec_changed_action
Feb 27 02:18:13 cfg_server: event: wl_chanspec_changed_action_a103 of eid(3) of cfgs(3074)
Feb 27 02:18:13 cfg_server: current chansp(unit0) is 100a, shall_be_excluded:0, avbl:1.
Feb 27 02:18:13 cfg_server: current chansp(unit1) is e932, shall_be_excluded:0, avbl:1.
Feb 27 02:18:14 cfg_server: current chansp(unit2) is eea3, shall_be_excluded:0, avbl:1.
Feb 27 02:18:14 cfg_server: dump exclchans:
Feb 27 02:18:14 cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Feb 27 02:18:14 cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Feb 27 02:18:14 cfg_server: valid wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Feb 27 02:18:14 cfg_server: old wl1_acs_excl_chans:0xd0b1,0xd9af,0xe3ab,0xefa3
Feb 27 02:18:14 cfg_server: new wl1_acs_excl_chans:0xd03c,0xd040,0xd83e,0xd93e,0xe23a,0xe33a,0xee32,0xef32
Feb 27 02:18:14 cfg_server: valid wl1_acs_excl_chans:0xd0b1,0xd9af,0xe3ab,0xefa3
Feb 27 02:18:14 cfg_server: old wl2_acs_excl_chans:0xd0b1,0xd9af,0xe3ab,0xefa3
Feb 27 02:18:14 cfg_server: new wl2_acs_excl_chans:0xd0b1,0xd9af,0xe3ab,0xefa3
Feb 27 02:18:14 cfg_server: valid wl2_acs_excl_chans:0xd0b1,0xd9af,0xe3ab,0xefa3
Feb 27 02:18:14 cfg_server:  wl_chanspec_changed_action: Need to restart acsd for AVBL update, static5G=0
Feb 27 02:18:14 rc_service: cfg_server 3074:notify_rc restart_acsd_acscli2
Feb 27 02:18:14 kernel: In wl_dfs_cac_notify_status chanspec 0xd028 DFS state 0
Feb 27 02:18:16 acsd: eth7: selected channel spec: 0xe12a (40/80)
Feb 27 02:18:16 acsd: eth7: Adjusted channel spec: 0xe12a (40/80)
Feb 27 02:18:16 acsd: eth7: selected channel spec: 0xe12a (40/80)

From Wifi analyzer on my phone I see my neighbors router reselect back 160MHz while mine stays 80, which is infuriating The DFS state also shows idle on my log:

DFS status: state IDLE time elapsed 0ms radar channel cleared by DFS channel 64/160 (0xEF32)

Any idea if it's a configuration issue? I have tried all of the options below on 5G-1

1. fixed 160MHz width , auto control channel or fixed
2. 20/40/80/160 , auto control channel or fixed

Current setup:

I do get the 2400+ mbps phy rate when 160 is enabled. First world problem I know but wondering if there's anything I can to make it better. Thanks!

 

[ColinTaylor]

...but wondering if there's anything I can to make it better.

Not really. It is what it is. Once RADAR has forced it to change channel the only scenario where it would voluntarily change again (back to the original or to a different channel) is if it sees that there's another channel that is significantly better than the one it's currently using. That's highly unlikely and not something I've ever seen happen myself.

 

[fast08]

Forgot to mention, after I manually toggle the 160 enable button on the UI, the wireless log shows a non-zero timer now:

DFS status: state In-Service Monitoring(ISM) time elapsed 198900ms radar channel cleared by DFS channel 64/160 (0xEF32)

What does this mean? In 3 minutes or so it will check radar again?

 

[ColinTaylor]

What does this mean? In 3 minutes or so it will check radar again?

No, it simply means that the current chanspec (channel/bandwidth) has been active for 198 seconds.

 

[fast08]

Not really. It is what it is. Once RADAR has forced it to change channel the only scenario where it would voluntarily change again (back to the original or to a different channel) is if it sees that there's another channel that is significantly better than the one it's currently using. That's highly unlikely and not something I've ever seen happen myself.

Got it, I guess the firmware also wants to reduce interruptions as much as possible. So switching back to 160 and disrupting connections might annoy more general users.

 

[OzarkEdge]

Current setup:

Do ALL of your wireless clients support the DFS channels?... typically not. If not, then you may want to deselect '... including DFS channels' to prevent the firmware from using a DFS control channel for those clients.

As for not returning to 160MHz bandwidth after a DFS event, this is not unexpected, but... I wonder if the firmware knows the difference (and if there is a difference) between RADAR and your neighbors' usage of DFS frequencies(?) in the 5-1 band. How close are their 5GHz APs?

Incidentally, if you are using a 160MHz wireless AiMesh uplink, have you noticed if this wireless uplink performs better using 80MHz bandwidth? Compare uplink connection details in the Wireless Log.

OE

 

[OzarkEdge]

So switching back to 160 and disrupting connections might annoy more general users.

I agree with this in principle... everything network admin should be done to protect the user experience... even when the admin is the only user!

OE

 

[fast08]

Do ALL of your wireless clients support the DFS channels?... typically not. If not, then you may want to deselect '... including DFS channels' to prevent the firmware from using a DFS control channel for those clients.

Oh, I thought I have to check the DFS box for router to use *any* DFS channels. You meant it's only for placing control channel on DFS channels? Everywhere I read on enabling DFS channels mention checking the box. But regardless I know most of my clients (laptops and phones) can connect to 160MHz (I used wifiman to check on each)

" How close are their 5GHz APs?"

California condo close let me get the analyzer screenshot tonight which has the approximate AP distances.

"Incidentally, if you are using a 160MHz wireless AiMesh uplink, have you noticed if this wireless uplink performs better using 80MHz bandwidth?"

Yes it's noticeably better with 160MHz uplink. I have 1Gps WAN. With 80MHz, the phy rate reported is at most 1200mbps, and speedtest on clients can only get to 800mpbs from WAN. But as mentioned, the backhaul is pretty stable at this point, it's the front haul that's loosing 160.
Thanks for the insights !

 

[OzarkEdge]

Oh, I thought I have to check the DFS box for router to use *any* DFS channels. You meant it's only for placing control channel on DFS channels? Everywhere I read on enabling DFS channels mention checking the box. But regardless I know most of my clients (laptops and phones) can connect to 160MHz (I used wifiman to check on each)

The channel setting (Auto or fixed) is for the control channel. If the control channel is DFS, legacy clients that can't use DFS channels won't connect. To accomodate them, use a non-DFS control channel... then only the extension channels will use neighboring DFS frequencies to achieve 160MHz bandwidth.

OE

 

[fast08]

I agree with this in principle... everything network admin should be done to protect the user experience... even when the admin is the only user!

OE

I have 4 users at home and they are not too happy with me interrupting their precious wifi connections

 

[OzarkEdge]

I have 4 users at home and they are not too happy with me interrupting their precious wifi connections

Yeah, damn users always have to be right.

OE