On Thu, Mar 24, 2022 at 01:39:06PM +0100, Nicolas Escande wrote:
> When you shouldn't use DFS channels (either disabled in conf or the
> driver doesn't support radar detection) we normaly mark all DFS cahnnels
> as disabled to prevent them from being used.
> However, there is a loophole when the driver exports
> WPA_DRIVER_FLAGS_DFS_OFFLOAD, this step is bypassed.
> Just because the driver handles DFS event without hostapd's help
> shouldn't impact ACS in any way, it is different from ACS offload.
>
> This led me to intanses where an AP would be brought up on a DFS
> channel, selected by ACS, while it shouldn't have (ieee80211h=0)
> diff --git a/src/ap/hw_features.c b/src/ap/hw_features.c
> @@ -119,9 +119,7 @@ int hostapd_get_hw_features(struct hostapd_iface *iface)
> HOSTAPD_CHAN_RADAR) && dfs_enabled) {
> dfs = 1;
> } else if (((feature->channels[j].flag &
> - HOSTAPD_CHAN_RADAR) &&
> - !(iface->drv_flags &
> - WPA_DRIVER_FLAGS_DFS_OFFLOAD)) ||
> + HOSTAPD_CHAN_RADAR) && !dfs_enabled) ||
> (feature->channels[j].flag &
> HOSTAPD_CHAN_NO_IR)) {
> feature->channels[j].flag |=
Why is this removing the use of WPA_DRIVER_FLAGS_DFS_OFFLOAD completely
here? I'm not completely sure I understood what kind of a case could
have allowed ACS to select a DFS channel incorrectly. Maybe that is
something that should be addressed in the ACS implementation instead?
Please note that the DFS offload cases might use different style for
configuring the DFS operations, so it is not clear whether the
ieee80211h parameter is really applicable in all such cases and this
type of a change could result in breaking something that is already
deployed.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
