No se puede acceder a LuCI: IP, puerto, DHCP y recuperación por consola

E2Reproducido en una VM de laboratorio

Entorno aplicableProbado

Firmware

OpenWrt

Versión

25.12.6

Gestor de paquetes

apk

Equipo

OpenWrt 25.12.6 x86 VM 200

Registro de pruebas

Resultado

• Distinguirás si el problema está en el enlace físico, la dirección del cliente, la IP de administración, el servicio HTTP o SSH/cortafuegos.
• Decidirás si LuCI realmente está escuchando sin cambiar la configuración.
• Te recuperarás con una dirección estática en el cliente, la consola o failsafe en lugar de un restablecimiento de fábrica a ciegas.
• Sabrás cuándo parar, hacer una copia de seguridad o leer la documentación del dispositivo.

Tabla de triaje

Síntoma	Comprueba primero	No hagas primero
Sin LED de enlace	cable, puerto LAN, alimentación	reinstalar el firmware
El cliente tiene 169.254.x.x	DHCP/cable/puerto LAN	cambiar la LAN del router
El ping funciona, la web no	80/443, uhttpd, cortafuegos, HTTPS	restablecimiento de fábrica
El ping falla	subred del cliente, IP de administración, VLAN/puerto	seguir cambiando IP
SSH funciona, LuCI no	uhttpd/paquete LuCI/puerto	cambiar la configuración de red
Sin salida por consola	ajustes serie, salida de vídeo, alimentación	cortocircuitar pines/reinstalar a ciegas

Capa 1: puerto físico y enlace

OrdenadorUsa un puerto LAN, no WAN

Conéctate a un puerto con la etiqueta LAN; el puerto WAN normalmente no ofrece acceso de administración. Prueba otro cable y otro puerto LAN; revisa los LED y el estado de la tarjeta de red del cliente.

Si el LED nunca se enciende: revisa la alimentación, el cable y el puerto antes de tocar el firmware.

EsperadoEl LED de LAN está encendido y el cliente detecta un enlace.

Capa 2: dirección del cliente y puerta de enlace

OrdenadorConfirma que el cliente está en la subred LAN

Linux:

ip addr show
ip route

Windows:

ipconfig /all

macOS:

ifconfig
netstat -rn

Una dirección 169.254.x.x significa que DHCP falló. Confirma primero el cable y la LAN, y luego establece una dirección estática temporal:

• IP: 192.168.1.2
• Máscara: 255.255.255.0
• Puerta de enlace: 192.168.1.1

Úsala solo para acceder; no colisiones con la dirección LAN del router.

EsperadoEl cliente tiene 192.168.1.x u otra dirección LAN conocida.

OrdenadorHaz ping a la puerta de enlace

ping 192.168.1.1

• Responde: pasa a la capa 3.
• No responde: revisa la subred del cliente, el puerto LAN y si se cambió la dirección predeterminada.
• No des el dispositivo por muerto solo porque falla un ping.

EsperadoResponde, o sabes que la IP de administración no es 192.168.1.1.

Capa 3: ¿se cambió la IP de administración?

OrdenadorEncuentra la dirección LAN real

Fuentes habituales:

• la etiqueta o el manual del dispositivo;
• una configuración o captura de pantalla guardada;
• la tabla de asignaciones DHCP del router de origen, si es accesible;
• uci show network en la consola;
• una dirección LAN que cambiaste tú mismo.

En tu propia subred, inspecciona la caché ARP:

ip neigh

No escanees ampliamente una red desconocida, y no identifiques un dispositivo a partir de los resultados de un escaneo.

EsperadoTienes al menos dos direcciones candidatas y las pruebas.

Capa 4: HTTP/HTTPS y SSH

OrdenadorSepara “el ping funciona pero la web falla” de un fallo de enlace

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

• HTTP y HTTPS agotan el tiempo: uhttpd/LuCI no está escuchando, o el cortafuegos lo bloquea.
• HTTP 404/redirección: puerto/ruta/configuración de HTTPS.
• SSH funciona: depura los servicios por SSH; no cambies la LAN.

EsperadoSabes si es un problema de puerto, servicio o protocolo.

Shell del routerSi SSH funciona, inspecciona uhttpd y los puertos

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 no se está ejecutando, prueba:

/etc/init.d/uhttpd restart

Si sigue fallando, lee los registros y el cortafuegos; no reinicies toda la red repetidamente.

EsperadoSabes si LuCI se ejecuta y si 80/443 están escuchando.

Shell del routerComprueba si el cortafuegos bloquea la administración

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

Si acabas de cambiar una zona del cortafuegos, restaura la copia de seguridad o corrígelo desde la consola; no sigas cambiándolo sin acceso a la consola.

EsperadoEl tráfico de LAN al router en 80/443/22 no está bloqueado por accidente.

Capa 5: consola local / failsafe

Consola localConfirma desde la consola que el sistema está activo

Usa serie/HDMI/teclado, IPMI o una consola en la nube. El puerto serie suele ser 115200 8N1, pero compruébalo en tu dispositivo. Si no hay salida, verifica primero el cable, la velocidad en baudios y la alimentación.

Una vez dentro:

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

EsperadoVes un aviso de inicio de sesión o el registro del kernel.

Consola localUsa failsafe solo cuando haga falta

El momento de pulsar el botón de failsafe depende del dispositivo; sigue la página del dispositivo en OpenWrt o el manual del fabricante. Una vez dentro, inspecciona primero:

uci show network
uci show dhcp

Si solo la dirección LAN es incorrecta, cámbiala de nuevo y reinicia tras verificarla. Si tienes dudas, anota o haz una copia de seguridad de la configuración primero; no ejecutes firstboot. Un restablecimiento de fábrica borra la configuración.

EsperadoPuedes restaurar LAN/DHCP sin un restablecimiento de fábrica.

Orden de recuperación

1. No cambies nada: cable/puerto LAN/dirección estática en el cliente.
2. El ping funciona, la web falla: uhttpd/cortafuegos/HTTPS.
3. SSH funciona: depura los servicios por SSH; no cambies la LAN.
4. Sin SSH: consola/failsafe.
5. Restablecimiento de fábrica al final: confirma que no hay configuración ni copia de seguridad importante, y sé consciente de que tendrás que reconfigurar WAN/LAN/Wi-Fi.

Diagnósticos erróneos comunes

• Usar el puerto WAN como administración.
• El cliente aún tiene una subred o IP estática antigua.
• El navegador fuerza HTTPS mientras LuCI usa HTTP.
• Suponer que LuCI está sano porque el ping funciona.
• Cambiar la dirección LAN sin actualizar DHCP/puerta de enlace.
• Una regla del cortafuegos bloquea la administración desde la LAN.
• Falta uhttpd o se eliminó, pero se reinicia la red repetidamente.

Prueba E2 de laboratorio (2026-10-20)

• Entorno: OpenWrt 25.12.6 x86 VM 200; LAN 192.168.1.2; HTTP comprobado desde el host PVE.
• /etc/init.d/uhttpd stop: curl a http://192.168.1.2/ devolvió http=000 (conexión fallida); SSH siguió disponible.
• /etc/init.d/uhttpd start: HTTP devolvió 200.
• No probado: bloqueo por cortafuegos, cambio de puerto de uhttpd, falta del paquete LuCI, secuencia real de teclas del puerto serie/failsafe.
• Receta: tests/recipes/troubleshooting-no-web-ui.md.

Estado E2 y fuentes

• Esto es E2 parcial: se probaron la parada/recuperación de uhttpd y la conservación de SSH; el cortafuegos, el puerto y failsafe siguen siendo documentación.
• Decide primero si es enlace, dirección, uhttpd o cortafuegos; no hagas un restablecimiento de fábrica en lugar de diagnosticar por capas.
• Los procedimientos de consola/failsafe varían según el dispositivo y el firmware; lee antes la documentación del dispositivo.

Registro de pruebasEstado: Reproducido en laboratorio (E2)

Entorno

OpenWrt 25.12.6 x86 VM 200; uhttpd detenido/recuperado, comprobación HTTP 80, SSH conservado

Receta

tests/recipes/troubleshooting-no-web-ui.md

Resultado

E2 parcial: tras detener uhttpd, HTTP 80 rechazó la conexión y SSH siguió disponible; start restauró HTTP 200; cortafuegos/cambio de puerto/failsafe sin probar

Reproducido en laboratorio (E2); sin revisión independiente ni prueba en una red física. El E3 sigue necesitando hardware real.

Fuentes

• Failsafe y restablecimiento de fábrica de OpenWrt
• Conceptos básicos de LuCI en OpenWrt
• Configuración de red de OpenWrt
• DHCP y DNS de OpenWrt