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

 

[fast08]

FWIW - Here's what I have for the nearby APs . "phobos" is my network and the CH173 is the backhaul. The AP starting with a "B" is the neighbor - about 6meters away but I think the app is under estimating it. But regardless I think -60dBm is considered "good"

This is just after a radar detection a few hours ago - I wasn't home but when I got back from work, "B" is still on 160 and mine back to 80. Anyway at this point I'm fine with what I have - my house is closer to the street may be I got the short end of the stick

 

[rung]

Not sure if you are using Merlin, but there is a script written to address this issue. I don't use it, so I can't vouch for it's effectiveness:

https://www.snbforums.com/threads/channelhog-monitor-and-force-maximum-5ghz-bandwidth.61131/

 

[OzarkEdge]

FWIW - Here's what I have for the nearby APs . "phobos" is my network and the CH173 is the backhaul. The AP starting with a "B" is the neighbor - about 6meters away but I think the app is under estimating it. But regardless I think -60dBm is considered "good"

This is just after a radar detection a few hours ago - I wasn't home but when I got back from work, "B" is still on 160 and mine back to 80. Anyway at this point I'm fine with what I have - my house is closer to the street may be I got the short end of the stick

View attachment 64140

Your 5.0 radio competition is close! Tri-band equipment can mean more radios to tweak to co-exist. Split band usage (5-1, 5-2) further limits channel options. But being able to use UNII-4 helps and helps your uplink (5-2) performance... wish I had that here.

I notice the neighbor uses a non-DFS control channel 40 (good, as discussed earlier). Maybe they also fix their router max bandwidth to 160MHz to prohibit it from dropping to 80MHz (or less) to avoid ANY radio interference such as you (why they are winning the interference war). Have you tried fixing your 5-1 max bandwidth to 160MHz to see if it holds despite their interference? Maybe RADAR/DFS interference is not the problem(?) Clients will still connect at their max bandwidth, typically 80MHz or less.

Also, I believe the UNII-2a DFS band is limited to 250mW Tx power, not 1000mW. So when you use 160MHz in bands 1,2a, the overall Tx power and range is less than when you use 160MHz in bands 3,4... 3,4 allow 1000mW Tx power.

Try fixing 160MHz on 5-1 to see if it sticks despite interference with your neighbor... you both will have less power/range, but that may be a good thing. Otherwise, fix it on 80MHz and don't look back.

OE

 

[fast08]

Try fixing 160MHz on 5-1 to see if it sticks despite interference with your neighbor... you both will have less power/range, but that may be a good thing. Otherwise, fix it on 80MHz and don't look back.

Sounds good. Based on earlier post I already turned off DFS control channel check box. But unfortunately the interface does not allow 160 + auto control + no DFS:

Current:

If I select 160 only, the DFS is preselected

I could fix it on 44 though:

Which is better? May be I should leave it in current and see how it performs for a few days. Previous I've always end up control channel on DFS.

 

[fast08]

Not sure if you are using Merlin, but there is a script written to address this issue. I don't use it, so I can't vouch for it's effectiveness:

https://www.snbforums.com/threads/channelhog-monitor-and-force-maximum-5ghz-bandwidth.61131/

Thanks, I saw that when searching for this issue. I've been running merlin on my previous routers but haven't flashed AX11000 pro. I'm also not sure about interrupting wifi whenever the script kicks in and get an angry call from my wife. I will do what I can tweaking the configuration but if nothing helps I will just leave it at 80 for the stability. Not worth to fight for the 5GHz channels when all of the 6G is unoccupied. May be down the line when Wifi 7 settles, either my neighbor upgrades (hopefully) and I get to enjoy a less crowded 5G-1, or I move my set up.

side question - does merlin guarantee operation with Asus's router app?

 

[OzarkEdge]

Sounds good. Based on earlier post I already turned off DFS control channel check box. But unfortunately the interface does not allow 160 + auto control + no DFS:

Current:

View attachment 64154

If I select 160 only, the DFS is preselected
View attachment 64155

I could fix it on 44 though:

View attachment 64156

Which is better? May be I should leave it in current and see how it performs for a few days. Previous I've always end up control channel on DFS.

That UI can be buggy... .sometimes it can't 'get there from here'. Try making the settings in a different sequence and/or save intermediate settings first before making the final settings. I have seen this approach change which settings get offered for the user. There is no reason you can't fix a non-DFS control channel in band 1, and fix 160MHz bandwidth. Play around with it... it should get there.

OE

 

[dave14305]

side question - does merlin guarantee operation with Asus's router app?

No, no guarantee at all.

 

[bennor]

side question - does merlin guarantee operation with Asus's router app?

Right from the developer...

Configure it through the webui. The mobile app is not supported.

 

[fast08]

That UI can be buggy... .sometimes it can't 'get there from here'. Try making the settings in a different sequence and/or save intermediate settings first before making the final settings. I have seen this approach change which settings get offered for the user. There is no reason you can't fix a non-DFS control channel in band 1, and fix 160MHz bandwidth. Play around with it... it should get there.

OE

No dice, tried multiple ways / intermediate saves etc all end up with the DFS control preselected if channel width selection is only 160mhz.

Anyway I'm moving on for now with leaving it auto and let it drop to 80 and stay there. In the past week DFS hits almost every other day.