DFS Channels: Security Implications and Configuration

The 5 GHz band is shared spectrum: a large portion of it (the UNII-2 and UNII-2 Extended ranges, roughly 5260–5720 MHz depending on region) was allocated for unlicensed Wi-Fi use on the condition that Wi-Fi devices don't interfere with the incumbent users of that spectrum — primarily weather and military radar systems. Dynamic Frequency Selection is the mechanism that makes that coexistence possible: before transmitting on a DFS channel, an AP must perform a Channel Availability Check (CAC), listening for radar signatures for a minimum period (60 seconds in most regulatory domains) before it's allowed to begin transmitting. While operating, it continues in-service monitoring, and if it detects a radar signature it must stop transmitting on that channel within a short window and either move to a non-DFS channel or run a fresh CAC on a different DFS channel.

This is why DFS channels sometimes behave unpredictably compared to the fixed UNII-1 (36–48) and UNII-3 (149–165) channels: a legitimate radar detection (or, less commonly, a false positive from another interferer) can force an unplanned channel change and a brief service interruption while the new channel completes its CAC.

Two distinct radar-detection obligations apply to DFS channels. The Channel Availability Check runs before the AP starts using a DFS channel — a minimum 60-second silent listening period in most regions. Channels adjacent to Terminal Doppler Weather Radar (TDWR) installations, used in the US around channels 120, 124 and 128, carry a much longer CAC requirement (up to 600 seconds) because of the higher cost of a missed detection near active weather radar.

In-Service Monitoring continues for as long as the AP transmits on the channel, and a detected radar pulse forces an immediate channel vacate — this is separate from and in addition to the initial CAC. Because this can happen at any time during operation, any AP relying solely on DFS channels should be treated as having a non-zero probability of an unscheduled brief outage, however rare in practice for a given deployment.

DFS rules are set per regulatory domain and differ meaningfully between regions — this is exactly the data our DFS Channel Checker tool (/tools/wireless/dfs-checker) exposes for the US, EU and India. In the US (FCC), channels 52–144 are DFS-required, with 36–48 and 149–165 available without DFS obligations, and channels 120/124/128 carrying the extended TDWR-adjacent CAC. In the EU (ETSI), the DFS range is similarly channels 52–140, but critically the upper UNII-3 channels 149–165 that the US treats as license-exempt non-DFS spectrum are not permitted for Wi-Fi use in the EU at all — that spectrum is allocated elsewhere. India's WPC regulations follow a different allocation still, permitting 36–48 and 149–161 as non-DFS channels but not the 5500–5600 MHz range that both the US and EU use for the middle block of DFS channels.

The practical consequence: a channel plan or a piece of hardware validated in one regulatory domain cannot be assumed to be legal or even functionally identical in another. Multi-region deployments need per-country channel plans, not one global default.

DFS channel behavior has a few direct security and resilience consequences worth planning around rather than treating purely as an RF/networking detail.

• •Availability: a network whose entire capacity plan depends on DFS channels has an availability dependency on radar activity in the area — this matters for high-assurance links (e.g., a security operations center's primary AP) more than for general office coverage, where a brief per-AP interruption is a minor nuisance.
• •Radar-triggered channel changes are not attacker-controlled — you cannot spoof a legitimate weather radar signature to force a DFS vacate in a way that's practical or reliable — but the resulting channel-change event and brief re-association burst is a normal part of DFS operation that shouldn't be mistaken for an attack when reviewing WIDS logs.
• •CAC delays affect failover: if a controller moves an AP to a new DFS channel after a radar hit, that channel is unusable for up to the full CAC duration (up to 600s near TDWR) before clients can reconnect there — plan redundancy using a mix of DFS and non-DFS channels so failover doesn't stack multiple CAC delays.
• •Non-DFS channels (36–48, 149–165 in the US) remain the more predictable choice for links where availability matters most, at the cost of a smaller pool of non-overlapping channels and more co-channel contention in dense deployments.

hostapd exposes DFS state and radar events through its control interface and logs; a typical CAC-in-progress and radar-detected sequence looks like this:

wlan0: DFS-CAC-START freq=5500 chan=100 chan_offset=0 width=80 seg0=106 seg1=0 cac_time=60s
wlan0: DFS-CAC-COMPLETED success=1 freq=5500 chan=100 chan_offset=0 width=80 seg0=106 seg1=0
wlan0: AP-ENABLED

# Radar detected during in-service monitoring
wlan0: DFS-RADAR-DETECTED freq=5500 chan=100
wlan0: DFS-NOP-START freq=5500 chan=100 (Non-Occupancy Period, typically 30 min)
wlan0: DFS-CAC-START freq=5580 chan=116 width=80 cac_time=60s

• •Confirm the AP's regulatory domain setting matches its actual physical location — an incorrectly set country code can mean the device applies the wrong channel list and CAC timers, which is both a compliance and a functional problem.
• •For links where a CAC-triggered outage is unacceptable, prefer non-DFS channels (36–48, 149–165 in the US) even at the cost of a smaller channel pool.
• •Avoid TDWR-adjacent channels (120/124/128 in the US) near airports and weather installations given their extended CAC requirement, unless there's a specific reason to use that spectrum.
• •When troubleshooting an unexplained brief outage on a 5 GHz network, check for a DFS-RADAR-DETECTED event before assuming an attack or hardware fault — it's a much more common cause.
• •Cross-check channel/region assumptions against authoritative regulatory data per country rather than assuming US FCC behavior applies globally.