On Mon, Aug 27, 2018 at 02:28:46PM -0700, peter.oh@xxxxxxxxxxxxxxxxx wrote:
> mac80211 does not allow mgmt tx to use off channel on
> DFS channels in non-ETSI domain, because it will invalidate
> CAC result on current operating channel.
> (mac80211 commit: 34373d12f3cbb74960a73431138ef619d857996f)
> Hence don't set offchanok for mgmt tx in case of DFS channels
> in non-ETSI.
> diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> @@ -7202,6 +7206,21 @@ static int wpa_driver_nl80211_send_action(struct i802_bss *bss,
> + if (is_mesh_interface(drv->nlmode)) {
> + modes = nl80211_get_hw_feature_data(bss, &num_modes,
> + &flags, &dfs_domain);
> + if (dfs_domain != HOSTAPD_DFS_REGION_ETSI &&
> + ieee80211_is_dfs(bss->freq, modes, num_modes))
This sounds unnecessarily heavy operation for every management frame TX
operation. Couldn't this information about DFS-ETSI be cached instead?
> + offchanok = 0;
And this won't work if the channel on which the frame is supposed to be
sent is not the operating channel. This should really be done
conditionally based on the operating channel and if ETSI case allows
somewhat more flexible rules for DFS channels, that could be considered
as an optimization. I guess the main issue with clearing offchanok would
be coming from trying to force the radio to remain active on the
operating channel for some time. For that to work, remain-on-channel
might actually be a better approach.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
