Hi,
I've been seeing some issues with DFS on ath10k but this could
also affect ath9k.
In the end of the CAC period there seems to be a time window in
which ath10k won't detect any radar pulses (<1sec) before starting
operation on this channel. Reason is that the channel context for
CAC is getting removed and it takes some time for hostapd to
finish the hw setup so a new channel context gets set.
This is no suitable patch but provides some more insight into
this issue:
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -494,9 +494,9 @@
if (!local->use_chanctx) {
struct cfg80211_chan_def *chandef = &local->_oper_chandef;
- chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
+ /*chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
chandef->center_freq1 = chandef->chan->center_freq;
- chandef->center_freq2 = 0;
+ chandef->center_freq2 = 0;*/
/* NOTE: Disabling radar is only valid here for
* single channel context. To be sure, check it ...
@@ -504,7 +504,7 @@
WARN_ON(local->hw.conf.radar_enabled &&
!list_empty(&local->chanctx_list));
- local->hw.conf.radar_enabled = false;
+ local->hw.conf.radar_enabled =
cfg80211_chandef_dfs_required(local->hw.wiphy, chandef,
NL80211_IFTYPE_AP);
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
} else {
Not sure how to get this race free. hostapd might have to configure
the channel before the CAC period is finished so there is no
window without channel context.
Did anyone else notice this? Any ideas?
Thanks,
Helmut