LuCI inaccessible : IP, port, DHCP et récupération par la console

Résultat attendu

Déterminer si le problème vient du lien physique, de l’adresse du client, de l’IP de gestion, du service HTTP ou de SSH/pare-feu.
Savoir si LuCI écoute réellement, sans modifier la configuration.
Récupérer l’accès avec une adresse statique côté client, la console ou le mode failsafe, plutôt qu’une réinitialisation d’usine à l’aveugle.
Savoir quand s’arrêter, sauvegarder ou consulter la documentation de l’appareil.

Tableau de diagnostic

Symptôme	À vérifier d’abord	À ne pas faire d’abord
Aucune LED de lien	câble, port LAN, alimentation	reflasher le firmware
Le client a une adresse 169.254.x.x	DHCP/câble/port LAN	changer le LAN du routeur
Le ping fonctionne, pas le web	80/443, uhttpd, pare-feu, HTTPS	réinitialisation d’usine
Le ping échoue	sous-réseau du client, IP de gestion, VLAN/port	continuer à changer d’IP
SSH fonctionne, pas LuCI	uhttpd/paquet LuCI/port	modifier la configuration réseau
Aucune sortie sur la console	paramètres série, sortie vidéo, alimentation	court-circuiter des broches ou reflasher à l’aveugle

Couche 1 : port physique et lien

OrdinateurUtilisez un port LAN, pas le WAN

Branchez-vous sur un port marqué LAN ; le port WAN ne donne généralement pas accès à la gestion. Essayez un autre câble et un autre port LAN ; vérifiez les LED et l’état de la carte réseau du client.

Si la LED ne s’allume jamais, vérifiez l’alimentation, le câble et le port avant de toucher au firmware.

AttenduLa LED LAN est allumée et le client détecte un lien.

Couche 2 : adresse du client et passerelle

OrdinateurVérifiez que le client est dans le sous-réseau LAN

Linux :

ip addr show
ip route

Windows :

ipconfig /all

macOS :

ifconfig
netstat -rn

Une adresse 169.254.x.x signifie que le DHCP a échoué. Vérifiez d’abord le câble et le port LAN, puis définissez une adresse statique temporaire :

IP : 192.168.1.2
Masque : 255.255.255.0
Passerelle : 192.168.1.1

Utilisez-la uniquement pour vous connecter ; évitez tout conflit avec l’adresse LAN du routeur.

AttenduLe client a 192.168.1.x ou une autre adresse LAN connue.

OrdinateurFaites un ping vers la passerelle

ping 192.168.1.1

Réponse : passez à la couche 3.
Pas de réponse : vérifiez le sous-réseau du client, le port LAN et si l’adresse par défaut a été modifiée.
Ne déclarez pas l’appareil mort sur la seule base d’un ping échoué.

AttenduElle répond, ou vous savez que l'IP de gestion n'est pas 192.168.1.1.

Couche 3 : l’IP de gestion a-t-elle été modifiée ?

OrdinateurTrouvez la véritable adresse LAN

Sources courantes :

l’étiquette de l’appareil ou le manuel ;
une configuration ou une capture d’écran enregistrée ;
la table des baux DHCP du routeur amont, s’il est accessible ;
uci show network sur la console ;
une adresse LAN que vous avez modifiée vous-même.

Sur votre propre sous-réseau, consultez le cache ARP :

ip neigh

Ne scannez pas largement un réseau inconnu et ne devinez pas un appareil à partir des résultats d’un scan.

AttenduVous avez au moins deux adresses candidates et vous les testez.

Couche 4 : HTTP/HTTPS et SSH

OrdinateurDistinguez « le ping fonctionne mais pas le web » d'une panne de lien

curl -v http://192.168.1.1/
curl -k -v https://192.168.1.1/
ssh [email protected]

HTTP et HTTPS expirent tous deux : uhttpd/LuCI n’écoute pas, ou le pare-feu le bloque.
HTTP 404 ou redirection : problème de port, de chemin ou de configuration HTTPS.
SSH fonctionne : diagnostiquez les services via SSH ; ne modifiez pas le LAN.

AttenduVous savez s'il s'agit d'un problème de port, de service ou de protocole.

Shell du routeurSi SSH fonctionne, inspectez uhttpd et les ports

netstat -lnp | grep -E ':80|:443|:22'
ps w | grep -E 'uhttpd|rpcd' | grep -v grep
logread -e uhttpd | tail -30
uci show uhttpd

Si uhttpd ne tourne pas, essayez :

/etc/init.d/uhttpd restart

Si cela échoue encore, lisez les journaux et le pare-feu ; ne redémarrez pas le réseau entier à répétition.

AttenduVous savez si LuCI tourne et si les ports 80/443 écoutent.

Shell du routeurVérifiez si le pare-feu bloque la gestion

uci show firewall
logread | grep -i firewall | tail -20

Si vous venez de modifier une zone du pare-feu, restaurez la sauvegarde ou corrigez-la depuis la console ; ne continuez pas à la modifier sans accès à la console.

AttenduLe trafic du LAN vers les ports 80/443/22 du routeur n'est pas bloqué par erreur.

Couche 5 : console locale / failsafe

Console localeVérifiez depuis la console que le système est actif

Utilisez le port série, HDMI/clavier, IPMI ou une console cloud. Le port série est souvent en 115200 8N1, mais vérifiez pour votre appareil. S’il n’y a aucune sortie, vérifiez d’abord le câble, la vitesse en bauds et l’alimentation.

Une fois connecté :

ip addr show
ip route
uci show network
uci show dhcp
logread | tail -50

AttenduVous voyez une invite de connexion ou le journal du noyau.

Console localeN'utilisez le failsafe qu'en cas de besoin

Le moment où appuyer sur le bouton failsafe dépend de l’appareil ; suivez la page OpenWrt de l’appareil ou le manuel du constructeur. Une fois connecté, commencez par inspecter :

uci show network
uci show dhcp

Si seule l’adresse LAN est incorrecte, remettez-la en place et redémarrez après vérification. En cas de doute, enregistrez ou sauvegardez d’abord la configuration ; n’exécutez pas firstboot. Une réinitialisation d’usine efface la configuration.

AttenduVous pouvez restaurer le LAN/DHCP sans réinitialisation d'usine.

Ordre de récupération

Ne modifiez rien : câble, port LAN, adresse statique côté client.
Le ping fonctionne, pas le web : uhttpd, pare-feu, HTTPS.
SSH fonctionne : diagnostiquez les services via SSH ; ne modifiez pas le LAN.
Pas de SSH : console ou failsafe.
Réinitialisation d’usine en dernier recours : assurez-vous qu’aucune configuration importante n’est perdue sans sauvegarde, et sachez que vous devrez reconfigurer WAN, LAN et Wi-Fi.

Erreurs de diagnostic courantes

Utiliser le port WAN pour la gestion.
Le client a encore un ancien sous-réseau ou une ancienne IP statique.
Le navigateur force HTTPS alors que LuCI est en HTTP.
Croire que LuCI fonctionne parce que le ping répond.
Changer l’adresse LAN sans mettre à jour le DHCP et la passerelle.
Une règle du pare-feu bloque la gestion depuis le LAN.
uhttpd est absent ou a été supprimé, mais le réseau est redémarré à répétition.

Essai en laboratoire E2 (2026-10-20)

Environnement : VM x86 200 sous OpenWrt 25.12.6 ; LAN 192.168.1.2 ; HTTP testé depuis l’hôte PVE.
/etc/init.d/uhttpd stop : curl vers http://192.168.1.2/ a renvoyé http=000 (échec de connexion) ; SSH est resté disponible.
/etc/init.d/uhttpd start : HTTP a renvoyé 200.
Non testé : blocage par le pare-feu, changement de port d’uhttpd, paquet LuCI manquant, vraie séquence de touches série/failsafe.
Recette : tests/recipes/troubleshooting-no-web-ui.md.

Statut E2 et sources

Il s’agit d’un E2 partiel : l’arrêt/la reprise d’uhttpd et le maintien de SSH ont été testés ; le pare-feu, le port et le failsafe restent de la documentation.
Déterminez d’abord s’il s’agit du lien, de l’adresse, d’uhttpd ou du pare-feu ; ne remplacez pas un diagnostic par couches par une réinitialisation d’usine.
Les procédures de console et de failsafe varient selon l’appareil et le firmware ; lisez d’abord la documentation de l’appareil.

Sources

Router.Homes

Notes indépendantes sur OpenWrt. Chaque page précise le firmware, l’appareil, le gestionnaire de paquets et le retour arrière.

Icônes : Solar by 480 Design, CC BY 4.0