[RFC PATCH] mac80211: use auto channel list by default
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. 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 With this patch hostapd will switch to any other channel and continue operating there when it received a DFS event. When the channels property was set nothing changes. Revert "mac80211: create channel list for fixed channel operation" This reverts commit cfd2f3bf6f4825b66e9a4ca9cba7c65b93eb89c7. Signed-off-by: Hauke Mehrtens --- package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 3 --- 1 file changed, 3 deletions(-) diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh index 92c56afd24fd..d6be2ed76c36 100644 --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh @@ -111,9 +111,6 @@ mac80211_hostapd_setup_base() { json_get_values ht_capab_list ht_capab tx_burst json_get_values channel_list channels - [ "$auto_channel" = 0 ] && [ -z "$channel_list" ] && \ - channel_list="$channel" - set_default noscan 0 [ "$noscan" -gt 0 ] && hostapd_noscan=1 -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] mac80211: use auto channel list by default
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. ;) > 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. Best David > > With this patch hostapd will switch to any other channel and continue > operating there when it received a DFS event. When the channels property > was set nothing changes. > > Revert "mac80211: create channel list for fixed channel operation" > > This reverts commit cfd2f3bf6f4825b66e9a4ca9cba7c65b93eb89c7. > > Signed-off-by: Hauke Mehrtens > --- > package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > index 92c56afd24fd..d6be2ed76c36 100644 > --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh > @@ -111,9 +111,6 @@ mac80211_hostapd_setup_base() { > json_get_values ht_capab_list ht_capab tx_burst > json_get_values channel_list channels > > - [ "$auto_channel" = 0 ] && [ -z "$channel_list" ] && \ > - channel_list="$channel" > - > set_default noscan 0 > > [ "$noscan" -gt 0 ] && hostapd_noscan=1 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH] mac80211: use auto channel list by default
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 '1e14.pcie/pci:00/:00:01.0/: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 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