DFS radar events
When an access point on a DFS channel detects radar, the rules force it off that channel and keep it off for a fixed non-occupancy period, and every client on that radio loses its connection.
On this page5 sections
Is this your problem? It presents like this
- Every client on one 5 GHz radio drops at the same moment, whatever the model.
- The access point's event log shows a radar detection and a channel change at the time of the drop.
- Clients on the access point's other radios, and on non-DFS channels, stay connected.
- The outage lasts longer when the access point moves to another DFS channel, because it must listen before it transmits.
- Several access points in the same area may log radar at the same moment.
- Bands
- 5 GHz DFS
Why it happens
Regulators let Wi-Fi share part of 5 GHz with radar on one condition: the access point listens, and it leaves when it hears radar. In the US, devices in 5.25 to 5.35 GHz and 5.47 to 5.725 GHz1 must detect radar, stop transmitting on the channel within 10 seconds with normal traffic allowed only for the first 200 ms, and stay off it for at least 30 minutes. ETSI EN 301 893 sets the same 10 second move and 30 minute non-occupancy period2, and caps all transmissions during the move at 1 second.
Where the access point goes next decides how long you wait. Before it can transmit on a DFS channel it must listen for 60 seconds, and in Europe channels that touch 5600 to 5650 MHz need 10 minutes. One enterprise Wi-Fi vendor sums it up: a hop from one DFS channel to another imposes at least a one-minute outage. Another documents its radio disassociating remaining clients on a hit.
Real radar sits on fixed frequencies, so it hits the same channels again and again. In the US, Terminal Doppler Weather Radars transmit in 5600 to 5650 MHz3, and the FCC tells anyone running 5 GHz devices within 35 km of one to take special care over frequency. Its investigations traced much of the interference to devices operating outdoors near airports. On the channel map, that range is 20 MHz channels 120, 124 and 128. If a yard or dock access point near an airport logs radar on those channels week after week, treat it as real and take them out of the plan there.
Channel switch announcements let some clients follow the access point to its new channel, and you should enable them. Support is optional on both sides, and one experienced practitioner says they should not be relied upon. The rule exists to protect radar. It does not care what was riding on the channel. If a control connection cannot survive the access point leaving, it does not belong on a channel the access point can be ordered to leave.
5 GHz Wi-Fi channels in the US, 20 MHz wide
16 of 25 channels must listen for radar and leave when they hear it. 9 carry no DFS requirement.
Channel center frequency is 5000 + 5 × channel number MHz. U-NII-2A (5.25 to 5.35 GHz) and U-NII-2C (5.47 to 5.725 GHz) carry the DFS requirement; channel 144 straddles 5.725 GHz, so part of it falls in a DFS band. The rules list no Wi-Fi band between 5.35 and 5.47 GHz. Channels above 165 are not shown. Rules differ by country; this is the US.
Source: 47 CFR 15.407.
What one radar detection does to a DFS channel
The access point has to leave. How long clients wait depends on where it goes next.
Schematic, not to scale
US rules: after a detection, normal traffic may continue for at most 200 ms, and every transmission on the channel must stop within 10 seconds. Before using any DFS channel, the access point must listen for radar for 60 seconds. A channel where radar was detected stays off limits for at least 30 minutes. Segments are not drawn to scale.
Source: 47 CFR 15.407(h)(2).
How to confirm it
- Pull the access point event log for the minute of the drop and look for a radar detection, the old channel, and the new one.
- Check whether every client on that radio dropped, or only one.
- Check whether neighboring access points on the same channel logged radar at the same moment. Several at once points to real radar.
- Note whether the new channel is also a DFS channel, and how long the radio stayed silent.
- Track radar events per channel over weeks to find the channels that keep getting hit.
The fix
- Move control traffic off DFS channels, onto non-DFS 5 GHz channels or 6 GHz.
- Remove the specific channels that log real radar from the channel plan.
- Narrow channel width so more of the plan fits in non-DFS spectrum.
- Enable channel switch announcements, but do not count on every client following them.
Prevent it at design time
- Decide at design time which traffic may ride DFS channels, and write it into the channel plan.
- Log radar events centrally, so the pattern shows before it stops a line.
- Check the non-DFS channel count for every regulatory domain you deploy in. It differs between FCC and ETSI rules.
About this page
Built from 6 sources: 1 standards body or lab, 2 regulators and government sources, 2 vendor documents and 1 other source. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "DFS radar events." OT Wireless, published October 5, 2026. https://otwireless.com/causes/dfs-radar-events/
APA 7
Rutter, B. (2026, October 5). DFS radar events. OT Wireless. https://otwireless.com/causes/dfs-radar-events/
BibTeX
@misc{rutter2026dfsradarevents,
author = {Rutter, Ben},
title = {{DFS radar events}},
year = {2026},
howpublished = {\url{https://otwireless.com/causes/dfs-radar-events/}},
organization = {OT Wireless},
}