u/sh2sg

I have a 3-node eero Max 7 mesh using wireless backhaul, running in bridge mode. The main node in Living room is wired to my ISP router, while the other 2 nodes use wireless backhaul. My devices are all Apple decides, M3 MacBook Pro and iPhone 17 Pro etc.

For quite a while I noticed somewhat strange band-selection behavior: when my MacBook was close to the main eero, it would initially connect to 6 GHz, but shortly afterwards switch to 5 GHz.

At first this looked wrong, since the 6 GHz signal was as strong as or stronger than 5 GHz. However, after macOS added support for 160 MHz channel width on 5 GHz, the result was actually pretty good. The Mac would connect to 5 GHz @ 160 MHz and throughput (14xx Mbps) was as good as, and sometimes better than, 6 GHz @ 160 MHz (13xx Mbps).

In hindsight, this actually made some sense in my setup.

Because the 2 leaf eeros use wireless backhaul, the main node is the aggregation point for that traffic. Its 6 GHz radio naturally tends to show higher utilization than the leaf nodes. So even though the Mac had an excellent 6 GHz signal near the main node, 5 GHz @ 160 MHz could sometimes provide better real-world throughput simply because that band had more available airtime.

With eeroOS 7.15.1, this was basically the behavior I was seeing. The band selection looked a little strange, but performance was excellent, so I didn't really consider it a problem.

After the next 2 eero firmware upgrades, however, the behavior completely changed.

The Mac no longer switches to 5 GHz. It now stays on 6 GHz, but has developed a very strong preference for one particular leaf node, regardless of where the Mac physically is.

For example, when the MacBook is literally right in front of the main eero, Wi-Fi Explorer shows roughly:

• main 6 GHz: 95% signal, 60 dB SNR, ~32% channel utilization
• leaf 6 GHz: 67% signal, 33 dB SNR, ~9% channel utilization

Yet the Mac associates with the leaf node.

If I force it back onto the main node by toggling Wi-Fi/reconnecting, it may initially connect to it, but within mins it moves back to leaf node again.

If I physically take the MacBook next to the leaf eero node, it stays on leaf node, which obviously makes sense there. The strange part is that when I move back next to main node, it continues preferring leaf node even though main node has a dramatically stronger signal.

The utilization difference itself isn't surprising to me. I expect the main node to have higher 6 GHz utilization because it has to handle the wireless mesh/backhaul traffic from the leaf nodes. That's normal for this topology.

What doesn't make sense is if AP selection is now heavily influenced by that utilization number.

A leaf node having only 9% utilization doesn't necessarily make it a better connection for a client sitting right beside the main node. In my example, macOS is apparently willing to give up a 60 dB SNR connection for a 33 dB SNR connection. Whatever airtime advantage the leaf has, that seems like a very strange tradeoff.

In other words, using channel utilization to help choose between 5 GHz and 6 GHz on the same nearby node can make sense — and that's arguably why the old 5 GHz @ 160 MHz behavior worked so well.

But using the lower utilization of a physically distant mesh node to outweigh a vastly better RF connection to the nearby node does not seem sensible.

I have already tried:

• Restarting/power-cycling the entire eero network
• Powering nodes off and bringing them back one at a time
• Forgetting and rejoining the Wi-Fi network on both Mac and iPhone
• Enabling and disabling Client Steering

None of these made any difference.

What's particularly interesting is that this changed after the recent eeroOS updates. The Mac, macOS version, physical eero topology and node locations haven't changed.

So the behavior has basically gone from:

7.15.1:

Main 6 GHz → Main 5 GHz @ 160 MHz

(strange-looking choice, but excellent performance and arguably rational because 5 GHz was less busy)

to:

Current firmware:

Main 6 GHz → distant Leaf 6 GHz

(ignores a much stronger nearby main node and becomes extremely sticky to one particular node)

I'm wondering whether something changed in eero's roaming/BSS-load/steering behavior and Apple devices are now giving the reported AP/channel utilization too much weight when selecting a BSSID.

Has anyone else noticed much stickier or irrational node selection after the recent eeroOS updates, particularly with Apple devices?

I'm especially interested if anyone has been able to confirm this by having eero Support temporarily roll the network back to 7.15.1 or another older firmware.