escandell.
Català

Sistemas

hpServer: la Wi-Fi que se caía y cómo se cura sola

Diagnóstico completo de un adaptador Realtek RTL8822BU que perdía el enlace: cómo aislar la capa que falla y un watchdog systemd que recupera la red solo.

hpServer: la Wi-Fi que se caía y cómo se cura sola

Hace pocos días hpServer desapareció de la red. SSH no respondía, Tailscale lo veía en la lista pero no contestaba ni un ping, y los servicios que dependían de él se quedaron colgados (el montaje SSHFS desde fxserver, por ejemplo, congeló todo lo que lo tocaba). Todo apuntaba a una máquina muerta. No lo era: Debian seguía funcionando perfectamente. Lo que fallaba era una sola capa, muy abajo del todo: el enlace Wi-Fi.

Esta nota es doble: el relato del diagnóstico completo y una referencia práctica —para mi yo del futuro y para cualquiera que tenga un adaptador Realtek USB parecido— de cómo localizar el problema y cómo montar un sistema que se recupera solo.

La parte didáctica: ¿qué capa ha fallado?

Cuando un servidor “desaparece”, la pregunta clave no es qué ha fallado sino en qué capa. De arriba abajo tenemos aplicaciones, servicios de red (DNS, VPN, túneles), IP, y finalmente el enlace físico. La regla que apliqué:

Si el enlace ha caído, todo lo que hay por encima cae con él. Empieza siempre por la capa más baja que puedas comprobar.

En este caso, durante una caída la interfaz quedaba así:

wlx6c5ab074f239: <NO-CARRIER,BROADCAST,MULTICAST,UP>
state DOWN
Not connected.

y el ping al router daba La red es inaccesible. Eso dejó siendo irrelevantes Tailscale, Cloudflare, el DNS y el DHCP: todos dependen de que el enlace funcione antes.

Descartando sospechosos

Fui cerrando puertas una a una:

  • UFW: en los logs había muchos [UFW BLOCK], pero era tráfico local bloqueado a propósito. No explica el fallo del firmware.
  • Ahorro de energía: ya tenía power_save off en la interfaz y disable_lps_deep=Y en el módulo rtw88_core.
  • Puerto USB: el problema se repetía en puertos distintos, y durante las caídas el dispositivo seguía presente y negociando a 5000M.
  • Señal: entre -57 y -60 dBm en 5 GHz. Razonable.
  • Firmware: firmware-realtek 20250410-2, actualizado.
  • Kernel: pasé de 6.12.73 a 6.12.107 con la esperanza de que fuera una regresión arreglada. El problema se reprodujo igual.

La pista que lo ató todo

En el journalctl del kernel, cada caída dejaba el mismo rastro:

rtw_8822bu 2-2:1.0: failed to get tx report from firmware
wlx6c5ab074f239: send auth to 78:81:02:44:b3:35 (try 1/3)
wlx6c5ab074f239: authentication with 78:81:02:44:b3:35 timed out

El firmware deja de contestar, la asociación se pierde y los reintentos acaban en timeout. Y aquí el descubrimiento importante: ifdown + ifup NO recuperan la conexión (se queda en waiting for carrier... timed out). Reiniciar la configuración no toca lo que está roto.

Lo que sí funciona es reinicializar el driver:

sudo modprobe -r rtw88_8822bu
sudo modprobe rtw88_8822bu

Después de eso, el Wi-Fi vuelve a asociarse solo y el ping al router vuelve en segundos. Esto apunta el problema al estado interno de la combinación adaptador/driver/firmware: TP-Link 2357:0138 (Realtek RTL8822BU), driver rtw88_8822bu, firmware 27.2.0.

El watchdog: que se recupere solo

Mientras investigo la causa de fondo, hpServer ahora se cura solo. La lógica: hacer ping al router (no a 8.8.8.8, para no reiniciar el Wi-Fi por un corte externo de internet), confirmar con una segunda comprobación, y si de verdad ha caído, bajar la interfaz, recargar el módulo y volverla a subir.

/usr/local/sbin/wifi-watchdog.sh:

#!/bin/bash

IFACE="wlx6c5ab074f239"
ROUTER="192.168.0.1"
MODULE="rtw88_8822bu"
LOG_TAG="wifi-watchdog"

# Si el router responde, todo está bien.
if ping -I "$IFACE" -c 2 -W 2 "$ROUTER" >/dev/null 2>&1; then
    exit 0
fi

logger -t "$LOG_TAG" "Wi-Fi sin conexión. Esperando 10 segundos antes de confirmar..."

# Evitar actuar por un microcorte.
sleep 10

if ping -I "$IFACE" -c 2 -W 2 "$ROUTER" >/dev/null 2>&1; then
    logger -t "$LOG_TAG" "La conexión se ha recuperado sola."
    exit 0
fi

logger -t "$LOG_TAG" "Wi-Fi sigue caído. Reiniciando módulo $MODULE..."

# Limpiar el estado de la interfaz.
ifdown --force "$IFACE" >/dev/null 2>&1 || true

# Reinicializar el adaptador.
modprobe -r "$MODULE"

sleep 2

modprobe "$MODULE"

# Esperar a que vuelva a inicializarse la interfaz.
sleep 5

# Levantar la conexión.
ifup "$IFACE" >/dev/null 2>&1 || true

sleep 10

# Comprobar resultado.
if ping -I "$IFACE" -c 2 -W 2 "$ROUTER" >/dev/null 2>&1; then
    logger -t "$LOG_TAG" "Wi-Fi recuperado correctamente."
    exit 0
else
    logger -t "$LOG_TAG" "ERROR: no se ha podido recuperar el Wi-Fi."
    exit 1
fi

El servicio y el timer de systemd, cada minuto:

# /etc/systemd/system/wifi-watchdog.service
[Unit]
Description=HPServer Wi-Fi watchdog
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/wifi-watchdog.sh
# /etc/systemd/system/wifi-watchdog.timer
[Unit]
Description=Comprobar Wi-Fi de HPServer cada minuto

[Timer]
OnBootSec=2min
OnUnitActiveSec=1min
AccuracySec=5s
Persistent=true

[Install]
WantedBy=timers.target

Activación:

sudo systemctl daemon-reload
sudo systemctl enable --now wifi-watchdog.timer
systemctl status wifi-watchdog.timer   # Active: active (waiting)

La prueba controlada

Para confiar en él hay que verlo trabajar. Simulas una caída y no tocas nada:

sudo ifdown --force wlx6c5ab074f239

En un minuto o dos, el timer lo detecta, recarga el módulo y recupera la red. En los logs tiene que aparecer la secuencia completa:

sudo journalctl -t wifi-watchdog --since "-5 minutes"
Wi-Fi sin conexión. Esperando 10 segundos antes de confirmar...
Wi-Fi sigue caído. Reiniciando módulo rtw88_8822bu...
Wi-Fi recuperado correctamente.

Cuando todo va bien, el watchdog es mudo: si no dice nada, es que todo va bien.

Referencia rápida para la próxima vez

# estado del enlace Wi-Fi
sudo /usr/sbin/iw dev wlx6c5ab074f239 link

# power save (debe ser off)
sudo /usr/sbin/iw dev wlx6c5ab074f239 get power_save

# driver y firmware en uso
sudo ethtool -i wlx6c5ab074f239

# errores Wi-Fi del arranque actual
sudo journalctl -k -b --no-pager | grep -Ei 'rtw|8822|wlx|deauth|disassoc|auth|firmware|usb' | tail -100

# logs del watchdog (hoy / todos)
sudo journalctl -t wifi-watchdog --since today
sudo journalctl -t wifi-watchdog

# recuperación manual comprobada
sudo ifdown --force wlx6c5ab074f239
sudo modprobe -r rtw88_8822bu
sleep 2
sudo modprobe rtw88_8822bu
sleep 5
sudo ifup wlx6c5ab074f239

Estado actual y qué haré si continúa

Ahora mismo: conexión estable a 5 GHz con el watchdog operativo. Si el problema vuelve (el watchdog lo registrará), los logs acumulados me dirán frecuencia y patrón para decidir si toca investigar una regresión concreta de rtw88_8822bu, probar un kernel diferente, ajustar opciones de rtw88_usb, o directamente cambiar a un adaptador con un chipset mejor soportado.

La lección que me quedo es la misma de la nota sobre servidores que no responden: la red es un sistema. Esta vez la pieza caída era el adaptador Wi-Fi, y todo lo que colgaba de él —Tailscale, SSH, mis montajes— hizo que pareciera una muerte clínica cuando solo era un desmayo. Diagnosticar por capas, descartar con pruebas, y dejar el sistema capaz de curarse solo mientras sigues investigando.