Espere aí: conexões WPA3 falham após 11 horas

Artigo original ↗ Discussão no Hacker News ↗

Conexões Wi‑Fi WPA3 em alguns dispositivos baseados em Broadcom/Infineon estariam caindo após cerca de 11 horas de uso, provavelmente por um bug no chipset ou driver relacionado a rekeying de chaves ou contadores, e não por uma falha inerente do WPA3. Comentadores trocam workarounds como reinicializações agendadas ou voltar ao WPA2, e ampliam a crítica ao ecossistema Wi‑Fi: blobs de firmware opacos, fraco suporte de longo prazo dos fabricantes e incentivos econômicos que favorecem lançar novos padrões em vez de testá-los a fundo. Várias vozes recomendam usar hardware um pouco mais antigo e bem suportado e pilhas open-source como OpenWrt para confiabilidade, ao mesmo tempo em que apontam os obstáculos práticos e regulatórios para chipsets Wi‑Fi totalmente abertos.

Hipóteses de causa raiz para a falha do WPA3 após 11 horas

  • Muitos suspeitam de um “bug de uptime”: estouro de inteiro ou wrap de contador no combo chip/driver Wi‑Fi da Broadcom/Cypress/Infineon.
  • Outros acham que é especificamente um problema de rekeying:
    • O intervalo de rekey GTK/SAE costuma ser ~3600s; alguns propõem que algo quebra após ~10 rekeys bem-sucedidos e a 11ª falha, o que combina com o sintoma de 11 horas.
    • Um patch no hostapd (alterando os tempos de vida das chaves, padrão ~12h) é sugerido como possível correção, embora a temporização não bata perfeitamente.
  • Contadores simples de segundos de 16 bits não se alinham exatamente com 11h; as pessoas especulam sobre outras granularidades de timer ou contadores de frames.
  • Consenso: provavelmente um bug do cliente/driver, não uma falha geral da especificação WPA3; drivers de fabricante aparentemente funcionam, o que indica que existe uma solução alternativa.

Críticas ao hardware, drivers e ecossistema

  • O ecossistema Wi‑Fi da Broadcom/Cypress/Infineon é descrito como “amaldiçoado”: blobs binários, suporte fraco no Linux, pouco envolvimento do fabricante.
  • O Raspberry Pi é defendido por alguns como “bom pelo preço” e criticado por outros como pouco confiável, com componentes baratos e minimamente testados.
  • Vários recomendam placas Wi‑Fi PCIe da Intel pela estabilidade, mas outros citam problemas recentes da Intel e falta de suporte a modo AP nos chips mais novos.
  • Pilhas open-source como ath9k e OpenWrt são elogiadas pela estabilidade, mas dependem de hardware mais antigo ou de chipsets limitados.

Workarounds e conselhos práticos

  • Workarounds automatizáveis discutidos:
    • Reinicializações agendadas (cron/systemd timers) pouco antes da janela de falha.
    • Monitoramento de conectividade (por exemplo, ping) e reinício da interface em caso de falha.
    • Ajustar os intervalos de rekey do WPA ou, quando possível, usar WPA2.
    • Usar Wi‑Fi aberto/OWE com uma VPN em overlay como WireGuard para segurança.
  • Alguns alertam que publicar workarounds pode incentivar fabricantes a marcar bugs como “wontfix”.

Maturidade dos padrões Wi‑Fi e estratégia de implantação

  • Conselhos de profissionais de Wi‑Fi: ficar 1–2 gerações atrás por confiabilidade (por exemplo, 802.11ac + WPA2 em vez de WPA3/6E/7 de ponta).
  • Outros argumentam que o Wi‑Fi 6/ax já está maduro o suficiente; o Wi‑Fi 7 é considerado cedo demais.
  • Enterprise vs consumer: equipamentos enterprise tendem a receber correções reais; roteadores consumer frequentemente contornam a instabilidade com recursos de reinicialização automática.

Discussão sobre hardware Wi‑Fi open-source

  • Chips Wi‑Fi totalmente open são vistos como difíceis do ponto de vista econômico e regulatório:
    • Complexidade enorme da especificação e da certificação.
    • Regras da FCC contra comportamento de transmissão modificável pelo usuário.
    • Margens baixas e economia de chips orientada por volume.
  • Projetos Wi‑Fi open baseados em FPGA existem como plataformas de pesquisa, mas ainda não são alternativas práticas para o mercado de massa.