[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)

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.

Hauke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x93DD20630910B515.asc
Type: application/pgp-keys
Size: 9895 bytes
Desc: OpenPGP public key
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210504/72218064/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20210504/72218064/attachment-0001.sig>