Skip to content

fix(firmware): accept WPA/WPA2-mixed routers; warn about compact-board thermal risk#1288

Open
matiapa wants to merge 1 commit into
ruvnet:mainfrom
matiapa:fix/wifi-auth-threshold-thermal-warning
Open

fix(firmware): accept WPA/WPA2-mixed routers; warn about compact-board thermal risk#1288
matiapa wants to merge 1 commit into
ruvnet:mainfrom
matiapa:fix/wifi-auth-threshold-thermal-warning

Conversation

@matiapa

@matiapa matiapa commented Jul 9, 2026

Copy link
Copy Markdown

Summary

  • Lower the ESP32 STA auth threshold from WIFI_AUTH_WPA2_PSK to WIFI_AUTH_WPA_PSK so routers running WPA/WPA2-mixed compatibility mode (common default on many consumer routers) aren't rejected with WIFI_REASON_NO_AP_FOUND_IN_AUTHMODE_THRESHOLD (reason=211). Also log the disconnect reason + RSSI instead of retrying blind, so this is diagnosable from serial output next time.
  • Add a thermal-risk warning for compact/coin-sized ESP32-S3 clones (ESP32-S3-Zero, SuperMini) to firmware/esp32-csi-node/README.md, the repo's CLAUDE.md hardware table, and the ruview-hardware-setup skill (so an AI agent flashing on someone's behalf asks about board form factor and warns proactively).

Why

Hit both issues live while onboarding a fresh 3-node deployment:

  1. WiFi wouldn't connect at all — serial log showed silent retries with no reason code. Added the reason/rssi log, found reason=211, traced it to the router's WPA/WPA2-mixed mode being rejected by the strict WPA2_PSK threshold.
  2. After a normal ~20-30 min CSI session, three ESP32-S3-Zero (compact/coin-sized clone) boards ran warm to the touch throughout (not flagged as unusual at the time), and failed to power on again afterward — heating up immediately even from a known-good USB power source on the next attempt, consistent with permanent regulator damage rather than a transient fault. This firmware runs the WiFi radio with modem sleep disabled (WIFI_PS_NONE) plus a full edge DSP pipeline (edge_tier=2) continuously, with no duty-cycling. Full-size dev boards (DevKitC-1, XIAO) have the copper pour/thermal mass to handle that; coin-sized clones with minimal PCB copper and budget regulators may not. Nothing in the docs warned about this before someone (or their AI agent) walks away from a board assuming any ESP32-S3 handles sustained full-load operation.

Full incident writeup + follow-up ideas (duty-cycled mode for compact boards, runtime thermal check) in #1289.

Test plan

  • Rebuilt firmware (4MB variant) with the WPA_PSK threshold change via espressif/idf:v5.4 Docker build
  • Reflashed an ESP32-S3-Zero, confirmed it connects to a WPA/WPA2-mixed-mode router and streams CSI to a wifi-densepose-sensing-server over UDP
  • Confirmed the disconnect-reason log correctly surfaced reason=211 before the fix, and connects cleanly after
  • Maintainers: re-run cargo test --workspace --no-default-features / firmware CI as this only touches main.c + docs

Docs portion addresses #1289 — thermal follow-up items in that issue remain open.

Co-Authored-By: claude-flow ruv@ruv.net

…d thermal risk

Lower the STA auth threshold from WPA2_PSK to WPA_PSK so routers running
WPA/WPA2-mixed compatibility mode aren't rejected with
WIFI_REASON_NO_AP_FOUND_IN_AUTHMODE_THRESHOLD (reason=211), and log the
disconnect reason/rssi instead of retrying blind. Also document the thermal
risk of running this firmware's continuous-radio, tier-2 DSP pipeline on
coin-sized clone boards (ESP32-S3-Zero, SuperMini) with minimal PCB copper
and budget regulators, after a field report of three such boards failing to
power on following a normal session.

Co-Authored-By: claude-flow <ruv@ruv.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant