DFS channels require the AP to listen quietly for 60 seconds before using the channel. In the case when Channelfly is enabled, wouldn't this mean that when switching to a DFS channel, the AP essentially has to go offline for 60 seconds before coming back online again? This would have a significant impact on VoIP applications
Resurrecting this thread as I'm not seeing the behavior described, Keith - I likewise have a standalone 7982 with channelfly and DFS channels enabled, and I actually do see the AP go invisible for 60 seconds after a channel switch. Here's an example syslog from the AP showing my STA dropping off after channel switch, followed by ~1 min of silence (on the STA side I see the network disappear):
May 7 04:13:41 RuckusAP daemon.info channel-wifi1: channelfly on radio 11a/n switches from channel 157 to channel 104
May 7 04:13:43 RuckusAP user.warn kernel: Start DFS wait period for channel 104
May 7 04:13:43 RuckusAP daemon.info hostapd: wlan8: STA c8:e0:eb:18:f3:13 IEEE 802.11: disassociated
May 7 04:13:43 RuckusAP daemon.warn Eved: STA-DISASSOC-REASON,nimac=c8:e0:eb:18:f3:13,func=sta_disassoc,line=2207,hint=AP VAP state change (RUN->INIT or SCAN),rx_rssi=36,ack_rssi=0,reason=0,freq=5785,chan=157,stats=(551,83357,470,109137)
May 7 04:13:43 RuckusAP daemon.warn Eved: wifi1: CHANNEL-CHANGE.indication: Channel (104)
May 7 04:14:47 RuckusAP user.warn kernel: End of DFS wait period
AFAIK, it does not matter which feature or algo triggers the channel change, if DFS channel is selected, AP MUST go invisible for 60 seconds. this 60 second is nothing but Channel Availability Check Time or DFS wait period where presence of radar is checked prior to initiating a communications link on that new channel (ch 104 in this case).
this is as per DFS regulation which every OEM MUST follow.