Summary
Two Xiaomi routers. OpenWrt on both. Same SSID broadcasting on both floors. And yet devices upstairs would barely connect, or stubbornly cling to the downstairs router from two floors away.
This post explains exactly what was wrong, how I diagnosed it, and the three fixes I applied to get reliable multi-floor WiFi without buying mesh hardware.
The Setup
- Router 1 (Primary): downstairs, connected to the ISP modem
- Router 2 (Secondary): upstairs, connected to the primary via ethernet backhaul (cable plugged into the secondary’s WAN port)
- Both running OpenWrt 22.03.3
- Both broadcasting the same SSID on 2.4 GHz and 5 GHz
The intention was mesh networking, but something was preventing devices upstairs from connecting reliably.
Diagnosis: What Was Actually Happening
The first thing I discovered: this was not a real mesh.
Both routers had a wifinet2 interface configured as an 802.11s faith-mesh interface — but it was disabled '1' on both routers. What I actually had was two independent access points broadcasting the same SSID, connected by ethernet. That is a valid and common setup (it is sometimes called a “dumb AP” or “roaming AP” setup), but it means clients decide for themselves when to switch routers. No forced handover, no band steering.
That is fine in principle. The real problem was something else entirely.
Problem 1: WAN port bridged into LAN on the secondary
To diagnose, I ran this on each router via SSH:
echo "=== HOSTNAME ===" && hostname && \
echo "=== BRIDGE PORTS ===" && brctl show br-lan && \
echo "=== WIRELESS CONFIG ===" && cat /etc/config/wireless && \
echo "=== NETWORK CONFIG ===" && cat /etc/config/network
The bridge output revealed the core issue immediately:
| Router | br-lan ports |
|---|---|
| Primary | lan1, lan2, wlan0, wlan1 ✓ |
| Secondary | lan1, lan2, wan, wlan0, wlan1 ✗ |
The secondary’s WAN port was included in the LAN bridge. Because I was using the WAN port for the ethernet backhaul (the cable connecting the two floors runs through the WAN port), the secondary was bridging WAN traffic directly into its LAN. This caused DHCP timing issues: devices connecting to the secondary would not reliably get an IP address from the primary’s DHCP server. No IP → no connection.
Problem 2: Missing 802.11r on the secondary’s 2.4 GHz radio
The primary had ieee80211r (Fast BSS Transition) enabled on both radios. The secondary had it on 5 GHz but not on 2.4 GHz (wifinet4). Without 802.11r, clients roaming between floors on 2.4 GHz have to do a full re-authentication, which can take several seconds — long enough for apps to drop connections.
Problem 3: Overlapping 2.4 GHz channel
The secondary was set to channel 10. Channel 10 overlaps with both channel 6 and channel 11, the two non-overlapping options in that range. The primary was set to auto (which picked a non-overlapping channel). The overlap added noise and reduced reliability.
The Fixes
Fix 1: Move the backhaul cable from WAN to LAN
The simplest fix: physically re-plug the ethernet backhaul cable from the secondary’s WAN port into one of its LAN ports (lan1 or lan2).
The WAN port on a router is just a regular ethernet port with a different label. Since the secondary is acting purely as an access point (not a router), there is no reason to use the WAN port specifically. Moving the cable to a LAN port means it is already in the bridge — no configuration changes needed.
Why not just fix the bridge config? You can, but moving the cable is cleaner and avoids needing to disable the WAN DHCP client to prevent the secondary from trying to acquire its own WAN IP.
After this fix, the secondary immediately started working correctly. Devices upstairs got DHCP leases reliably.
Fix 2: Enable 802.11r on the secondary’s 2.4 GHz AP
SSH into the secondary and run:
uci set wireless.wifinet4.ieee80211r='1'
uci set wireless.wifinet4.mobility_domain='1234'
uci set wireless.wifinet4.ft_over_ds='0'
uci set wireless.wifinet4.ft_psk_generate_local='1'
uci commit wireless
wifi reload
The mobility_domain must match between both routers (use the same value on both). ft_over_ds='0' selects FT over the air (more compatible), and ft_psk_generate_local='1' allows PSK-based fast transitions without a separate authentication server.
Fix 3: Set a non-overlapping 2.4 GHz channel
uci set wireless.radio0.channel='6'
uci commit wireless
wifi reload
Use channel 1, 6, or 11 — these are the only non-overlapping channels in the 2.4 GHz band. If the primary is on 1 or 11, use 6 on the secondary to minimize interference.
Verifying the Fix
After applying all three fixes, I ran a full health check on both routers:
echo "=== HOSTNAME ===" && cat /proc/sys/kernel/hostname && \
echo "=== BRIDGE PORTS ===" && brctl show br-lan && \
echo "=== 802.11r CHECK ===" && uci show wireless | grep -E "ieee80211r|mobility_domain|ft_" && \
echo "=== CHANNEL CHECK ===" && uci show wireless | grep -E "channel|band|htmode" && \
echo "=== DHCP LEASES ===" && cat /tmp/dhcp.leases 2>/dev/null && \
echo "=== PING GATEWAY ===" && ping -c 3 -W 1 192.168.1.1
What to confirm:
- Bridge ports on secondary:
lan1,lan2,wlan0,wlan1— nowan - 802.11r: present on all four radio interfaces (2.4 GHz and 5 GHz on both routers), same
mobility_domain - Channels: non-overlapping between primary and secondary
- DHCP leases: only the primary should show leases (it is the only DHCP server)
- Gateway ping: secondary can reach 192.168.1.1 (primary)
What Did Not Change
I deliberately did not enable the 802.11s mesh interface. The two-AP-same-SSID setup works well with ethernet backhaul and 802.11r for roaming. 802.11s mesh would add complexity and is unnecessary when a wired backhaul is available.
I also left the MAC block (AC:F1:08:45:93:0E) unchanged — it was consistent on both routers and intentional.
Summary
| Issue | Root Cause | Fix |
|---|---|---|
| Devices upstairs not getting IPs | WAN port bridged into LAN on secondary | Move backhaul cable to a LAN port |
| Slow roaming on 2.4 GHz | Missing 802.11r on secondary | uci set + wifi reload |
| RF interference | Channel 10 (overlapping) on secondary | Set to channel 6 |
Three small changes. No new hardware. Both floors now work reliably, and devices roam smoothly between floors when signal drops.
If you have a similar setup — two OpenWrt routers with ethernet backhaul and the same SSID — check your bridge configuration first. The WAN-in-LAN-bridge issue is subtle, easy to miss, and accounts for most of the “upstairs devices won’t connect” complaints I have seen.
