DFS Wi-Fi channels are invisible to phones

Mon, 22 Jun 2026 00:00:00 GMT

import Detail from "../../components/Detail.astro"; While debugging [Bluetooth and Wi-Fi fighting over 2.4GHz](/posts/bluetooth-wifi-coexistence), 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) was DFS[Dynamic Frequency Selection](https://en.wikipedia.org/wiki/Dynamic_frequency_selection). It turns out a chunk of the 5GHz band (channels 52–144) is shared with radar — weather, military, aviation. Wi-Fi does not have priority.[^secondary] To use those channels an access point has to: - listen on the channel for ~1 minute before transmitting (Channel Availability Check),[^cac] and - keep monitoring, then **immediately vacate** the channel if it ever detects radar.[^vacate] That second rule is why DFS is bad for anything latency-sensitive: a radar hit — or a _false_ detection, which happens[^false] — 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.[^passive] So phones (to save battery and airtime) **skip DFS channels during active scans** — they only send probe requests on the always-allowed channels.[^phonescan] My router had auto-selected channel 104, smack in the middle of the DFS range,[^ch104] 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).[^nondfs] 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. [^secondary]: 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](https://en.wikipedia.org/wiki/List_of_WLAN_channels); [Dynamic Frequency Selection — Cisco Meraki Documentation](https://documentation.meraki.com/Wireless/Operate_and_Maintain/User_Guides/Radio_Settings/Dynamic_Frequency_Selection_(DFS)). [^cac]: 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](https://www.purple.ai/en-us/guides/dfs-channels-what-they-are-and-when-to-avoid-them). [^vacate]: 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](https://www.purple.ai/en-us/guides/dfs-channels-what-they-are-and-when-to-avoid-them). [^false]: 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](https://mac-wifi.com/why-i-dislike-dfs-channels-and-you-might-too/). [^passive]: 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](https://www.cwnp.com/dynamic-frequency-selection/); [DFS channels and why to avoid them — WIFI_NC](https://wifinc.net/dfs-channels-and-why-to-avoid-them-even-though-you-say-you-cannot/). [^phonescan]: 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](https://mac-wifi.com/why-i-dislike-dfs-channels-and-you-might-too/). [^ch104]: Channel 104 sits in UNII-2-Extended (UNII-2C) and is a DFS channel. [List of WLAN channels — Wikipedia](https://en.wikipedia.org/wiki/List_of_WLAN_channels). [^nondfs]: 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](https://en.wikipedia.org/wiki/List_of_WLAN_channels); [U-NII Bands and 5 GHz Wi-Fi Channels — ib-lenhardt](https://ib-lenhardt.com/kb/glossary/unii-bands).

Bluetooth and Wi-Fi fight over 2.4GHz

Mon, 22 Jun 2026 00:00:00 GMT

I have a phone running a Snapcast client: it pulls synced audio over Wi-Fi and plays it out to a pair of Bluetooth headphones. It buffered constantly: a few seconds of audio, then a stall, then a reconnect.

The Wi-Fi signal was excellent (RSSI -44), the server was idle, and the same stream played fine elsewhere, so naturally I blamed everything except the obvious thing. Eventually I just pinged the server with Bluetooth on, then turned Bluetooth off and pinged again. Same Wi-Fi network, same location, seconds apart:

# Bluetooth ON (streaming to the headphones)
10 packets transmitted, 8 received, 20% packet loss
rtt min/avg/max/mdev = 8.6/238.6/742.4/254.4 ms

# Bluetooth OFF
10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 7.4/9.1/10.8/0.9 ms

The only variable was Bluetooth, and it took the link from a flawless 9ms to 238ms average with 20% loss.

The cause is 2.4GHz coexistence. Bluetooth lives in the 2.4GHz band,¹ and so did my Wi-Fi. On a phone the two typically share a single radio and antenna,² so pushing audio out over Bluetooth while pulling audio in over 2.4GHz Wi-Fi means they have to take turns and they trample each other. Snapcast streams real-time PCM with a ~1s buffer;³ with packets arriving 250ms+ late and one in five dropped, the buffer starves and the client gives up and reconnects.

The fix was to get Wi-Fi off the band Bluetooth is squatting on: move the phone to 5GHz. Bluetooth stays on 2.4GHz, Wi-Fi moves up, and they stop fighting.

There was one more gotcha. The 5GHz SSID didn’t even show up in the phone’s Wi-Fi scans as the router had auto-selected channel 104, which phones won’t see. I pinned the router’s 5GHz radio to channel 36 and the problem disappeared entirely:

# 5GHz channel 36, Bluetooth still ON
12 packets transmitted, 12 received, 0% packet loss
rtt min/avg/max/mdev = 8.9/10.3/13.7/1.3 ms

10ms average, 1.3ms jitter, zero loss with Bluetooth doing exactly what it was doing before. The audio has been rock solid since.

Bluetooth operates in the 2.4 GHz ISM band (2.400–2.4835 GHz), the same unlicensed band used by 2.4 GHz Wi-Fi. “Improved Spectrum Coexistence in 2.4 GHz ISM Band Using Optimized Chaotic Frequency Hopping for Wi-Fi and Bluetooth Signals”, Sensors (NCBI/PMC). ↩
Phones commonly use a combined Wi-Fi/Bluetooth chip that shares a single antenna between the two radios, requiring time-division coexistence so they transmit in alternating time slots rather than simultaneously. “Systems and methods for coexistence between plurality of wireless communications modules sharing single antenna”, US Patent 9,130,605. ↩
Snapcast reads PCM chunks from its source and tags them with server time for synchronized playback; its default read/buffer size is 1000 ms. Note that, while it supports an uncompressed pcm codec, its default wire codec is FLAC rather than raw PCM. Snapcast README — codecs and buffering. ↩

]]>

RSS Feed for networking - James Stone's Blog

DFS Wi-Fi channels are invisible to phones

Bluetooth and Wi-Fi fight over 2.4GHz

Footnotes