Skip to content

fix(coord): back off minutes behind a captive portal instead of every 16s - #48

Merged
fudio101 merged 2 commits into
mainfrom
fix/captive-portal-backoff
Aug 18, 2026
Merged

fix(coord): back off minutes behind a captive portal instead of every 16s#48
fudio101 merged 2 commits into
mainfrom
fix/captive-portal-backoff

Conversation

@fudio101

Copy link
Copy Markdown
Collaborator

What

do_noise_handshake() now flags a captive portal in two ways:

  • an HTTP 302 in the Noise-upgrade response, or
  • the TCP connection closing outright before any response arrives (some
    portals do this instead of a redirect).

Either sets a module-static s_captive_portal flag, which the
COORD_RECONNECTING backoff checks: instead of the usual <=16s exponential
backoff, it waits a flat 5 minutes. Hammering a portal every 16s until the
user logs in is futile and churns TLS setup/teardown for no benefit, wasting
radio time and internal heap. The wait remains command-queue-interruptible
(it's the existing xQueueReceive(ml->coord_cmd_queue, &wake_cmd, pdMS_TO_TICKS(backoff_ms))), so a real event — new creds, a rebind, the
portal clearing — still wakes the loop early; a false-positive portal
detection is harmless for the same reason.

Source

Adapted from cplewes/microlink
8f2ff39b + 5c7303b4 (not cherry-picked — base has diverged too far).

Related issues

Closes #23

Builds on top of #47 (the teardown-UAF liveness bitmask, same file) —
branched from that PR's tip and rebased onto main once #47 merged, so
this diff is just the captive-portal change.

Test plan

idf.py build isn't runnable in this sandbox (no ESP-IDF installed).
Manual check: grep -n "s_captive_portal" components/microlink/src/ml_coord.c
shows exactly 5 uses (declare + 2 sets + check + clear). Needs hardware
re-test behind an actual captive portal to confirm detection fires and the
5-minute backoff is observed, plus confirm a real wake (rebind) still
interrupts it promptly.

nguyenndt-qualgo and others added 2 commits August 18, 2026 23:42
… 16s

do_noise_handshake() now flags a captive portal in two ways: an HTTP
302 in the Noise-upgrade response, or the TCP connection closing
outright before any response arrives (some portals do this instead of
a redirect). Either sets s_captive_portal, which the COORD_RECONNECTING
backoff checks: instead of the usual <=16s exponential backoff, it
waits a flat 5 minutes. Hammering a portal every 16s until the user
logs in is futile and churns TLS setup/teardown that starves the
radio and internal heap for no benefit. The wait remains
command-queue-interruptible (xQueueReceive with the backoff as
timeout), so a real event — new creds, a rebind, the portal clearing —
still wakes the loop early; a false-positive portal detection is
harmless for the same reason.

Adapted from cplewes/microlink@8f2ff39b and @5c7303b4.

Closes #23

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@fudio101
fudio101 merged commit c77ab55 into main Aug 18, 2026
13 checks passed
fudio101 added a commit that referenced this pull request Aug 19, 2026
Issue #23 (captive-portal detection) was closed and merged via PR #48
on 2026-08-18 but the tracker table was never updated to reflect it —
the only row still missing a done marker. Also prunes the Notes
section's two "conflicts to resolve before scoping" callouts (#11,
#2-vs-#17), both already resolved in their own rows.

Co-authored-by: Adrian.Nguyen-Qualgo <nguyen.ndt@qualgo.net>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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.

Detect captive portals and back off in ml_coord (mined from cplewes/microlink)

2 participants