Re: [RFC PATCH] mac80211: use auto channel list by default

[Hauke Mehrtens]

Hi David,


On 5/3/21 1:14 AM, David Bauer wrote:

Hi Hauke,

On 5/3/21 12:23 AM, Hauke Mehrtens wrote:

This change removes setting the channels property by default to the
channel property if nothing else is specified.

When hostapd detects a DFS alarm and it has to switch channels allow
hostapd to switch to any channel in the frequency band if channels
property is not specified.

This was exactly the behavior I've tried to fix. My expectation when

configuring a specific channel would be, that the radio does not switch

to

an arbitrary channel when it is forced to do DFS. Especially as DFS channels
are required to be used when the AP is used Outdoors (At least in Germany /
ETSI).

When dynamic channel usage is desired, I'd expect the user to provide a

chanlist

or use the "auto" channel.

Maybe this is something which is is flexible in how it can be interpreted, so 
I'm
open to find an alternative solution for that. ;)

I assumed that this was intentional. ;-)

I was not aware of chanlist until recently, should we add this to the default configuration to promote it more? If the interface is just off for an hour and comes back this should be fine. Should we set the default 5GHz channel to auto?

When we set channels to the same channel as the channel variable it will
not switch channel, the interface will be deactivated and hostapd writes
this error message:

Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED 
freq=5640 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5640 cf2=0

Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: interface state

DFS->DFS

Wed Feb 10 17:24:48 2021 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5580 
chan=116 sec_chan=1, width=0, seg0=122, seg1=0, cac_time=60s

Wed Feb 10 17:24:48 2021 daemon.err hostapd: 20/40 MHz: center segment

0 (=122) and center freq 1 (=5590) not in sync

Wed Feb 10 17:24:48 2021 daemon.err hostapd: Can't set freq params
Wed Feb 10 17:24:48 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1

Can you share your radio settings? I've tested this back when the patch

was applied

and the radio reappeared after the NOP period.

I used these settings:
----
config wifi-device 'radio1'
        option type 'mac80211'
        option channel '120'
        option hwmode '11a'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option htmode 'VHT80'
        option country 'DE'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'mywifi'
        option encryption 'sae-mixed'
        option key 'mykeykey'
-----
on a Xiaomi Mi Router 3G (MT76x2E)





Hauke

I think hostapd tries to switch from 80MHz channel size to 40MHz to try to avoid DFS. When I debugged this further it looked like this switch is not fully working, it ends up in a mix of 80MHz and 40MHz settings and the validation fails. I am also seeing this with hostapd from April 2021. Did anyone ever ran the hostapd test suite? I would like to reproduce this problem there. I think there is a test case for this scenario already, but it could be that it needs some tweaks. Can I trigger DFS events intentional to trigger this code in hostapd? I do not want to wait 3 days till this happens.

OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel