4.0.1b2 - DFS in Auto Channels not enabling on AXT1800

4.0.1b2 not allowing DFS channels in ACS space for US

Expected behavior would allow ACS for DFS channels based on declared wireless regulatory area

DFS channels can be manually selected, but DFS should be enabled for ACS, that’s kind of the purpose of allowing DFS in the first place.

Steps to reproduce.

  1. Log into Web UI
  2. Go to “Wireless”
  3. Select 5GHz
  4. Press “Modify”
  5. Enable “Allow DFS Channel” - note slider is enabled/true
  6. Press Save
  7. Select Internet, and then go back to Wireless
  8. Observe that “Allow DFS Channel” is now reset back to disabled/false

uci show wireless and /etc/config wireless ranges are non-DFS channels only

root@GL-AXT1800:~# iw reg get
global
country US: DFS-FCC
        (2400 - 2472 @ 40), (N/A, 30), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
        (5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5730 - 5850 @ 80), (N/A, 30), (N/A)
        (57240 - 71000 @ 2160), (N/A, 40), (N/A)

phy#1 (self-managed)
country US: DFS-FCC
        (2402 - 2472 @ 40), (6, 30), (N/A)
        (5170 - 5250 @ 80), (6, 30), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (6, 24), (0 ms), DFS, AUTO-BW
        (5735 - 5895 @ 160), (6, 30), (N/A), AUTO-BW

phy#0 (self-managed)
country US: DFS-FCC
        (2402 - 2472 @ 40), (6, 30), (N/A)
        (5170 - 5250 @ 80), (6, 30), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (6, 24), (0 ms), DFS, AUTO-BW
        (5735 - 5895 @ 160), (6, 30), (N/A), AUTO-BW

root@GL-AXT1800:/etc/config# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='platform/soc/c000000.wifi'
wireless.radio0.band='5g'
wireless.radio0.htmode='HE80'
wireless.radio0.country='US'
wireless.radio0.disabled='0'
wireless.radio0.legacy_rates='0'
wireless.radio0.channels='36 40 44 48 149 153 157 161 165'
wireless.radio0.hwmode='11a'
wireless.radio0.channel='auto'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.wds='1'
wireless.default_radio0.isolate='0'
wireless.default_radio0.ssid='thumper'
wireless.default_radio0.hidden='0'
wireless.default_radio0.key='cellbounce34'
wireless.default_radio0.disabled='0'
wireless.default_radio0.encryption='sae-mixed'

If you select Auto in the “Channel” Option, the router does not automatically select the DFS channel.
The “Allow DFS Channel” switch is a Fool-proofing design.
Selecting the DFS channel will cause the WiFi to be temporarily turned off. So to avoid misuse, users need to turn it on manually every time they switch from non-DFS channel to DFS channel.

If you feel that this is misleading, we will review the interaction design here.

One should not be able to explicitly set a DFS channel, as this could be one where DFS could be an issue - which in that case, the radio has to either disable the transmitter, or “auto” tune to another channel, either non-DFS, or another DFS channel that meets the allowed conditions.

  • If DFS==True and Auto==True - start in a non-DFS channel, allow ACS to do it’s channel triage, and if a channel is clear, change to that channel, and send the 802.11 action message for the clients to follow.
  • If DFS!=True, and Auto==True - then ACS scans the non-DFS channels, and chooses the best possible candidate.
  • If DFS!=True, and Auto!=True - expose the non-DFS channels, and allow user to select accordingly

At no time, shall DFS channels be allowed to be manually selected by the end user, as the End-User has no idea if they are in a DFS area, thus potentially allowing misuse of the feature.

What the WebUI has now is exactly opposite.

I understand what you mean and we will discuss this interface design again.

They are not exactly opposite, which I may not have explained clearly before.
When using the DFS channel, scanning the radar signal to avoid conflicts is a must. So:

  • If the user selects a channel that does not conflict with the radar, then the router will use that channel
  • If the user selects a channel that conflicts with the radar, then the router will use another non-conflicting channel
    In other words, the user-selected channel is only used as a preference.
    If channels 52/56/60/64 are available, why not let the user choose to use 56?

But I think your suggestion is very useful. We should not force the user to enter the “Preference”.
Thanks again.

Thanks for looking into it.

Also, I have found a few client STA’s that also do not support DFS channels, which could make things interesting - so default’s should be carefully decided to avoid customer care issues…

Question, if the customer selects 56, and initially it works, but a DFS event occurs and AP moves to a non-DFS channel, how to display the channel that is now in use, because DFS has gone to another channel via ACS - not all client stations support all channels…

Last minute comment - since this is a travel router, user selection shouldn’t be a DFS channel - might be good in Chicago, but drop it in the bag and go to Munich - DFS might not be allowed due to a doppler weather radar close by (having first hand experience there)

Like relationships in Facebook, DFS is complicated :slight_smile: