I tested the DFS implementation in Extreme Networks legacy AP 3800 and 3900 series. Unfortunately, it does not implement channel switch announcement.
Upon detecting a radar signal, a legacy Extreme AP 3900 complies to domain regulation and leaves the 5Ghz channel where radar was received. It does so by sending deauthentication frames to the BSS and moving straight to a new channel. There is no Channel Switch Announcement in action frames or in beacons. The new channel number however can be defined in the controller configuration.
Affected devices
This issue affects legacy, controller-based 3900 and 3800 APs from the ExtremeWireless/Identify product line. It does not affect the recent ExtremeWireless cloud AP line following the Aerohive acquisition.
The following models were tested:
- WSAP3935i-ROW firmware 10.51.170006
- WSAP3915i-ROW firmware 10.51.170006
- WSAP3912i-ROW firmware 10.51.170006
- AP3825 firmware 10.51.170006
3900 are 802.11ac Wave2 APs that went out of sale in December 2020. They are supported through 2025 on the latest Extreme Campus Controllers (ECC).
3800s are an older 802.11ac Wave1 AP line, still supported until 2023 on legacy Extreme controllers.
I have not tested the 3900s from the WING product line. As far as I know it’s exactly the same chipset. If you are a WING user and use DFS channels, you should test.
Background
During a CWNA course in 2019, Devin Akin mentioned DFS validation and the wide differences in DFS implementation by vendor and by AP model. The DFS Project website has a good introduction to the issue and several example packet captures you can check out. The DFS Project lists a set of questions that the validation process should answer:
- Does my AP detect DFS events of various types?
- If a DFS event is detected, does my AP move to a new channel? If so, how long does that take?
- Does my AP announce the Channel Switch Announcement (CSA) in beacons, probe responses, and action frames? If so, for how long?
- If a DFS event happens, how does it affect application performance on my devices?
- When my channel changes, where does it go?
- Does my AP return to the original channel? If so, after how long?
- After a channel change, what happens to the channels on the other APs in the area?
The Channel Switch Announcement information element is found in action frames and beacons. It provides a graceful transition mechanism to a new channel, while keeping the client stations associated. The clients are informed of the channel number and the move time. If the destination channel is U-NII-1 U-NII-3 (non DFS) the service disruption is minimal.
Tools
I used the Wifimetrix handheld wi-fi tester, which I finally purchased this year. It does many useful WLAN things, my favorite being the FCC radar wave simulation. I am under the ETSI regulatory domain, so the Wifimetrix manufacturers kindly provided me this FCC-ETSI equivalence table:
FCC ETSI 0 1,2 1 1,2 3 3 4 3
Test results
I configured Extreme APs 3935, 3915, 3912 and 3825 on a DFS channel on 5Ghz, and started a packet capture. I simulated a radar event on that channel with the Wifimetrix and analyzed AP behavior in the capture.
Leaving the channel
Upon detecting a radar signal, the AP sends broadcast and unicast deauthentication frames with Reason code: Deauthenticated because sending STA is leaving (or has left) IBSS or ESS (0x0003). It then leaves the channel for good.
The destination channel can be defined in the AP configuration as custom channel plan (legacy Identifi controllers) or DFS fallback channel (Extreme Campus Controller). It should be a non-DFS chanel so that the AP does not have to perform a Channel Availability Check (CAC) and can start transmitting immediately.
Switching back to the original channel
I have not tested this behavior fully, this are just my preliminary results with a 3912 on ECC. After about 1 hour the AP simply leaves the channel without any deauthentication of CSA frames.
It is very likely that the AP will do a channel availability check before resuming transmission in the original DFS channel, but I have not tested it yet.
Impact assessment
The DFS mechanism implemented in this APs effectively disrupts service to the client stations in the basic service set.
Leaving the channel
When the AP detects a radar signal it send deauthentication frames to the BSS. After being deauthenticated (and therefore disassociated), clients cannot use roaming mechanisms to move to another AP. The client will choose to associate to the original BSSID, to the 2.4 Ghz BSSID from the same AP, or to another AP.
The clients must discover the new channel (or a new BSSID) by themselves, either listening to beacons, sending probes, or using information from the neighbor report if 802.11k is implemented. Clients must then do authentication, association, PSK or 802.1X authentication.
This will break voice calls and realtime audio/video conferencing. Buffered multimedia streaming may or may not be impacted, asynchronous traffic such as web and email may not notice any interruption.
Since the fallback channel can be defined, there is some room to ensure that the destination channel is U-NII-1 in a contingency channel plan.
Returning back to the original channel
The switchback to the original channel seems to be totally silent. Client stations won’t receive ACKs to their frames, beacons will be missed, and the clients will eventually move to another channel or BSSID. In addition, CAC will be performed by the AP on the original DFS channel.
This means service disruption for all kind of traffic. The only upside is that clients will keep their association, so that after learning AP information via beacons, probes or neighbor reports, the client can roam to another BSSID. If 802.11r is enabled, roaming may be fast and almost seamless.
Impact on channel plans
Deployments with low AP and user density, in domains where U-NII-1 and U-NII-3 channels are available, should exclude DFS channels from the channel plan.
High density deployments with potential high co-channel interference should carefully evaluate the requirements and choose a trade-off between service availability and airtime:
- sticking to non-DFS channels will prevent occasional service disruption caused by radar events, but due to CCI the airtime % use will be high and the service will be severely degraded permanently.
- including DFS channels in the channel plan will minimize CCI, at the price of the occasional disruption caused by radar evens (real or false positives).
Whichever you choose, it is important to state the issue clearly to the organization management. Users should be informed of the service level they can expect from the wi-fi network.
Mitigation
Extreme Networks in their support documentation recommends to monitor the occurrences of DFS events, and exclude the frequently offending channels from the custom channel plan on an AP by AP base. There is no dynamic RRM for DFS issues in 3900 APs, only an initial auto channel setup called ACS (automatic channel selection).
Other techniques that I have found helpful are:
- Enable 802.11k to help clients finding their next AP. This is important even if there are no radar events, as clients cannot do active discovery on DFS channels.
- Plan 2.4 Ghz wisely. Clients will probably associate to the same AP on 2.4, if available.
- Design good secondary coverage. If there are 2 APs in a lecture hall, configure one AP on an U-NII-1 channel and another on a DFS channel.
Long term solution
Unfortunately, the only permanent solution to this issue is replacing 3900 and 3800 APs with more modern models that implement Channel Switch Announcement correctly. This may be expensive, given the high number of 3900s installed and the longevity of the product. Management should be informed of the issue and involved in the assessment of its impact.
Final considerations
DFS events in the wild are difficult to capture and analyze. Vendor datasheets and documentation may not go in such details. You should always validate the DFS implementation of your APs, you could be in for a surprise. Buy a Wifimetrix and go testing, or have a WLAN professional do it for you.