Re: hostap response to DFS 'radar detected' events - channel recovery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17 May 2018 at 19:11, Janusz Dziedzic <janusz.dziedzic@xxxxxxxxx> wrote:
> 2018-05-09 12:48 GMT+02:00 Seb Belcher <s.d.j.belcher@xxxxxxxxx>:
>> Hi all,
>>
>> I have noticed some behavior on my LEDE powered Linksys router
>> regarding the response to DFS 'radar detected' events when a DFS
>> channel has been manually selected for a 5GHz radio (i.e. non-ACS).
>>
>> hostap is correctly responding and immediately switching to a
>> different channel.  However it then stays on this alternate channel
>> indefinitely.
>>
>> This causes issues when the alternate channel selected by hostapd is a
>> congested 5Ghz channel, resulting in poorer performance for clients.
>> From my understanding of the IEEE guidelines for DFS, the channel
>> change is only supposed to be temporary and after the DFS NOP
>> (non-occupancy) period has expired, which is typically 30 minutes, the
>> radio is permitted to switch back to the originally configured channel
>> if no further radar is detected for 60 seconds.
>>
>> Seemingly right now the only way to 'fix' this channel change back to
>> the original channel is to manually restart hostapd with the original
>> settings again.
>>
> You should/can write an application that will do that via hostapd_cli and
> chan_switch (should be able to start CAC again, if not you can easy
> fix it).
>
> Why application:
> - will monitor events from hostapd_cli monitor
> - why back to the same dfs channel, maybe better use another DFS?
> - application can check surveys and decide what channel will be the best
> - anyway you need also disconnect 5GHz clients because of CAC
> - you can start global instance of hostapd and
> configure/enable/disable bss via hostapd_cli
>
> So, some kind of manager would be best here - will decide what to do.
>
>> Could a feature be added to allow hostap to automatically switch back
>> to the configured channel after the NOP period has expired?  The
>> trade-off here is that this action requires another 60 second DFS
>> scan, resulting in radio down-time, so this ideally would be
>> selectable in the config.
>>
> This is also possible and probably will be easy to do (conf param),
> but question when to do that?
> Wait for no-station connected? This could be one of the solutions ...

Wait for no stations is certainly what other AP manufacturers do ref:
https://documentation.meraki.com/MR/Radio_Settings/Dynamic_Frequency_Selection_(DFS)

Personally I think 3 configurable options would be most flexible for
post Radar Detected DFS events:
1. Remain on new channel.
2. Revert to original channel immediately after NOP expiry.
3. Revert to original channel when no stations connected.

The above would be modified by the ACS setting, so that ACS would be
used for 2 and 3 if set for that SSID/radio.
Best,
Seb

>
> BR
> Janusz
>> Thanks,
>> Seb
>>
>> _______________________________________________
>> Hostap mailing list
>> Hostap@xxxxxxxxxxxxxxxxxxx
>> http://lists.infradead.org/mailman/listinfo/hostap
>
>
>
> --
> Janusz Dziedzic

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux