Summary
Deux routeurs Xiaomi. OpenWrt sur les deux. Le même SSID diffusé sur les deux étages. Et pourtant, les appareils à l’étage avaient du mal à se connecter, ou s’accrochaient obstinément au routeur du rez-de-chaussée depuis deux étages de distance.
Cet article explique exactement ce qui n’allait pas, comment je l’ai diagnostiqué, et les trois correctifs que j’ai appliqués pour obtenir un WiFi multi-étage fiable sans acheter de matériel mesh.
La configuration
- Routeur 1 (Principal) : au rez-de-chaussée, connecté au modem de l’opérateur
- Routeur 2 (Secondaire) : à l’étage, connecté au principal via backhaul ethernet (câble branché sur le port WAN du secondaire)
- Les deux tournent sous OpenWrt 22.03.3
- Les deux diffusent le même SSID en 2,4 GHz et 5 GHz
L’intention était de faire du réseau mesh, mais quelque chose empêchait les appareils à l’étage de se connecter de façon fiable.
Diagnostic : ce qui se passait vraiment
La première découverte : ce n’était pas un vrai mesh.
Les deux routeurs avaient une interface wifinet2 configurée comme interface 802.11s faith-mesh — mais avec disabled '1' sur les deux. Ce que j’avais en réalité, c’étaient deux points d’accès indépendants diffusant le même SSID, reliés par ethernet. C’est une configuration valide et courante (parfois appelée “dumb AP” ou “roaming AP”), mais cela signifie que les clients décident eux-mêmes quand basculer d’un routeur à l’autre. Pas de transfert forcé, pas de band steering.
Ce n’est pas un problème en soi. Le vrai problème était tout autre.
Problème 1 : le port WAN bridgé dans le LAN sur le secondaire
Pour diagnostiquer, j’ai exécuté ceci sur chaque routeur 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
La sortie du bridge a révélé le problème central immédiatement :
| Routeur | Ports dans br-lan |
|---|---|
| Principal | lan1, lan2, wlan0, wlan1 ✓ |
| Secondaire | lan1, lan2, wan, wlan0, wlan1 ✗ |
Le port WAN du secondaire était inclus dans le bridge LAN. Comme j’utilisais le port WAN pour le backhaul ethernet (le câble qui relie les deux étages passe par le port WAN), le secondaire bridgeait le trafic WAN directement dans son LAN. Cela causait des problèmes de timing DHCP : les appareils qui se connectaient au secondaire n’obtenaient pas de façon fiable une adresse IP du serveur DHCP du principal. Pas d’IP → pas de connexion.
Problème 2 : absence d’802.11r sur la radio 2,4 GHz du secondaire
Le principal avait ieee80211r (Fast BSS Transition) activé sur les deux radios. Le secondaire l’avait sur le 5 GHz, mais pas sur le 2,4 GHz (wifinet4). Sans 802.11r, les clients qui roament entre les étages en 2,4 GHz doivent effectuer une ré-authentification complète, ce qui peut prendre plusieurs secondes — suffisamment pour que des applications perdent leur connexion.
Problème 3 : canal 2,4 GHz en superposition
Le secondaire était réglé sur le canal 10. Le canal 10 se superpose à la fois au canal 6 et au canal 11, les deux options non superposées dans cette plage. Le principal était réglé sur auto (ce qui avait choisi un canal non superposé). Cette superposition ajoutait du bruit et réduisait la fiabilité.
Les correctifs
Correctif 1 : déplacer le câble backhaul du port WAN vers un port LAN
Le correctif le plus simple : rebrancher physiquement le câble backhaul ethernet depuis le port WAN du secondaire vers l’un de ses ports LAN (lan1 ou lan2).
Le port WAN d’un routeur n’est qu’un port ethernet ordinaire avec une étiquette différente. Comme le secondaire agit uniquement comme point d’accès (pas comme routeur), il n’y a aucune raison d’utiliser le port WAN spécifiquement. Déplacer le câble vers un port LAN signifie qu’il est déjà dans le bridge — aucune modification de configuration nécessaire.
Pourquoi ne pas corriger la config du bridge directement ? On peut, mais déplacer le câble est plus propre et évite de devoir désactiver le client DHCP WAN pour empêcher le secondaire d’essayer d’acquérir sa propre adresse IP WAN.
Après ce correctif, le secondaire a immédiatement commencé à fonctionner correctement. Les appareils à l’étage ont obtenu des baux DHCP de façon fiable.
Correctif 2 : activer 802.11r sur l’AP 2,4 GHz du secondaire
Se connecter en SSH sur le secondaire et exécuter :
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
Le mobility_domain doit être identique sur les deux routeurs (utiliser la même valeur sur les deux). ft_over_ds='0' sélectionne FT par voie radio (plus compatible), et ft_psk_generate_local='1' permet des transitions rapides basées sur PSK sans serveur d’authentification séparé.
Correctif 3 : régler un canal 2,4 GHz non superposé
uci set wireless.radio0.channel='6'
uci commit wireless
wifi reload
Utiliser le canal 1, 6 ou 11 — ce sont les seuls canaux non superposés dans la bande 2,4 GHz. Si le principal est sur 1 ou 11, utiliser 6 sur le secondaire pour minimiser les interférences.
Vérification du correctif
Après avoir appliqué les trois correctifs, j’ai effectué un bilan de santé complet sur les deux routeurs :
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
Ce qu’il faut confirmer :
- Ports du bridge sur le secondaire :
lan1,lan2,wlan0,wlan1— pas dewan - 802.11r : présent sur les quatre interfaces radio (2,4 GHz et 5 GHz sur les deux routeurs), même
mobility_domain - Canaux : non superposés entre le principal et le secondaire
- Baux DHCP : seul le principal devrait afficher des baux (c’est le seul serveur DHCP)
- Ping de la passerelle : le secondaire peut atteindre 192.168.1.1 (le principal)
Ce qui n’a pas changé
Je n’ai délibérément pas activé l’interface mesh 802.11s. La configuration avec deux AP sur le même SSID fonctionne bien avec un backhaul ethernet et 802.11r pour le roaming. Le mesh 802.11s ajouterait de la complexité et est inutile quand un backhaul câblé est disponible.
J’ai également laissé le bloc MAC (AC:F1:08:45:93:0E) inchangé — il était cohérent sur les deux routeurs et intentionnel.
Résumé
| Problème | Cause racine | Correctif |
|---|---|---|
| Les appareils à l’étage n’obtiennent pas d’IP | Port WAN bridgé dans le LAN sur le secondaire | Déplacer le câble backhaul vers un port LAN |
| Roaming lent en 2,4 GHz | 802.11r absent sur le secondaire | uci set + wifi reload |
| Interférences RF | Canal 10 (superposé) sur le secondaire | Régler sur le canal 6 |
Trois petits changements. Pas de nouveau matériel. Les deux étages fonctionnent désormais de façon fiable, et les appareils roament sans problème entre les étages quand le signal baisse.
Si vous avez une configuration similaire — deux routeurs OpenWrt avec backhaul ethernet et le même SSID — vérifiez d’abord votre configuration de bridge. Le problème WAN-dans-le-bridge-LAN est subtil, facile à manquer, et explique la plupart des plaintes “les appareils à l’étage ne se connectent pas” que j’ai vus.
