Wiki personal — Esteban Alcocer

Wake-on-LAN, WoWLAN y recuperación tras corte de energía (pop-os)

Properties1
tagscosmic, hardware

Se lee en 5 min

Wake-on-LAN, WoWLAN y recuperación tras corte de energía (pop-os)

pop-os (HP T640 Thin Client, BIOS M43 v01.11) tiene dos interfaces de red — enp2s0f0 (Ethernet) y wlp3s0 (Realtek RTL8852AE, driver rtw89_8852ae) — y se investigó qué tan lejos llega el soporte de encendido remoto/automático en cada una, además de si el firmware permite que el equipo se encienda solo tras un corte de energía. Son tres mecanismos distintos que conviene no confundir: Wake-on-LAN y WoWLAN dependen de la tarjeta de red y responden a un paquete específico enviado por otra máquina; la recuperación tras corte de energía es puramente un comportamiento de firmware ante la pérdida y el regreso de la corriente AC, sin involucrar red en absoluto.

Wake-on-LAN por cable (enp2s0f0)

ethtool enp2s0f0 reporta soporte de hardware:

Supports Wake-on: pumbg
Wake-on: d
Link detected: no

La g en pumbg es el modo “magic packet”, el que usan herramientas como wakeonlan. Está soportado pero deshabilitado (Wake-on: d), y el cable no está conectado (Link detected: no), así que ahora mismo no es utilizable. Para habilitarlo en caliente:

sudo ethtool -s enp2s0f0 wol g

Esto no persiste solo tras un reinicio — necesitaría un hook de systemd/udev dedicado para reaplicarse en cada arranque, cosa que no se ha configurado.

WoWLAN (wlp3s0)

iw phy phy0 info muestra el soporte del chip Realtek:

WoWLAN support:
  * wake up on disconnect
  * wake up on magic packet
  * wake up on pattern match, up to 18 patterns of 1-128 bytes

A diferencia del Ethernet, esta sí quedó activada: el perfil de NetworkManager de la red Wi-Fi (FamAlcocerAguilar) tiene 802-11-wireless.wake-on-wlan puesto en magic:

sudo nmcli connection modify "FamAlcocerAguilar" 802-11-wireless.wake-on-wlan magic
sudo nmcli connection up "FamAlcocerAguilar"

Confirmado con:

$ sudo iw phy phy0 wowlan show
WoWLAN is enabled:
 * wake up on magic packet

Al vivir en el perfil de conexión de NetworkManager (no en un estado de runtime), se reaplica solo cada vez que esta red se activa. Dos cosas quedan sin confirmar:

  • El modo de suspensión del sistema es deep (/sys/power/mem_sleep → s2idle [deep], con deep seleccionado), no s2idle puro. El chip sí reporta soporte PCI PME hasta D3cold, que es la señal que hace falta para que un dispositivo PCIe pueda despertar el equipo desde ese estado — pero no se ha probado en la práctica.
  • No se ha hecho la prueba de extremo a extremo (suspender el equipo y mandar un magic packet desde otra máquina en la red a la MAC de wlp3s0). Si algún día se quiere confirmar: wakeonlan <mac-de-wlp3s0> tras suspender.

Recuperación automática tras corte de energía (AC Power Recovery)

Esto es lo que en BIOS/UEFI suele llamarse “AC Power Recovery”, “Restore on AC/Power Loss” o “After Power Loss” — que el equipo se encienda solo cuando vuelve la corriente tras un apagón, sin depender de red ni de que alguien presione el botón físico.

Se investigó si HP expone esta opción vía sysfs en Linux (algunos equipos business/thin-client de HP lo hacen a través del driver hp-bioscfg, sin necesidad de entrar al setup del BIOS). El resultado es que no es viable en este equipo, por un bug de firmware:

  • /sys/class/firmware-attributes/hp-bioscfg/ existe y los módulos correctos están cargados (hp_bioscfg, hp_wmi, wmi, firmware_attributes_class), pero la enumeración de atributos del BIOS sale corrupta: los nombres de los atributos son bytes no imprimibles, y current_value/possible_values están vacíos. Ninguno de los pocos atributos legibles (Sure_Start, pending_reboot) tiene relación con power.
  • La causa raíz aparece en journalctl/dmesg: al invocar los métodos WMI _SB.WMID.WQBD, WQBE y WMAA (los que el driver usa para leer el bloque de configuración del BIOS), el intérprete ACPI/AML del kernel aborta con AE_AML_OPERAND_VALUE y AE_AML_BUFFER_LIMIT. El firmware del BIOS M43 v01.11 (AMI, 2021-09-13) devuelve un buffer que el propio kernel no puede interpretar — es un bug del firmware de HP, no algo corregible desde la configuración de Linux.
  • No hay ninguna utilidad de configuración de BIOS de HP para Linux instalada ni disponible (hp-bioscfg-cli no existe en el sistema); la HP BIOS Configuration Utility oficial solo tiene versión para Windows/DOS/WinPE.
  • fwupdmgr get-updates confirma que no hay actualización de firmware disponible para este equipo en este momento. Una versión de BIOS más nueva podría, en teoría, corregir el bug de enumeración WMI y dejar el atributo de power utilizable desde sysfs — pero no hay nada que actualizar hoy, y de haberlo sería una acción de riesgo (flasheo de firmware) que no se ha evaluado.

Conclusión práctica: la única vía confiable para activar esto hoy es manual, directo en el BIOS. Al arrancar el equipo, presionar F10 (setup estándar de HP) y buscar, típicamente bajo Advanced → Power Management (el nombre exacto del submenú puede variar según la revisión del BIOS), la opción “After Power Loss” / “Restore on AC/Power Loss”, y ponerla en “Power On”. No es automatizable desde el sistema operativo mientras este bug de firmware siga presente.

Véase también

Vista Gráfica

Retroenlaces