Espera ahí: las conexiones WPA3 fallan después de 11 horas

Artículo original ↗ Discusión en Hacker News ↗

Las conexiones Wi‑Fi WPA3 en ciertos dispositivos basados en Broadcom/Infineon aparentemente se caen tras unas 11 horas de funcionamiento, probablemente por un bug del chipset o del controlador relacionado con el rekeying de claves o con contadores, y no por un defecto inherente de WPA3. Los comentaristas intercambian soluciones temporales como reinicios programados o volver a WPA2, y amplían la crítica al ecosistema Wi‑Fi en general: blobs de firmware opacos, escaso soporte del fabricante a largo plazo e incentivos económicos que favorecen lanzar nuevos estándares antes que probarlos a fondo. Varias voces recomiendan usar hardware algo más antiguo y bien soportado, y pilas de código abierto como OpenWrt para ganar fiabilidad, a la vez que señalan los obstáculos prácticos y regulatorios para los chipsets Wi‑Fi completamente abiertos.

Hipótesis sobre la causa raíz del fallo de WPA3 a las 11 horas

  • Muchos sospechan un “bug de uptime”: desbordamiento de enteros o envoltura de contadores en la combinación chip/controlador Wi‑Fi de Broadcom/Cypress/Infineon.
  • Otros creen que se trata específicamente de un problema de rekeying:
    • El intervalo de rekeying de GTK/SAE suele ser de ~3600s; algunos proponen que algo falla después de unos 10 rekeyings exitosos y que el 11.º falla, lo que encaja con el síntoma de 11 horas.
    • Se sugiere como posible solución un parche a hostapd (cambiando las vidas útiles de las claves, por defecto ~12h), aunque el momento no encaja del todo.
  • Los simples contadores de segundos de 16 bits no cuadran exactamente con 11h; se especula sobre otras granularidades de temporizador o contadores de tramas.
  • Consenso: probablemente un bug del cliente/controlador, no un fallo general de la especificación WPA3; se informa de que los controladores del fabricante funcionan, lo que implica que hay una solución alternativa.

Críticas al hardware, los controladores y el ecosistema

  • Se describe el ecosistema Wi‑Fi de Broadcom/Cypress/Infineon como “maldito”: blobs binarios, mal soporte en Linux, escasa interacción del fabricante.
  • Algunos defienden a Raspberry Pi como “bien por su precio” y otros la atacan como poco fiable, con componentes baratos y mínimamente probados.
  • Varios recomiendan tarjetas Wi‑Fi PCIe de Intel por su estabilidad, pero otros citan problemas recientes de Intel y la falta de soporte de modo AP en chips más nuevos.
  • Se elogia a las pilas de código abierto como ath9k y OpenWrt por su estabilidad, pero dependen de hardware antiguo o de chipsets limitados.

Soluciones temporales y consejos prácticos

  • Se comentan soluciones temporales automatizables:
    • Reinicios programados (cron/timers de systemd) justo antes de la ventana de fallo.
    • Monitorización de la conectividad (por ejemplo, ping) y reinicio de la interfaz al fallar.
    • Ajustar los intervalos de rekeying WPA o quedarse en WPA2 cuando sea posible.
    • Usar Wi‑Fi abierto/OWE más una VPN superpuesta como WireGuard para la seguridad.
  • Algunos advierten que publicar soluciones temporales puede animar a los fabricantes a marcar los errores como “wontfix”.

Madurez de los estándares Wi‑Fi y estrategia de despliegue

  • Consejo de practicantes de Wi‑Fi: mantenerse 1–2 generaciones por detrás para lograr fiabilidad (por ejemplo, 802.11ac + WPA2 en lugar de WPA3/6E/7 de vanguardia).
  • Otros argumentan que Wi‑Fi 6/ax ya es suficientemente maduro; Wi‑Fi 7 se considera demasiado temprano.
  • Empresa vs consumo: el equipo empresarial suele recibir correcciones reales de errores; los routers de consumo suelen sortear la inestabilidad con funciones de reinicio automático.

Discusión sobre hardware Wi‑Fi de código abierto

  • Los chips Wi‑Fi completamente abiertos se ven como difíciles desde el punto de vista económico y regulatorio:
    • Gran complejidad de la especificación y carga de certificación.
    • Normas de la FCC contra el comportamiento de transmisión modificable por el usuario.
    • Márgenes bajos y economía de chips impulsada por volumen.
  • Existen proyectos de Wi‑Fi abierto basados en FPGA como plataformas de investigación, pero aún no son alternativas prácticas para el mercado masivo.