Hold on there: WPA3 connections fail after 11 hours

Original Article ↗ Hacker News Discussion ↗

WPA3 Wi‑Fi connections on certain Broadcom/Infineon-based devices are reportedly dropping after about 11 hours of uptime, likely due to a chipset or driver bug around key rekeying or counters rather than an inherent flaw in WPA3 itself. Commenters trade workarounds such as scheduled reboots or falling back to WPA2, and broaden the critique to the wider Wi‑Fi ecosystem: opaque firmware blobs, weak long-term vendor support, and economic incentives that favor shipping new standards over thoroughly testing them. Several voices recommend using slightly older, well-supported hardware and open-source stacks like OpenWrt for reliability, while noting the practical and regulatory obstacles to fully open Wi‑Fi chipsets.

Root-cause hypotheses for the 11-hour WPA3 failure

  • Many suspect an “uptime bug”: integer overflow or counter wrap in the Broadcom/Cypress/Infineon Wi‑Fi chip/driver combo.
  • Others think it’s specifically a rekeying problem:
    • GTK/SAE rekey interval often ~3600s; some propose something breaks after ~10 successful rekeys and the 11th fails, matching the 11‑hour symptom.
    • One patch to hostapd (changing key lifetimes, default ~12h) is suggested as a possible fix, though the timing doesn’t quite match.
  • Simple 16‑bit second counters don’t line up exactly with 11h; people speculate about other timer granularities or frame counters.
  • Consensus: likely a client/driver bug, not a general WPA3 spec failure; vendor drivers reportedly work, implying there is a workaround.

Hardware, drivers, and ecosystem criticism

  • Broadcom/Cypress/Infineon Wi‑Fi ecosystem is described as “cursed”: binary blobs, poor Linux support, minimal vendor engagement.
  • Raspberry Pi is defended by some as “fine for its price” and attacked by others as unreliable, with cheap, minimally tested components.
  • Several recommend Intel PCIe Wi‑Fi cards for stability, but others cite recent Intel issues and lack of AP mode support on newer chips.
  • Open-source stacks like ath9k and OpenWrt are praised for stability, but rely on older hardware or limited chipsets.

Workarounds and practical advice

  • Automatable workarounds discussed:
    • Scheduled reboots (cron/systemd timers) just before the failure window.
    • Monitoring connectivity (e.g., ping) and bouncing the interface on failure.
    • Adjusting WPA rekey intervals or sticking to WPA2 where possible.
    • Using open/OWE Wi‑Fi plus an overlay VPN like WireGuard for security.
  • Some warn that publishing workarounds can encourage vendors to mark bugs “wontfix.”

Wi‑Fi standards maturity and deployment strategy

  • Advice from Wi‑Fi practitioners: stay 1–2 generations behind for reliability (e.g., 802.11ac + WPA2 rather than bleeding‑edge WPA3/6E/7).
  • Others argue Wi‑Fi 6/ax is now mature enough; Wi‑Fi 7 is considered too early.
  • Enterprise vs consumer: enterprise gear tends to get real bugfixes; consumer routers often work around instability with auto-reboot features.

Open-source Wi‑Fi hardware discussion

  • Fully open Wi‑Fi chips are seen as economically and regulatorily difficult:
    • Massive spec complexity and certification burden.
    • FCC rules against user-modifiable transmit behavior.
    • Low margins and volume-driven chip economics.
  • FPGA-based open Wi‑Fi projects exist as research platforms but aren’t yet practical mass-market alternatives.