While debugging Bluetooth and Wi-Fi fighting over 2.4GHz, I hit a confusing one: my router was happily broadcasting a 5GHz network, my laptop was connected to it, and yet my phone’s Wi-Fi scan flat out refused to show it. Same SSID, same room.
The culprit (I think) wasDFS
Dynamic Frequency Selection- listen on the channel for ~1 minute before transmitting (Channel Availability Check),2 and
- keep monitoring, then immediately vacate the channel if it ever detects radar.3
That second rule is why DFS is bad for anything latency-sensitive: a radar hit — or a false detection, which happens4 — boots every client off with no warning while the AP scrambles to a new channel.
And the invisibility? A client isn’t allowed to transmit on a DFS channel until it has passively heard a beacon from an AP claiming it.5 So phones (to save battery and airtime) skip DFS channels during active scans — they only send probe requests on the always-allowed channels.6 My router had auto-selected channel 104, smack in the middle of the DFS range,7 so the phone never probed it and never saw it.
The non-DFS 5GHz channels — the ones that are always yours to use and always discoverable — are 36, 40, 44, 48 at the bottom and 149, 153, 157, 161 at the top (region dependent; my router only exposes the lower set).8 Pinning the radio to channel 36 made the network show up instantly and stop dropping out.
So if a 5GHz network is mysteriously missing on one device but fine on another, check whether it’s parked on a DFS channel.
Footnotes
-
In the 5 GHz band, the sub-bands 5250–5350 MHz and 5470–5725 MHz — channels 52–64 and 100–144 — are shared with radar (weather, military, aviation/maritime), where Wi-Fi is only a secondary user and radar has absolute priority. List of WLAN channels — Wikipedia; Dynamic Frequency Selection — Cisco Meraki Documentation. ↩
-
Before transmitting on a DFS channel, an AP must perform a Channel Availability Check, listening passively for 60 seconds on most DFS channels (extended to 600 seconds for the 5600–5650 MHz range). DFS Channels: What They Are and When to Avoid Them — Purple. ↩
-
On detecting radar the AP must stop using the channel within 10 seconds (the Channel Move Time), so “immediately” is approximate rather than instantaneous. DFS Channels: What They Are and When to Avoid Them — Purple. ↩
-
False (erroneous) radar detections are a well-documented real-world problem that can boot clients off a DFS channel without warning. Why I dislike DFS channels — Mac-WiFi. ↩
-
On a DFS channel a client may not transmit until it has passively heard a beacon (~100 ms) confirming an AP is present and the channel is radar-free; only then may it send a probe request. Dynamic Frequency Selection — CWNP; DFS channels and why to avoid them — WIFI_NC. ↩
-
To save airtime and battery, phones de-prioritize DFS channels when scanning — for example, iOS scans the UNII-2-Extended (DFS) channels only every 6th cycle, leaving APs on those channels invisible most of the time. Why I dislike DFS channels — Mac-WiFi. ↩
-
Channel 104 sits in UNII-2-Extended (UNII-2C) and is a DFS channel. List of WLAN channels — Wikipedia. ↩
-
Channels 36/40/44/48 (UNII-1) and 149/153/157/161/165 (UNII-3) are non-DFS and always available for active scanning; UNII-3 availability is region-dependent. List of WLAN channels — Wikipedia; U-NII Bands and 5 GHz Wi-Fi Channels — ib-lenhardt. ↩