The living-room TV was, according to every indicator it had, perfectly online. Full WiFi bars. Connected to the right network. Strong signal. And it could not load a single thing — Jellyfin said "server not available," Home Assistant showed it as dead, and a ping to it came back 100% loss. It was the most confident "I'm fine" I've ever seen from a device that was, in every way that mattered, not fine at all.
The symptom that made no sense
A device that's off, or out of range, or on the wrong password fails in ways you understand. This wasn't that. The TV was associated — the access point agreed it was connected, the signal strength was strong, the little icon was full. But not one packet crossed. Ping it: silence. Ask Home Assistant: unavailable. Open Jellyfin on it: nothing.
Every "connected but no internet" reflex I have is about the layers above WiFi — DHCP, DNS, a gateway, a firewall rule. So I chased those first, and every one of them checked out. The lease was valid. DNS was fine for everything else in the house. Nothing in the routing had changed. The dead thing was the one layer everything reported as healthy: the radio link itself.
It was associated and it was strong and it was completely deaf. The link existed on paper and nowhere else.
The clue was in the timing
The thing that cracked it wasn't a log line, it was a pattern: this only happened to the 5 GHz devices, and it happened after the access point had, for no reason I'd asked for, briefly changed channels. Which sent me reading about a corner of WiFi I'd been happily ignoring: DFS.
A big chunk of the 5 GHz band is shared spectrum — the same frequencies weather and military radar use. To be allowed on those channels, your access point has to run Dynamic Frequency Selection: it must listen for radar, and the instant it thinks it hears any, it is legally required to vacate the channel immediately and go find another one, re-running a mandatory listen-before-transmit check on the new one. That gap is real dead air, and my access point was sitting on channel 100 — squarely in DFS territory.
So the sequence was: AP thinks it hears radar (often a phantom — a false positive, no actual radar anywhere), AP bolts off channel 100 to re-establish elsewhere, and the clients have to follow it across. Most of my devices did that fine. The TV did not.
Why the TV, specifically
This is the part I'd never have guessed: televisions are notoriously bad at DFS channel switches. When the AP jumps channels, a well-behaved client notices it's been cut loose and re-associates cleanly. A cheap smart-TV WiFi stack instead gets wedged into a half-state — it still believes it's associated on the old channel, keeps reporting a strong link, and never re-negotiates. It's not disconnected enough to trigger its own "reconnect" logic, and not connected enough to move a byte. A zombie.
And the intuitive fix — power the TV off and on with the remote — doesn't touch it. Android TV "off" is really standby, and standby keeps the wedged WiFi state alive. You turn it "off," turn it back "on," and the zombie is right there waiting, still lying about its bars.
The 20-second rescue
The trick that actually revives it, without rebooting anything or bouncing the whole radio (which would knock every other device off too), is to kick just that one client off at the access point and force it to start over. On OpenWRT that's a single call into hostapd, targeting the TV's MAC:
ubus call hostapd.phy3-ap0 del_client \
'{"addr":"10:b2:32:f8:d3:f4","reason":5,"deauth":true,"ban_time":0}'De-authenticated and un-banned in the same breath, the TV has no choice but to notice it's gone, re-associate from scratch, and pull a fresh DHCP lease. Within a poll cycle it's back in Home Assistant and Jellyfin plays. It's a lovely party trick — and it is treating the symptom, every single time, forever.
The actual fix: get off the shared spectrum
The real problem was never the TV's flaky radio — I can't patch that. The real problem was that I'd parked the access point on a DFS channel at all. If the AP never has to run from phantom radar, the TV never gets orphaned, and there's nothing to rescue.
The lower 5 GHz channels — 36, 40, 44, 48 — aren't subject to DFS at all. No radar duty, no sudden evictions, no re-checks. My other AP was already on 36, so I moved the offending one down to channel 44: close enough to be clean, far enough to not fight its neighbor. Both radios are now firmly outside DFS. Since the move, the zombie hasn't come back once — not because the TV got better at DFS, but because it never has to do a DFS switch again.
ch100 (DFS: subject to radar eviction) → ch44 (non-DFS: no eviction, ever)The lesson
Two things I took from this. First, the diagnostic one: "connected" is a claim, not a measurement. A full signal bar tells you two radios agreed to talk; it tells you nothing about whether they are. When a device insists it's fine while passing zero traffic, stop trusting the status it reports about itself and look at the layer underneath — here, the physical channel it was clinging to had moved out from under it.
Second, the design one: the fancy features of a band are only worth the fragility they add. DFS channels get you extra clean spectrum, and in exchange every device has to gracefully survive a sudden eviction — and the cheapest device on your network sets the real reliability floor. I don't have so much WiFi congestion that I needed those channels. Trading them away for a band that never disappears was the whole fix, and the boring lower channels have been silent ever since.
Comments