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.
There's no known reason why additional firmware build of this board
with serial logging enabled was needed.
So, removing it for now to optimize building process and cleanup
firmware list.
When the MQTT WebSocket handshake fails before a connection is fully
established (e.g. "Sec-WebSocket-Accept not found"), the IDF v4
transport teardown path writes only 3 of the 4 bytes of the heap block
tail canary (expected 0xbaad5678, actual 0xbaad5600). The subsequent
esp_mqtt_client_destroy() call frees that block, causing multi_heap_free
to detect the broken canary and abort:
CORRUPT HEAP: Bad tail at 0x3fcb42a4. Expected 0xbaad5678 got 0xbaad5600
assert failed: multi_heap_free multi_heap_poisoning.c:259 (head != NULL)
The fix is to check heap integrity with heap_caps_check_integrity_all(false)
between esp_mqtt_client_stop() and esp_mqtt_client_destroy(). If corruption
is detected, scan internal SRAM (0x3FC00000–0x3FD00000) for the truncated
canary pattern and restore it to the correct value before
destroy() runs.
The scan is a no-op when the heap is clean and is compiled out entirely
on IDF v5+, where the underlying bug does not exist.
This fixes crash-on-reconnect observed with ESP32-S3 + IDF v4 + WSS transport.
