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

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

 



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.

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.

Thanks,
Seb

_______________________________________________
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