The ‘Good Enough’ Trap: Why Home Roaming Problems Hide in Plain Sight
Roaming was a deliberate deferral. After deploying Cudy AX3000 access points running OpenWRT, the decision to wave off roaming as “good enough” felt reasonable at the time. The network worked. Devices connected. Nobody complained. That judgment held for a few months — then it didn’t.
The trouble with roaming problems is that they don’t announce themselves. A phone that clings to a distant access point at -78 dBm when a closer one sits at -58 dBm still shows full signal bars. Video calls stutter occasionally. A smart speaker hesitates before responding. The symptoms look like isolated glitches, not a systemic handoff failure, so they get dismissed and forgotten rather than traced to a root cause.
What made diagnosis slower in this case was that two changes happened simultaneously: the 5GHz band got upgraded, and the physical positions of the access points shifted. Either change alone would have been manageable. Together, they created dead zones that hadn’t existed under the previous layout. A hallway that had acceptable 2.4GHz coverage suddenly sat in a 5GHz gap. A room that roamed cleanly before now straddled two access points with nearly identical signal strength — the worst position a client can be in, because it triggers constant, disruptive reassociation attempts.
The device mix compounded everything. A modern household network carries phones and laptops that understand roaming hints alongside IoT hardware that behaves as though 802.11r fast transition was never ratified. Those legacy devices ignore steering attempts entirely. They associate with the first access point that responds and stay there until the connection collapses. Separating 2.4GHz into a hard-split legacy network addresses part of this, but it doesn’t eliminate the need for actual roaming logic on the 5GHz side.
The gap between “working” and “working well” in a multi-AP home is wide, and it stays invisible until the conditions that expose it finally align. By the time they did here, months of suboptimal handoffs had already accumulated — affecting real usage, just not dramatically enough to force immediate attention. That’s exactly what makes this class of problem easy to defer and hard to diagnose.
The Real-World Device Problem: Legacy IoT and the Band-Splitting Headache
The average home network in 2025 runs devices spanning nearly two decades of Wi-Fi standards. A current iPhone sits on the same SSID as a smart thermostat from 2017, a Wi-Fi-enabled washing machine, and a handful of budget IoT sensors that shipped with 802.11b/g/n support and nothing newer. These devices don’t just occupy different capability tiers — they actively conflict with each other in ways most users never see.
The core problem is roaming asymmetry. Modern smartphones and laptops support 802.11r fast BSS transition, 802.11k neighbor reports, and 802.11v BSS transition management. They hand off between access points cleanly when signal degrades. Legacy IoT devices support none of this. A cheap smart plug or an older security camera will lock onto the first access point it connected to and hold that association until the signal drops below the point of usability — sometimes to -80 dBm or worse — before it considers moving. While it clings to that dying connection, it forces the access point to maintain low data rates to keep the link alive, dragging down the entire BSS and consuming airtime that every other device on that radio shares.
This is the problem a hard 2.4GHz / 5GHz band split is designed to address. By isolating legacy devices onto a dedicated 2.4GHz SSID, you contain the damage. The stubborn IoT devices can cling to weak signals and negotiate at 802.11n rates all they want — that behavior stays confined to a radio that modern devices never touch. The 5GHz band remains clean, populated only by clients that understand the handoff protocols and respond to steering signals.
Mesh Wi-Fi marketing glosses over this entirely. Vendors advertise seamless roaming and self-healing networks, but those claims assume a cooperative device ecosystem. The actual ceiling on roaming performance is set by the least capable, least cooperative device on the network. A single legacy client that refuses to disassociate from a distant access point creates congestion that degrades throughput for every other device on that radio. Fixing roaming means solving for that device — not just optimizing for the flagship phone in your pocket.
Why OpenWRT Changes the Equation — and What It Demands From You
OpenWRT transforms hardware like the Cudy AX3000 from a sealed appliance into a configurable radio platform. Where consumer firmware makes a single automated decision about when a client should roam, OpenWRT exposes every parameter that drives that decision — signal thresholds, band steering aggressiveness, neighbor report behavior, fast transition timing. That granularity is the point. It is also the problem.
Getting OpenWRT running on an access point takes an afternoon. Getting roaming right takes considerably longer, because the protocols involved — 802.11r for fast BSS transition, 802.11k for neighbor reports, 802.11v for BSS transition management — are not self-explanatory, and their interactions are not forgiving. Enabling 802.11r without correctly configuring the mobility domain identifier across all access points breaks handoff entirely for some clients. Enabling 802.11k without a working neighbor report list means clients receive guidance toward access points that haven’t been properly registered, and simply ignore it.
The daemon that ties this together on OpenWRT is usteer, a userspace steering daemon that monitors client signal levels and pushes disassociation requests when a better access point exists. But usteer requires tuning: the default thresholds are conservative, and a network with mixed 2.4GHz legacy devices and modern 5GHz clients needs different steering logic for each band. That means separate configuration blocks, tested against actual device behavior, revised when a phone that roams cleanly turns out to be a tablet that refuses to move at all.
This is the gap that stops most self-hosters. Installing OpenWRT is a defined task with a finish line. Configuring roaming has no finish line — only progressively better behavior validated by walking through your own house watching signal logs. The difference between a working OpenWRT mesh and an optimized one is measured in hours of reading hostapd debug output, cross-referencing client association logs, and adjusting a threshold by three decibels to see what changes.
Consumer firmware automates all of this, badly, invisibly. OpenWRT refuses to hide it. That refusal is exactly why it produces better results when someone actually does the work.
What Coverage Gets Wrong: Roaming Is a Client-Side Problem as Much as an AP Problem
Most guides treat Wi-Fi roaming as an access point problem. Tune your transmit power, space your APs correctly, configure the same SSID and BSSID across nodes — done. The reality is more frustrating: the client device decides when to roam, not the AP. An access point can whisper suggestions, but it cannot force a handoff. The 802.11 standard hands that authority entirely to the client, and different devices interpret it wildly differently.
This asymmetry breaks the promise of a well-configured mesh. A modern Android phone running a recent stack might roam cleanly every time. A three-year-old smart bulb or a budget IoT sensor will often lock onto the first AP it ever connected to and refuse to let go, even when that AP is two floors away and the signal has degraded to the point where throughput collapses. The AP sees a weak, struggling client. The client sees a technically valid connection and stays put.
The 802.11k and 802.11v standards exist precisely to narrow this gap. 802.11k lets an AP send a neighbor report — a map of nearby APs the client could roam to, including their signal characteristics. 802.11v includes BSS Transition Management, which lets an AP send a transition request essentially telling a client “you should move to this AP now.” Neither standard forces a roam. A compliant client is expected to act on the recommendation; a non-compliant or stubborn client ignores it entirely.
OpenWRT’s usteer daemon adds another layer by monitoring connected client signal levels and actively steering clients that fall below configurable thresholds — either by sending BSS Transition Management requests or, as a harder backstop, by kicking the client off the current AP so it has no choice but to reassociate somewhere better. Getting these thresholds right matters. Set the signal floor too high and you’ll disrupt clients that are connecting fine. Set it too low and sticky clients keep degrading the AP’s airtime before usteer intervenes.
The practical challenge is that most home network documentation skips the threshold math entirely and treats 802.11k/v as a checkbox. Enabling the features is straightforward in OpenWRT. Tuning them for a house full of mixed devices — phones, laptops, and decade-old IoT hardware that predates these standards — is where the real work happens.
The Broader Lesson: Home Infrastructure Needs the Same Iterative Thinking as Software
The author’s return visit to a roaming configuration declared “good enough” months earlier is not an admission of failure — it’s the correct workflow. Ship, observe in production, iterate. Software engineers accept this cycle as standard practice. Home network builders largely do not, treating a working setup on day one as a closed ticket. That mismatch is exactly where silent performance degradation hides.
The problem is about to get significantly more common. Wi-Fi 6 hardware has crossed the affordability threshold — the Cudy AX3000 is a concrete example of capable AX-class gear available to non-specialist buyers. More households will run multi-access-point setups with 802.11r, 802.11k, and 802.11v support baked into the chipset, and most of those households will misconfigure roaming, or skip it entirely, and never know what they’re missing. A phone clinging to a distant access point at -75 dBm while a closer node sits idle doesn’t throw an error. It just makes video calls worse.
OpenWRT directly addresses this with tools like usteer for active client steering and hostapd-level neighbor report configuration for 802.11k — but finding that information requires navigating community wikis, forum threads, and package documentation that the mainstream tech press has never systematically covered. Router review sites benchmark throughput in ideal conditions. They do not test what happens when a tablet walks from the kitchen to the back bedroom. OpenWRT’s open-source model means every fix, workaround, and configuration quirk gets documented somewhere by the person who figured it out — but discoverability is a genuine barrier that goodwill alone does not solve.
The iterative mindset closes that gap more than any single configuration change. Log client association events. Check which devices are sticking to weak signals. Adjust usteer thresholds. Revisit after a firmware update changes hostapd behavior. Home infrastructure maintained like production software surfaces problems before they become permanent background noise. Home infrastructure treated as a one-time install accumulates them silently for years.
