[ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Zefir Kurtisi <zefir.kurtisi@neratec.com>]

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.

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.

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).


Cheers,
Zefir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 999-0001-ath9k-do-not-enable-radar-pulse-detection-in-STA-mod.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20150113/8e077949/attachment.bin