Mesh Wi-Fi roaming problems: why devices stick to the wrong node

The short version

• Your phone or laptop decides when to roam, not the mesh. Apple says devices "are responsible for maintaining their 802.11 connection", including when to move to another access point. A mesh system can suggest a move; it can't make one.
• Devices wait until the signal is already mediocre. An iPhone doesn't look for another node until its current one falls to about −70 dBm, and then wants one at least 8 dB stronger (12 dB if it's idle). A Mac waits until −75 dBm. Android's defaults skip the system's own scans while a 5 or 6 GHz connection stays above −70 dBm and was checked recently. Ubiquiti gives −70 dBm as the minimum for a stable connection, so a "sticky" phone is working as designed, right at the edge.
• 802.11k, v and r make roaming faster and better informed, but the device still has the last word. 802.11k hands the device a list of nearby nodes, 802.11v lets the network suggest one, and 802.11r shortens the handoff. The device can ignore all of them, and 802.11r can stop some older devices connecting at all.
• Fix it in this order: confirm it's roaming with the walk test, leave the maker's steering features on (eero Client Steering, Deco Mesh Technology, UniFi BSS Transition), move nodes so a strong one is waiting where you walk, try 802.11r if your devices cope, adjust a sticky laptop's own roaming setting, exclude stationary devices from steering, and use "kick" features such as Minimum RSSI last. Wire the backhaul of the node you roam to, so moving to it is worth it.

Our guide to why mesh doesn't fix every slow room introduces sticky clients and the quickest check: turn the device's Wi-Fi off and on, and if it gets faster, it was clinging to a far node. This article goes further: the rules each platform uses, a symptom table, the roaming settings each maker documents, and a repeatable test.

Who decides when a device roams

Every mesh node broadcasts the same network name, but each radio has its own hardware address, the BSSID. Moving from one BSSID to another is a roam, and the device starts it. Apple's deployment guide is explicit: "Devices connected to a Wi-Fi network are responsible for maintaining their 802.11 connection. One portion of this connection relationship is deciding when to roam." Intel says the same about its laptop adapters: roaming "is based on signal quality rather than distance to an AP/router", and "if the signal quality to an AP/router that is further away remains good the client may not roam to a nearer AP/router, or may not roam immediately." Intel says that in most cases this is "normal and expected": the behavior is designed "to increase the efficiency of the Wi-Fi network by minimizing unnecessary data traffic" and "aids in conserving battery power consumption".

The makers agree from the other side. eero says some devices "may have a stronger wireless connection to an eero farther away" because "different devices have different thresholds for when to roam between eeros". A TP-Link staff guide on Deco roaming puts it in one line: "Whether to roam is decided by clients and Deco just gives a roaming advice."

The thresholds each platform documents

Apple publishes exact numbers. Android publishes its framework defaults, which phone makers can change. Microsoft and Intel describe the mechanism but not the dBm values. Signal strength is in dBm, a negative number where closer to zero is stronger.

Apple's own example: an iPhone on a voice call whose signal drops to −75 dBm "searches for roam candidate BSSIDs that have an RSSI of at least –67 dBm". Ubiquiti says clients "often roam to another AP around -70 to -75 dBm, and usually only when another AP has far greater signal strength."

Two details matter at home. Apple says it also scores candidates on "channel utilization and quantity of associated clients", and prefers Wi-Fi 7 over Wi-Fi 6 and wider channels over narrower ones, so the strongest node doesn't always win. And Android's page says that when the phone's chip supports firmware roaming, a candidate with the same network name and security type counts as a match for the connected network, and "no further action is taken". RouterHaus's reading: on such phones, moves between your mesh nodes are left to the chip.

What that means for a walk between two nodes

RouterHaus's arithmetic from Apple's numbers, for an iPhone on a call (sending data) as you walk from node A toward node B:

1. The phone doesn't scan for node B until node A reads −70 dBm or weaker (Apple: the device "scans for roam candidate BSSIDs" after it crosses the trigger).
2. At that moment, node B must read at least −62 dBm (−70 + 8) for the phone to move. Idle in a pocket, it needs −58 dBm (−70 + 12).
3. A Mac at its −75 dBm trigger needs node B at −63 dBm or better.

So a smooth handoff needs a spot on your route where the old node is weak and the new one is already strong. If both nodes read around −72 dBm in the hallway between them, the phone has crossed its trigger but has no candidate 8 dB better, so under Apple's rules it stays where it is while the signal keeps falling. Apple warns about exactly this in network design: with cells that overlap at −67 dBm, an iPhone "keeps its connection to the BSSID longer than expected" because its trigger is −70 dBm.

Set that against Ubiquiti's figures (−70 dBm minimum for a stable connection, −65 dBm recommended) and a phone obeying Apple's rule spends its last minutes on the far node at the very edge of what Ubiquiti calls stable.

Symptom, cause, fix

Most roaming complaints fit one of these rows. The "How to check" column uses the tests in the walk test below.

802.11k, v and r: what each one actually does

All three are IEEE amendments to the 802.11 Wi-Fi standard, published in 2008 (k and r) and 2011 (v). Both ends must support a feature for it to work: Microsoft says the Wi-Fi driver must support them and "All three features need AP-side support".

Apple says iPhone, iPad and Macs with Apple silicon can support all three, while Intel-based Macs "don't support Fast BSS Transition, but they interoperate" with networks that use it. Apple adds that, depending on the Wi-Fi vendor, 802.11r "can work with both pre-shared key (PSK) and 802.1X authentication", so it isn't limited to enterprise networks on Apple devices. Microsoft's page covers Windows 10 only and says PSK and open networks "aren't supported"; we found no equivalent statement for Windows 11.

The Wi-Fi Alliance packages similar ideas into two certification programs, Wi-Fi Agile Multiband (access point, band and channel selection) and Wi-Fi Optimized Connectivity, which it says "improves mobility and allows users to experience more consistent connections while roaming within and across networks". RouterHaus didn't check which home mesh products carry either certification.

The roaming settings each maker documents

This is what each maker's support documentation says you can change, checked November 7, 2026. "Not documented" means RouterHaus didn't find it in the maker's support pages and manuals for that system; it isn't proof the setting is absent from the app.

eero, Nest and Orbi keep roaming automatic, Deco and ASUS expose a few switches, and UniFi exposes nearly everything: more ways to fix a problem, and more ways to create one.

Two maker tools are aimed at devices that don't move. TP-Link suggests turning off Mesh Technology for devices you don't want roaming; after that, "roaming can only be initiated by the clients themselves". ASUS's Roaming Block List does the same for AiMesh, with the note that a listed device "will do self roaming to a better mesh node" anyway.

Settings on the device side

RouterHaus found no roaming setting for iPhone, iPad or Mac in Apple's documentation, and Android's page describes defaults that phone makers configure, not user controls. Windows laptops are the exception, through the Wi-Fi adapter's driver.

On Intel adapters, Intel's steps for Windows 10 are: right-click Start, choose Device Manager, expand Network adapters, right-click the wireless adapter, choose Properties and open the Advanced tab. Intel's articles on these settings sit in its legacy-products section and list older Centrino-era adapters; Dell's current guide for its laptops (updated May 2026) lists the same Roaming Aggressiveness and Preferred Band properties on Intel adapters, with the caveat that some options "may not be available" depending on the adapter, driver and Windows version. Three settings there bear on roaming:

• Roaming aggressiveness "alters the signal strength threshold at which the WiFi adapter starts scanning for another candidate AP". Lowest waits until the signal is "very low"; Highest scans "when the signal strength with the current AP is still good". Medium is the default and Intel's recommended value, and Intel says to go back to Medium if another value doesn't help. RouterHaus's suggestion for a laptop that clings to a far node as you carry it around: try Medium-High before Highest, one step at a time. Dell's advice points the other way for a laptop that stays on a desk: Lowest or Medium-Low, "to prevent connection lag and drops".
• Preferred band (No Preference by default, or prefer 2.4 or 5 GHz). Intel describes it as a way to reduce interference; RouterHaus's suggestion is that preferring 5 GHz may also keep a laptop off a far node's 2.4 GHz band.
• Transmit power: Intel's ideal is the lowest level "still compatible with communication quality", to limit interference in crowded places, but it warns that lowering it reduces "the radio coverage". Don't lower it on a laptop that already struggles at the edge of a node.

Other adapter brands use their own names, and Microsoft notes that 802.11k, v and r work on Windows only when "the WLAN radio driver" supports them, so a driver update from the laptop maker is worth checking before anything else.

Node placement and transmit power

Because devices roam on signal strength, where you put a node decides where a device leaves the previous one. The makers' general placement rules are in our placement table. For roaming, add three checks:

1. Walk the routes you use on calls. From the handoff arithmetic, an iPhone on a call needs a point on that route where the old node has dropped to −70 dBm and the new one is at −62 dBm or better. If one stretch, such as a stairwell, has two weak nodes and no strong one, that's where calls fail. Move the nearer node toward that stretch, or wire a node so it can sit there.
2. Measure with the device that has the problem. Apple's network design guide says phones "see different cell boundaries" from laptops, whose antennas are "much larger and more powerful", and that "It's always best to measure using the target device." A laptop survey is a guide; the phone's behavior in the walk test is the answer.
3. Turn power down only where nodes are close. Ubiquiti advises "High Transmission Power on APs, unless they are very close together" for homes, and medium power in dense offices "to prevent them from interfering with one another". RouterHaus's reading of Apple's rules: a node louder than its area needs keeps phones past the point where a nearer node would serve them better, so lowering it can move the handoff point. NETGEAR's Orbi 770 lets you lower 2.4 and 5 GHz power (not 6 GHz); UniFi offers it per radio; we found no documented setting for eero, Deco or Nest.

Adding a node isn't the default fix. If a phone in the office still reads the living room node above −70 dBm, a new office node doesn't change its decision: it only gives it a better candidate once it does look. And every extra wireless hop costs throughput; Ubiquiti recommends at most two. See how many mesh nodes you need before buying one.

Minimum RSSI and other kick features: use with care

Because the network can't move a device, some systems offer the blunt alternative: disconnect it when its signal is weak, so it has to reconnect, ideally to a nearer node.

• UniFi's Minimum RSSI tells an access point to disconnect clients below a set signal level. Ubiquiti warns it "can have implications for general roaming if improperly tuned; some devices may refuse to connect to an AP from which they have been kicked multiple times", and calls it "generally not recommended unless running a high density deployment."
• UniFi's Roaming Assistant (Network 9.2 and later) first uses BSS transition frames to warn clients they will be disconnected. Ubiquiti says this "soft kick" is "tolerated much better by modern clients" and "generally recommended to be set to a value below -70 dBm".
• ASUS's Roaming Assistant disconnects clients when their signal falls below a threshold, −70 dBm by default.

RouterHaus's arithmetic on why these can backfire: ASUS's default −70 dBm is the same level at which an iPhone starts looking for itself, so it adds little for iPhones; and a Mac, whose own trigger is −75 dBm, gets disconnected before it would have chosen to move. If no other node is stronger at that spot, the device may just reconnect to the same node after a gap, which on a call is worse than staying put. Try kick features last, set them weaker than −70 dBm, prefer the soft version where one exists, and turn them off if any device starts dropping.

Why the backhaul still matters

Roaming fixes get a device onto the nearest node; the backhaul decides whether that node is worth being on. A phone that roams correctly to a satellite whose wireless link to the router is weak gets a strong signal and a slow connection. Ubiquiti says "each 'wireless hop' reduces throughput by at least 50%" and calls hardwiring access points "the ideal method to provide the highest performance and stability".

A cable also frees placement. A wireless satellite has to sit where it still hears the router well (Ubiquiti aims for −60 dBm or better between a meshed access point and its parent), usually short of where you need coverage. A wired one can go where the roaming arithmetic says it should: at the stretch where calls fail, or in the room you use. If only one node can be wired, wire the one your devices roam to most. For which kits make that easy, see mesh systems with wired backhaul, and MoCA over TV coax where there's no Ethernet. Some Wi-Fi 7 systems can run the wireless backhaul over multi-link operation: ASUS documents an AiMesh "MLO Backhaul", limited to the first node and to identical models. See Wi-Fi 7 MLO explained.

The walk test: find out what your devices actually do

The test turns "the Wi-Fi is flaky" into a specific row of the symptom table. Change one setting at a time between runs.

What you can read on each device

• Any phone: the mesh app's client list is the dependable check. eero's device page "Shows which eero your device is currently connected to and which wifi frequency it's using (2.4, 5, or 6 GHz)". TP-Link's guide shows Deco clients listed under each unit (tap the Internet icon, then a Deco). UniFi shows each client's signal under Radios > Coverage. iPhones don't show signal strength or band; see how to tell which band an iPhone uses.
• Windows: Microsoft lists netsh wlan show interfaces among its baseline Wi-Fi diagnostics. It reports the current connection; look for the BSSID (the node you're on) and Signal lines, though Microsoft doesn't document the output line by line. netsh wlan show networks mode=bssid, Microsoft says, "adds the BSSID, signal strength, channel, and radio type for each visible network", so you can see every node the laptop hears. After a dropped call, netsh wlan show wlanreport builds a report of "recent wireless sessions, disconnect reasons" and related events.
• Mac: hold Option and click Wi-Fi in the menu bar or Control Center. Apple's Mac User Guide says this menu shows details "such as the IP address, router address, channel, frequency (or band), security standard, and 802.11 protocol", and that it holds Open Wireless Diagnostics; Apple's list doesn't include the BSSID or signal strength. If your Mac shows them there, use them as a convenience and confirm with the mesh app's client list.

The steps

1. Pick a route you actually walk while on calls, from the room with one node to the room with another. Note where each node sits and where calls tend to fail.
2. Start at node A. Confirm in the client list (or with netsh on a laptop) that the device is on node A, and note the signal.
3. Start something continuous: a voice or video call, or on a laptop a continuous ping to the router (ping -t followed by the router's address on Windows; Microsoft's reference writes the switch as /t and says it keeps pinging "until interrupted").
4. Walk slowly to node B's room and stand there for a minute. Note any freeze, its length, and where it happened.
5. Check which node the device is on now. On a laptop, note the BSSID and signal of both nodes.
6. Turn the device's Wi-Fi off and on in node B's room and check again.
7. Walk back and repeat with the device idle (screen off, no call). Apple's 12 dB idle rule and Android's screen-off firmware roaming mean idle and busy behavior can differ.