On Tuesday 13 January 2015 11:16:02 Zefir Kurtisi wrote:
> On 01/10/2015 05:26 PM, Simon Wunderlich wrote:
> > On Friday 09 January 2015 19:57:37 Arend van Spriel wrote:
> >> On 01/09/15 17:54, Simon Wunderlich wrote:
> >>> Performing spectral scans on 5 GHz channels may result in PHY errors
> >>> sent by the hardware, even if DFS support is not enabled in the driver
> >>> (e.g. channel scanning or passive monitoring). In that case channels may
> >>> falsely get marked as 'unusable'. To fix that, only process radar PHY
> >>> errors when radar is explicitly enabled in the driver.
> >>
> >> Hi Simon,
> >>
> >> Not an ath9k expert, but I would think those channels would already be
> >> marked as unusable, because DFS is disabled in the driver. Or does this
> >> also affect 5G channels that do not require DFS.
> >>
> >> Regards,
> >> Arend
> >
> > Hey Arend,
> >
> > maybe that was not really clear, but this is talking about the DFS state
> > "unusable". By default, channels are marked in DFS state "usable", and
> > after the clear channel assessment (which is done e.g. when starting AP
> > mode) they are marked as "available". As soon as radar is detected they
> > are marked as "unusable".
> >
> > These DFS state changes should only happen while there is something
> > operating with radar enabled, e.g. AP mode. It should not happen if we
> > just have monitor mode or scan for channels. These channels should then
> > stay in their previous DFS state (e.g. 'usable'). This was borked and
> > this patch tries to fix it. :)
> >
> > Cheers,
> >
> > Simon
>
> Hi,
>
> the issue here is that DFS and spectral use the same PHY_ERROR reporting
> mechanism, and the dfs module is still in its initial state prior the
> spectral support was added. With that, feeding the dfs detector with
> PHY_ERROR frames generated by spectral scanner might cause false radar
> detections.
Yup, that's right - we noticed that too, and its written in various places
that the FFT and DFS hardware logic is shared. :)
>
> I did not dig how the hw->conf.radar_enabled flag is set in monitor mode,
> but if it is same as for master (i.e. set for DFS channels), then it would
> be a better approach to prevent calling ath9k_dfs_process_phyerr()
> altogether from ath9k_rx_skb_preprocess() if not set.
Hm, you mean like - if radar_enabled then dfs_process, otherwise fft_process?
That would might be more elegant indeed ...
The monitor mode does not have the radar flag enabled,
cfg80211_chandef_dfs_required() returns 0 in this case.
>
> And while you're at that: slaves do not need to scan for radar, might be
> worth checking if it makes sense to selectively disable radar detection in
> STA mode. I am using attached private OpenWRT patch for that - which still
> would interfere with spectral scanning. Generally, the PHY_ERROR processing
> should be reworked but becomes quite complicated when you take into account
> special use-cases. Think of radar events being treated differently
> depending on whether a master or a monitor detected them (OC-CAC vs. ISM).
I didn't check if that is enforced correctly, but
cfg80211_chandef_dfs_required() returns if radar is required for the various
interface types - AP, Adhoc and Mesh have it enabled if its a DFS channel,
client, monitor, etc don't have it enabled. That gets marked in the sdata-
>radar_required, and ieee80211_is_radar_required() checks all interfaces if
there is any interface which needs radar. So that should have been taken care
of.
Therefore I think that this is already handled in cfg80211/mac80211 and ath9k
should not check the iftype at all, but only check the radar_enabled flag.
Off-channel CAC is certainly a different beast, but as far as I know we
currently don't support that anyway. :)
Cheers,
SimonAttachment:
signature.asc
Description: This is a digitally signed message part.
