Replace the two separate volatile counters (s_idle_ticks, s_busy_ticks)
with a two-element array s_ticks[2]:
[0] = idle ticks (xTaskGetCurrentTaskHandle() != s_idle_handle → false → 0)
[1] = busy ticks (xTaskGetCurrentTaskHandle() != s_idle_handle → true → 1)
The tick hook becomes a single branchless statement:
s_ticks[xTaskGetCurrentTaskHandle() != s_idle_handle]++;
This eliminates the conditional branch from the tick ISR at the cost
of a few additional instructions in IRAM. On Xtensa LX7 the branch
is somewhat unpredictable — the system alternates between idle and
busy — so removing the misprediction penalty (~5–10 cycles/call)
outweighs the slightly larger code size.
_onSample() is updated to read s_ticks[0] (idle) and s_ticks[1]
(busy) accordingly. All other logic is unchanged.
Previously _onSample() computed and stored a volatile float _sma_avg
on every sample (64 times/minute on core 0). The getter simply returned
that pre-computed value.
This commit inverts the responsibility:
- _sma_sum is now volatile uint16_t — the raw integer sum is the
cross-core shared state, written atomically by core 0 (single S16I
instruction on Xtensa LX7) and read by core 1.
- The float conversion (uint16_t → float multiply) is moved into
getCore0Util(), which is called rarely (once/minute for history,
on-demand for web requests). The multiply now happens on the core
that actually needs the result.
- _sma_avg is removed entirely, saving 4 bytes and one volatile float
store per sample from the hot path.
- The SMA update is rewritten as a single combined expression:
const uint16_t last = _sma_buf[_sma_idx];
_sma_buf[_sma_idx] = s8;
_sma_sum = (_sma_sum - last) + s8;
This produces a single write to _sma_sum instead of two (decrement
then increment), which is cleaner when _sma_sum is volatile.
The cross-core contract is unchanged: core 0 writes _sma_sum once per
sample; core 1 reads it in getCore0Util(). A 16-bit aligned store on
Xtensa LX7 is a single instruction, so no spinlock is needed.
The previous implementation maintained three exponential moving averages
(1/5/15-minute) of CPU busy-fraction, sampled every 5 seconds. This had
two problems:
1. Wrong semantics: the metric was labelled "load_avg" (a Unix concept
measuring run-queue depth), but the tracker actually measures CPU
busy-time as a fraction of FreeRTOS ticks — i.e. utilization, not
load. The name was misleading.
2. Poor responsiveness: the 1-minute EMA (DECAY = exp(-5/60) ≈ 0.920)
has a ~60-second time constant. On a live web panel, this made the
metric appear frozen, especially during short bursts of activity
(e.g. an HTTP request from the panel itself).
This commit replaces the EMA with a 64-sample simple moving average
(SMA) over a compact uint8_t circular buffer. The sample interval is
60 s / 64 = 937,500 µs, so the window covers exactly 60 seconds:
Algorithm:
- Every 937,500 µs (= 60 s / 64), the FreeRTOS tick delta (busy vs
idle ticks on core 0) is computed and stored as a uint8_t
(0–255 = 0–100% utilization).
- The circular buffer holds 64 samples, spanning exactly 60 seconds
(64 × 937,500 µs = 60,000,000 µs). The timer interval is derived
directly from the window size: 60 000 000 / SMA_WINDOW µs.
- The index wraps with a bitwise AND (& 63) instead of modulo, since
64 is a power of 2.
- The running sum is a uint16_t (max 64 × 255 = 16 320, fits easily).
- The result _sma_avg is a volatile float written atomically by the
esp_timer task (core 0) and read from the main loop (core 1).
No spinlock is needed: on Xtensa LX7, a 32-bit aligned float store
is a single instruction.
The 60-second window smooths out short bursts (e.g. WiFi/HTTP spikes)
while reacting to sustained load changes within ~10–15 seconds.
Naming:
- The public API is now getCore0Util() returning a float in [0.0, 1.0].
The name explicitly identifies which core is measured (core 0, which
runs WiFi, MQTT, HTTP, and LwIP — see task_pinning.c).
- JSON keys: "load_avg" (array) → "core0_util" (scalar float, percent)
- HistorySample field: load_avg1_pct → core0_util_pct
- StatsHistory series key: "cpu_load" → "core0_util"
- Web panel label: "Load Avg" → "Core0 Util"
The history snapshot (once per minute) reads the same _sma_avg value,
which at that point represents the rolling average of the last 60
seconds — exactly one history interval.
Apply consistent number-unit spacing and helper usage:
- Add a space before "%" in all percentage labels (Battery,
Signal Quality, TX Share, RX/TX Flood Share, RX Error Rate,
Archive Free), matching the existing style of other units
such as " dBm" and " dB".
- Replace raw String(x) + " s" with formatDuration() for RX Air,
TX Air, and Total Air in the Radio card, matching the style
already used for uptime and event age.
Reorder the four air-time metrics in the Radio card:
Before: TX Air | RX Air
TX Share | Total Air
After: RX Air | TX Air
Total Air | TX Share
Move RX Air to the primary (top-left) position — a repeater
receives before it retransmits, so RX is the primary signal.
Move TX Share after Total Air so the derived percentage follows
the raw counters it summarises.
Add a compact "min X / max Y" label to the right of the current value
on each trend card in the stats panel. The range is computed client-side
from the points array already present in the API response, so no backend
changes are required.
CSS: add .trend-info (flex:1 wrapper) and .trend-range (small muted
label) classes; make .trend-value a flex row with space-between so the
range label is pushed to the right edge.
JS: refactor formatTrendValue to use a module-level kTrendFmt lookup
table instead of a chain of if-statements, and add a withUnit parameter
(default true) so the same function can produce unit-free numbers for
the range display. Populate the new head-range-<key> span in
renderTrendResult after the existing axis-label block.
Wire the 1-minute CPU load average into the stats history pipeline:
- Rename HistorySample::reserved to load_avg1_pct (uint8_t, 0-100);
struct size unchanged.
- Populate load_avg1_pct in updateStatsHistory on ESP32 from
_cpu_tracker.getLoadAvg1() * 100.
- Register "cpu_load" series in buildPointValue / seriesTitle /
seriesUnit so buildSeriesJson serves it via
/api/stats?series=cpu_load.
- Persist load_avg1_pct as a 29th CSV column in flushSummaryLog.
parseSummaryLine accepts both 28-column (old, load_avg1_pct=0)
and 29-column (new) formats for backward compatibility.
- Add "cpu_load" to the web panel trend card order with orange
sparkline color (#e07b39), "N %" hover formatting, and a Y-axis
floored at 0 with a 10% minimum ceiling.
Add a blinking "refreshed >Xm ago" label aligned to the right of the
Stats page h2 header. The label is hidden until stats are more than
1 minute old, then appears with a CSS color-pulse animation (red to
--text-muted) to draw attention. It hides immediately when a refresh
is initiated and reappears only after the next successful fetch.
- Add @keyframes blink-stale (color pulse red <-> --text-muted) and
.stats-stale CSS class (13px, normal weight, 1.5s animation)
- Add statsLastUpdated span inside the Stats h2 (flex, right-aligned,
initially hidden)
- statsLastFetchedAt: null until first successful fetch, reset to null
at the start of each loadStatsPage call, set to Date.now() on success
- updateStatsLastUpdated() hides span when null or secs < 60, shows
minutes/hours elapsed otherwise
- setInterval(updateStatsLastUpdated, 10000) runs only on /stats page
For a mesh repeater, a packet must be received before it can be
retransmitted, so RX metrics are the primary signal. Reorder the
Packets card to reflect this:
- Swap meter order: RX Flood Share before TX Flood Share
- Swap metric order: Recv before Sent, RX Direct before TX Direct
- Reorder floodTx/directTx declarations to match the new order
The "packets" trend series previously emitted a single combined
packet-count delta per interval. This change breaks it into two
separate values so the sparkline can show directional traffic.
Backend (StatsHistory::buildSeriesJson):
- Add a dedicated branch for series == "packets" in the second
(JSON-emission) loop.
- Each point is now emitted as [uptime_secs, rx_delta, tx_delta]
instead of [uptime_secs, total_delta].
- rx_delta / tx_delta are computed as non-wrapping uint32_t
differences of packets_recv / packets_sent between consecutive
samples, consistent with the existing buildPointValue logic.
- Buffer overflow guard updated from +24 to +40 bytes to cover
the wider three-integer format.
Frontend (WebPanelServer / inline JS):
- drawSparkline: for "packets", compute Y scale and bar height
from rx+tx total; render a stacked bar with TX on top (cyan,
#06b6d4 / hover #22d3ee) and RX below (violet, #8b5cf6 /
hover #a78bfa), proportioned by the rx:tx ratio.
- bindSparkHover tooltip: show "RX: N TX: M" for "packets"
instead of the generic formatTrendValue output.
- Remove the now-unused sparkStrokeColor early-return for
"packets" (stroke color is not used in the bar path).
Backend (StatsHistory.cpp):
- buildPointValue: add "error_rate" series — computes per-interval
receive error rate as (d_errors * 1000) / (d_errors + d_recv),
yielding a per-mille value (0–1000); returns false when no previous
sample is available or the interval had zero traffic
- seriesTitle: register "error_rate" → "Error Rate"
- seriesUnit: register "error_rate" → "per_mille"
- buildSeriesJson: extend the packets delta-series special case to
also cover "error_rate" so the current-value field is populated
correctly instead of being emitted as null
Frontend (WebPanelServer.cpp):
- renderMeter: suppress the hud-sub div when note is empty to avoid
blank layout space
- renderPacketsCard: compute recv_errors / (recv + recv_errors) as
errorRatePct; display it as a dedicated "RX Error Rate" meter with
an errors/attempts subtitle; lay out TX and RX flood-share meters
side-by-side in a two-column grid to make room
- sparkline pipeline: register "error_rate" throughout
- sparkFormatValue: (value / 10).toFixed(1) + " %" (per-mille → %)
- sparkStrokeColor: fixed red (#ef4444)
- sparkValueRange: fixed 0–1000
- sparkBands: green 0–20 %, yellow 20–45 %, red 45–100 %
- summary panel order: battery → memory → packets → error_rate →
signal → noise_floor (packet throughput and error rate grouped)
Add visual indicators for the mcu_temp trend series on the /stats page.
Values are stored as deci-°C (tenths of a degree), so all threshold
constants are in that unit (750 = 75 °C, 950 = 95 °C).
Threshold rationale (ESP32-S3 / Heltec V4, internal die temperature,
T_j max = 105 °C per datasheet):
- < 75 °C (< 750): normal, green — comfortable operating range
- 75–95 °C (750–950): elevated, amber — die is running hot,
30 °C below the junction temperature limit
- > 95 °C (> 950): critical, red — 10 °C below the 105 °C
junction limit; sensor accuracy is ±2 °C in this range
- Chart upper bound 125 °C (1250) covers the full sensor measurement
range with headroom
Changes:
- sparkStrokeColor: color the mcu_temp stroke dynamically based on
the most recent data point (green / amber / red)
- sparkGuideValues: draw horizontal guide lines at 75 °C and 95 °C
- sparkBands: shade three background bands (normal / high / critical)
- getTrendSeriesOrder: insert "mcu_temp" at position 2 (after battery
and memory, before RF metrics) when sensors.mcu_temp_c is present
in the summary payload
Add a /update endpoint to the HTTPS web panel server that issues a
302 redirect to the OTA update server (http://<host>/update, port 80).
When the user confirms the OTA prompt in the web panel, the browser
now opens the update page in a new tab automatically instead of
requiring manual navigation. The redirect also helps users who
manually navigate to https://<host>/update and forget to switch to
http — they are transparently forwarded to the correct URL.
The JS handler opens a relative URL (window.location.origin + "/update")
rather than a hardcoded device IP, so it works correctly when the device
is behind a reverse proxy. Similarly, handleOtaRedirect builds the
redirect target from the request's Host header rather than WiFi.localIP(),
preserving the proxy hostname end-to-end.
The new tab is opened only after runCommand("start ota") returns a
successful response, meaning the OTA server is already up and listening
on port 80 by the time the browser navigates to /update — no race
condition or polling needed.
The /update endpoint returns 404 until notifyOtaStarted() is called,
ensuring the redirect is only served once OTA mode is actually active.
- Add _ota_started flag to WebPanelServer, initialized to false;
set to true via notifyOtaStarted()
- Register GET /update route; returns 302 to http://<host>/update
only after OTA has been started (404 otherwise)
- Call notifyOtaStarted() from WebService::prepareForOTAStart() after
stopping the HTTP redirect server, freeing port 80 for the OTA server
- Update OTA button JS handler to open window.location.origin+"/update"
in a new tab on successful "start ota" command response
The .panel-warning class carries min-height:1.4em, so clearing its
textContent left an empty element at the bottom of the MQTT Settings
section.
Move the warning string into the HTML as static content and switch
refreshMqttIataWarning() to toggle style.display instead of textContent.
When no warning is needed the element is removed from layout entirely,
eliminating the extra vertical gap.
The Enter key handler in the CLI panel now awaits runCommand() directly
instead of simulating a button click, and clears the input field once
the command has been dispatched. This makes keyboard-driven use more
comfortable: the field is ready for the next command without manual
clearing.
The placeholder text "get mqtt.status" is removed from the command
input. Its color was nearly identical to regular input text, making the
field appear non-empty even when cleared, which was confusing. The
Quick "get" Commands panel already provides one-click buttons for all
common read-only queries, so the hint was redundant in any case.
The Run button onclick path is intentionally unchanged: the command
stays in the field after execution, allowing fast repeat by clicking
Run again without retyping.
Add a split-button next to the Refresh button on the stats page.
The right half (↻) toggles a 60-second auto-refresh countdown.
While active, the button shows the remaining seconds and fires
loadStatsPage() each time the counter reaches zero, then resets.
A manual Refresh while the timer is running resets the countdown
display to keep it in sync.
The syncNavButton helper is simplified: visibility is now toggled
on the whole split-group container instead of the individual button,
and the manual gridTemplateColumns override is removed because the
flex split-group handles its own layout.
CSS: introduce .btn-split, .btn-split button:first-child, and
.btn-split button:last-child rules for the joined-button appearance.
The app and stats pages already use an explicit data-theme attribute
approach — reading the saved "repeater-theme" key from localStorage
and falling back to the OS preference — with a ☾/☀ toggle button in
the UI. The login page was the only page still relying solely on the
CSS @media (prefers-color-scheme) query with no manual override.
This commit mirrors the same pattern on the login page so the theme
switcher works consistently across all pages:
- Add --surface2 CSS variable to both light and dark theme blocks
- Replace @media (prefers-color-scheme: dark) with :root[data-theme="dark"]
- Add a theme toggle button (☾/☀) in the login card header
- Add getPreferredTheme(), applyTheme(), and toggleTheme() helpers,
identical in behaviour to those already present on the app page
Replace the two Info panel fields so they surface more useful
device identity information on login:
- First field: renamed from "Version" (id: versionValue, cmd: ver)
to "Hardware" (id: hardware, cmd: board), showing the board
identifier rather than the firmware version string.
- Second field: renamed from "Client Version" (id: clientVersionValue,
cmd: get mqtt.client_version) to "Firmware" (id: firmware, cmd: ver),
showing the firmware version string.
"Client Version" was a static MQTT protocol identifier string used
internally in MQTT status payloads published to brokers. It tracks
the firmware build but carries no additinal information for a
user. It remains accessible via the Quick "get" Commands panel
(get mqtt.client_version).
Track CPU utilisation on core 0 using a FreeRTOS tick hook that
increments per-tick idle/busy counters, sampled every 5s by an
esp_timer callback. Exponential moving averages with Linux-style
time constants (1 / 5 / 15 min) are maintained in software:
DECAY1 = exp(-5/60) ≈ 0.9200 (1-minute window)
DECAY5 = exp(-5/300) ≈ 0.9835 (5-minute window)
DECAY15 = exp(-5/900) ≈ 0.9945 (15-minute window)
Core 1 is excluded intentionally: it runs the Arduino loopTask at
100% load for LoRa packet processing, so its figure is always 1.0
and carries no diagnostic value. All other tasks are pinned to
core 0 by task_pinning.c, so core-0 load reflects the true system
utilisation.
New files:
arch/esp32/CPUUsageTracker.h – class declaration
arch/esp32/CPUUsageTracker.cpp – tick hook + esp_timer sampling
Integration:
MyMesh::begin() calls _cpu_tracker.begin() on ESP32 builds.
formatStatsReply() emits "load_avg":[<1m>,<5m>,<15m>] in the
compact stats JSON payload.
formatWebStatsSummaryJson() adds the same field to the web-panel
stats endpoint under core.load_avg.
The web-panel HUD gains a "Load Avg" metric tile showing all
three values side-by-side; the core-metrics grid is widened from
4 to 5 columns. The tile is rendered conditionally so older
firmware (or non-ESP32 builds) that omit the field degrade
gracefully.
CPUUsageTracker.cpp is added to the esp32_base build_src_filter
in platformio.ini.
This fixes accidental crash when disabling the web panel without an
active MQTT uplink.
When the web panel was disabled, isWebEnabled() immediately returned
false. If no other network consumer was active, network.loop(false)
tore down WiFi *before* web.loop() stopped the httpd server.
Calling httpd_stop() while WiFi was being freed sometimes caused a
LoadProhibited panic (ieee80211_output_do -> wifi_free). This only
occurred when the server was stopped after WiFi teardown began.
Fix by including _panel.isRunning() in isWebEnabled(): WiFi stays up
for one extra iteration, so the server is stopped while the stack is
still valid. Only on the next loop cycle does the network shut down.
Additionally, move the "server stopped" and "redirect server stopped"
log messages to after the actual httpd_stop() / httpd_ssl_stop()
calls. This prevents a misleading "stopped" message if a crash
happens during teardown.
When startOTAUpdate() was called while the device was already connected
as a STA (web panel or MQTT active), it would bring up an open
"MeshCore-OTA" AP alongside the existing connection and report its IP
(softAPIP, typically 192.168.4.1) in the reply. The OTA AsyncWebServer
also listens on the STA interface, so the update page was reachable via
the existing network IP, but that address was not reported.
Two problems with the old behaviour:
- Raising an open AP while a STA connection is active is a security
concern.
- The reported AP address is not useful to a user who is already on the
same network as the device; they would naturally try the STA IP.
New behaviour:
- If the device is already connected as a STA (WiFi.status() ==
WL_CONNECTED), skip softAP() entirely and report WiFi.localIP() in
the reply. The OTA server is already reachable on that address.
- If there is no STA connection, keep the original behaviour: bring up
the "MeshCore-OTA" AP and report softAPIP().
In both cases the reply now includes the network name so the user knows
which interface to connect to:
STA: "Started: http://<ip>/update (WiFi: <ssid>)"
AP: "Started: http://<ip>/update (AP: MeshCore-OTA)"
If a user specifically wants to perform OTA via the dedicated AP, they
can disable the current WiFi interface first, after which startOTAUpdate
will fall into the AP path as before.
Calling `set web off` through the web panel caused the device to either
hang permanently or crash with a Guru Meditation Error (LoadProhibited).
Root cause: the HTTP command handler runs inside the httpd task and
synchronously called `setWebEnabled(false)`, which called
`_panel.stop()` -> `httpd_ssl_stop()` on the very connection that was
serving the request. This is unsafe in two ways:
1. `httpd_ssl_stop()` blocks waiting for the httpd task to finish, but
the httpd task is the one executing the handler — a self-deadlock.
2. Even if the stop proceeds, closing the active TLS connection from
within its own handler triggers lwIP teardown (esp_netif_down_api ->
dhcp_stop -> TCP RST) while the WiFi driver is in an inconsistent
state, causing a null-pointer dereference in ieee80211_output_do.
The deadlock was further compounded by a second concurrent call:
while the httpd task was stuck in httpd_ssl_stop(), the main loop kept
running, called ensureWebServer(), saw _server != nullptr (never cleared
because httpd_ssl_stop() never returned), and issued a second
httpd_ssl_stop() on the same handle — blocking the main loop as well
and stopping all radio packet processing until reboot.
The explicit start/stop calls in setWebEnabled() were redundant:
WebService::loop() already calls ensureWebServer() on every iteration,
which starts the server when enabled and WiFi is up, and stops it
otherwise. Remove the block entirely and let loop() handle both
transitions safely from the main loop context, outside the httpd task.
When the "start ota" command was issued from the web panel, a race
condition could occur between the main loop thread and the HTTP server
thread:
- HTTP thread: prepareForOTAStart() -> stopRedirectServer() ->
httpd_stop(_redirect_server) [blocking]
- Main thread: loop() -> ensureWebServer() -> stopRedirectServer() ->
httpd_stop(_redirect_server) [double free!]
Because stopRedirectServer() sets _redirect_server = nullptr only after
httpd_stop() returns, both threads could pass the nullptr check
simultaneously, resulting in a double free and heap corruption:
CORRUPT HEAP: Bad head at 0x3fcb1f24. Expected 0xabba1234 got 0x3fca5f34
assert failed: multi_heap_free multi_heap_poisoning.c:259 (head != NULL)
The call in ensureWebServer() was added as a safety net in commit
4b83142b, but is redundant: prepareForOTAStart() already calls
stopRedirectServer() synchronously before startOTAUpdate() occupies
port 80. Removing it eliminates the race condition.
The bug only manifested when OTA was triggered from the web panel
(HTTP thread), not from radio (main thread), because in the latter
case both calls happen on the same thread and cannot race.
The previous while loop computed a ternary `chunk_len` on every
iteration to handle the final partial chunk as a special case, and
called vTaskDelay(1) after every chunk including the last one,
adding an unnecessary yield immediately before the terminating null
chunk.
Restructure the loop using the identity:
last_size = ((len - 1) % kWebPageChunkSize) + 1
This gives `last_size` in [1, kWebPageChunkSize] for any non-zero `len`,
so the final partial chunk is always non-empty and can be sent after
the loop without a special case. The for loop then iterates only over
full kWebPageChunkSize chunks, making every iteration identical and
branch-free, and vTaskDelay(1) is called only after full chunks.
Also add a `len == 0` guard to short-circuit immediately when there is
nothing to send, and remove the best-effort terminator send on the
error path since a failed send makes a follow-up send equally likely
to fail.
The HTML pages (login, app, stats) are string literals compiled into
PROGMEM. Their sizes are known at compile time, but the previous
sendProgmemChunked() called strlen() on every request to determine
the length, requiring a full scan of potentially tens of kilobytes of
PROGMEM data before the first byte was sent.
Replace sendProgmemChunked() with a sendWhole() function that accepts
an explicit length parameter, and introduce a sendProgmem() macro that
passes sizeof(mem) - 1 at the call site. For array literals this
resolves to a compile-time constant, eliminating the runtime strlen
scan entirely.
The rename from sendProgmemChunked() to sendWhole() also better reflects
what the function does — it sends the entire buffer in chunks — rather
than where the data comes from.
The login, app, and stats HTML pages are static assets compiled into
PROGMEM. All dynamic content is fetched separately via JavaScript API
calls after the page loads — the HTML itself never changes between
requests within the same firmware version.
The "Cache-Control: no-store" header forced the browser to re-download
the full HTML on every visit, including a complete chunked transfer
from the ESP32. Given that the ESP32 is slow and serves responses in
small chunks, this was an unnecessary repeated cost that added latency
before the page became interactive.
Removing no-store allows the browser to cache the HTML pages locally.
Subsequent requests are served from the browser cache instantly, with no
transfer from the ESP32 at all, leaving the server free to handle the
API requests that actually carry dynamic data.
The HTTP redirect server has max_open_sockets = 2. A client that
connects and then disappears silently (network drop, browser crash,
mobile radio loss) leaves its socket occupying a slot indefinitely —
the server has no way to detect the loss until it tries to write to
the socket again.
Enable lru_purge_enable on the redirect server so that when both
slots are occupied by such stale connections, the least-recently-used
one is evicted automatically to make room for a new incoming
connection, rather than refusing it outright.
Add a "Connection: close" header to the 302 response as a complementary
measure. For well-behaved clients this triggers an immediate TCP
teardown after the redirect is received, shrinking the window during
which a connection can turn into a zombie. Together the two changes
provide defence in depth: "Connection: close" prevents stale connections
from forming in the first place; lru_purge_enable cleans them up when
they do.
The ESP32 processes HTTP requests sequentially on a single task.
Under load — generating chunked HTML pages, running commands, or
serving sequential stats API calls — it can be slow to send data
or loop back to accept the next request. The previous 2-second
recv/send timeouts were too tight for this: the httpd layer would
drop connections mid-transfer, causing the browser to hang or
show incomplete pages.
Raise recv_wait_timeout and send_wait_timeout from 2 s to 10 s
on both the HTTPS and HTTP-redirect servers, giving the ESP32
enough headroom to finish generating and sending responses without
the transport layer tearing down the connection prematurely.
Set backlog_conn to 0 on both servers. With the previous backlog
of 2, incoming connections completed the TCP handshake and queued
in the kernel while the ESP32 was busy. The browser saw the
connection as open but received no HTTP response, causing it to
freeze indefinitely. With backlog 0 (lwIP minimum), connections
that cannot be immediately accepted are refused outright, giving
the browser a fast, recoverable error instead of a silent hang.
Enable lru_purge_enable on the HTTPS server. Browsers hold
keep-alive connections open for reuse. With max_open_sockets = 2,
both slots can be occupied by idle keep-alive connections from the
same session, blocking a new connection attempt entirely. LRU
purge automatically closes the least-recently-used idle keep-alive
connection to make room, ensuring the single client can always
reconnect without a server restart.
When sending large PROGMEM content in chunks over HTTPS, the lwIP TCP/IP
task (tiT) could monopolize CPU 0 for an extended period without ever
yielding, starving the IDLE0 task and triggering the task watchdog timer.
Add vTaskDelay(1) at the end of each iteration in sendProgmemChunked()
to yield to the scheduler between chunks, allowing the IDLE task to reset
the watchdog and preventing spurious reboots during web panel page loads.
The hardcoded kWebPageChunkSize of 768 bytes caused the task watchdog
to trigger when serving the web panel over HTTPS. Each call to
httpd_resp_send_chunk() results in a separate TLS record encryption
via mbedTLS, which on ESP32-S3 uses DMA-backed AES-GCM (esp_aes_process_dma).
The gdma_disconnect() call inside that path enters a critical section,
blocking the IDLE0 task. With 768-byte chunks, a large page response
requires many such DMA operations in tight succession, starving the IDLE
task long enough to trip the watchdog.
Replacing the hardcoded value with MBEDTLS_SSL_OUT_CONTENT_LEN aligns the
chunk size to the TLS output record buffer, minimising the number of TLS
records (and thus DMA encryption operations) needed to send a full page,
and keeping the httpd task within the watchdog timeout.
Fixes: task_wdt abort in sendProgmemChunked() -> httpd_ssl_send() ->
esp_aes_process_dma() -> gdma_disconnect() on ESP32-S3.
Browsers negotiate ECDHE cipher suites by default. On ESP32-S3 the
hardware RSA accelerator handles RSA key exchange efficiently, but
there is no ECP hardware accelerator. ECDHE requires the server to
compute an ephemeral key pair: ecp_precompute_comb() builds a comb
table through many sequential ECP point doublings, each dispatched
to the hardware bignum unit (esp_bignum.c), but the ECP layer has
no RTOS yield points between iterations. The entire computation runs
to completion on CPU 0 without ever resetting the task watchdog.
A single handshake does not exceed the watchdog timeout on its own,
but two consecutive handshakes (e.g. a browser retry after a failed
attempt) accumulate enough uninterrupted runtime to starve IDLE0:
E (54924) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x0050
E (57208) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x7280
E (57638) task_wdt: Task watchdog got triggered.
E (57638) task_wdt: - IDLE0 (CPU 0)
E (57638) task_wdt: Tasks currently running:
E (57638) task_wdt: CPU 0: httpd
The crash occurs in ecp_precompute_comb() → ecp_double_jac() →
mbedtls_mpi_mul_mpi() during the ServerKeyExchange step.
Fix by wrapping mbedtls_ssl_config_defaults() via the linker --wrap
mechanism. The wrapper intercepts server-side SSL config init
(MBEDTLS_SSL_IS_SERVER) and replaces the cipher suite list with
RSA key exchange only, routing handshakes through the hardware RSA
accelerator and eliminating the ECDH path entirely. MQTT connections
(MBEDTLS_SSL_IS_CLIENT) are unaffected.
Also switch the self-signed cert generator from EC (prime256v1) to
RSA 2048 so the generated certificate matches the restricted cipher
suites.
Changes:
- arch/esp32/tls_cipher_restrict.c: new file implementing the
mbedtls_ssl_config_defaults wrap; restricts server cipher suites
to RSA_WITH_AES_{128,256}_{GCM,CBC}_SHA{256,384}
- platformio.ini: add -Wl,--wrap=mbedtls_ssl_config_defaults and
include tls_cipher_restrict.c in the esp32_base build
- arch/esp32/extra_scripts/generate_web_panel_cert.py: switch key
generation from `openssl ecparam -name prime256v1` to `openssl
genrsa 2048`
On dual-core ESP32-S3 (ARDUINO_RUNNING_CORE=1), the Arduino loop and
LoRa processing run exclusively on core 1. ESP-IDF v4 creates mqtt_task
with tskNO_AFFINITY, meaning FreeRTOS may schedule them on core 1 under
load, preempting the LoRa loop.
ESP-IDF v4 provides no public API to change a task's core affinity after
creation (vTaskCoreAffinitySet is IDF v5+ only), and the esp_mqtt_client
config struct has no task_core_id field. The precompiled Arduino-ESP32
framework cannot be patched via sdkconfig.
Instead, use the GCC/LD --wrap linker mechanism to intercept every call
to xTaskCreatePinnedToCore. Any task created with tskNO_AFFINITY is
redirected to core 0. Tasks that are already explicitly pinned (Wi-Fi
driver, LwIP, httpd, esp_timer, ipc0/ipc1) are passed through unchanged.
We intentionally do not filter by task name. Pinning all unpinned tasks
makes the approach robust against internal ESP-IDF task name changes and
catches any future tasks that may be added with tskNO_AFFINITY.
Verified task layout after the change:
loopTask pri=1 core=1 (Arduino loop / LoRa — unchanged)
mqtt_task pri=5 core=0 (was tskNO_AFFINITY, now pinned)
httpd pri=2 core=0 (core_id set explicitly in WebPanelServer)
tiT pri=18 core=0 (LwIP, already pinned by ESP-IDF)
wifi pri=23 core=0 (Wi-Fi driver, already pinned)
esp_timer pri=22 core=0 (already pinned)
ipc0/ipc1 pri=24 core=0/1 (IPC, already pinned per-core)
The -Wl,--wrap flag and arch/esp32/task_pinning.c are added only to
[esp32_base] (IDF v4). The ESP32-C6 pioarduino target (IDF v5) is
unaffected and can use vTaskCoreAffinitySet() if needed in the future.
Set task_priority = tskIDLE_PRIORITY + 2 and core_id = 0 for both the
HTTPS server and the HTTP-to-HTTPS redirect server. This keeps web
serving off core 1, which handles radio and application logic, reducing
interference with time-sensitive operations.
_have_time_sync is reset to false whenever WiFi disconnects, even
though the ESP32 RTC continues to hold accurate time after a
successful SNTP sync. This caused hasTimeSync() to return false
during transient WiFi outages, unnecessarily tearing down MQTT
broker connections and suppressing packet publishing.
Introduce _last_time_sync to record the wall-clock time of the
most recent confirmed sync. Move hasTimeSync() out of the header
into NetworkService.cpp and extend its logic: in addition to the
existing _have_time_sync flag, return true if the system clock is
still sane (>= kMinSaneEpoch) and no more than kMaxOutOfSync (24h)
has elapsed since the last confirmed sync.
This makes the MQTT uplink resilient to brief WiFi dropouts without
requiring any changes to callers of hasTimeSync().
Also bump kMinSaneEpoch from 2025-01-01 to 2026-01-01.
