mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-11-04 14:27:16 +00:00
deploy: 5a031f7674
This commit is contained in:
mikecarper committed
1 parent
9e392ef699
commit
01c3fb78f9
3 files changed
+88
-15
No files matched your search
@@ -2351,7 +2351,8 @@ single allocation.</p>
|
||||
<h3 id="mqtt-startup-minimum-and-runtime-qualification">MQTT startup minimum and runtime qualification</h3>
|
||||
<p>The <code>mqtt_startup_allowance</code> component keeps a 24,576-byte internal startup
|
||||
minimum for the default 8,192-byte MQTTBridge worker stack and two active
|
||||
clients. Each SDK client task defaults to 6,144 bytes and its maximum configured
|
||||
clients. Each SDK client task is explicitly configured with a 6,144-byte stack
|
||||
and priority 5 on IDF 4 and 5; its maximum configured
|
||||
receive/transmit buffers total 1,792 bytes. These stacks and buffers total
|
||||
24,064 bytes for two clients, leaving 512 bytes within the existing allowance.
|
||||
This is a minimum allowance, not a complete allocation bound for the clients,
|
||||
@@ -2375,8 +2376,16 @@ in these build reports. A <code>passed</code> startup check must not be presente
|
||||
qualification of five simultaneous PSRAM connections or two internal TLS
|
||||
connections.</p>
|
||||
<p>The <code>mqtt</code> report also names the production runtime admission thresholds.
|
||||
Each attempt requires at least 16 KiB of DMA-capable internal free heap and a
|
||||
4 KiB contiguous DMA block. A TLS attempt without PSRAM requires at least
|
||||
A cold SDK start requires at least 32 KiB of DMA-capable internal free heap
|
||||
and an 8 KiB contiguous DMA block. This includes a separate 16 KiB allowance
|
||||
for its SDK task stack/TCB, receive/transmit/reassembly buffers and transport
|
||||
or configuration objects, alongside the 16 KiB AES reserve. Those ordinary
|
||||
SDK allocations occur after admission and do not use the TLS allocation guard.
|
||||
A retained SDK handle with a stopped task receives the same cold allowance.
|
||||
A warm reconnect keeps its running task and buffers; it requires at least
|
||||
16 KiB free and a 4 KiB contiguous DMA block. The per-client SDK stack is
|
||||
independent of <code>MQTT_TASK_STACK_SIZE</code>, which sizes the existing bridge worker.
|
||||
A TLS attempt without PSRAM requires at least
|
||||
60 KiB free and a 17,408-byte contiguous block. PSRAM allocation fallback must
|
||||
leave the 16 KiB DMA reserve available. These thresholds describe free heap at
|
||||
the time of admission; they are not additional linked capacity and the TLS
|
||||
|
||||
@@ -1 +1 @@
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated
|
||||
@@ -2299,8 +2299,12 @@ room-server and companion images that enable it.</p>
|
||||
<li>Schedule initial connections through the normal maintenance loop. Check
|
||||
the actual pending attempt across SDK tasks, rather than assuming a
|
||||
five-second startup delay or 15-second reconnect gap finished a handshake.</li>
|
||||
<li>Defer a new connection if DMA-capable internal memory has less than
|
||||
16 KiB free or a largest block below 4 KiB. TLS without working PSRAM
|
||||
<li>Reserve 32 KiB free DMA-capable internal memory and an 8 KiB largest block
|
||||
before starting an SDK client task. This includes a 16 KiB startup allowance
|
||||
above the 16 KiB AES reserve. Retained, running clients need 16 KiB free and
|
||||
a 4 KiB largest block to reconnect. Pin SDK client tasks to their existing
|
||||
6,144-byte default stack; the separate bridge worker remains 8 KiB.
|
||||
TLS without working PSRAM
|
||||
additionally needs 60 KiB free and a 17 KiB largest block. These are
|
||||
conservative admission bounds, not a promise that future allocations succeed.</li>
|
||||
<li>Prefer PSRAM for TLS allocations and reject an internal fallback that
|
||||
@@ -2310,6 +2314,9 @@ room-server and companion images that enable it.</p>
|
||||
<li>Require byte-addressable internal memory for string/JSON/queue buffer
|
||||
fallbacks. The internal-memory capability alone also admits instruction RAM
|
||||
that only supports aligned 32-bit access.</li>
|
||||
<li>Count broker QoS acknowledgments separately from accepted writes and expose
|
||||
them as <code>pub_ack</code> in <code>get mqttN.diag</code>. This lets hardware tests verify
|
||||
delivery without treating an expired outbox entry as an acknowledgment.</li>
|
||||
<li>Add DMA free/largest readings to <code>get mqtt.stats</code> and diagnostic logs.
|
||||
Correct the operator-facing TLS error labels against SDK constants.</li>
|
||||
</ul>
|
||||
@@ -2323,15 +2330,72 @@ controlled SDK calls and heap readings. They cover IDF 4/5 config layouts,
|
||||
PSRAM and internal-only modes, fragmented heap, exhausted PSRAM, delayed
|
||||
connection callbacks, retry timing and bounded replies. They do not execute
|
||||
an ESP32 AES peripheral or qualify physical WiFi behavior.</p>
|
||||
<p>All 1,794 native tests and the 31 memory-budget tests passed. The focused
|
||||
MQTT tests are also connected to the GitHub unit-test workflow.</p>
|
||||
<p>The VM reached both reported broker TLS endpoints with certificate
|
||||
verification enabled. That is an endpoint check, not an ESP32 MQTT test.</p>
|
||||
<p>MercerWoodMesh reported offline and its SSH connection timed out during this
|
||||
run. No live V4 flash, MQTT publication or soak result is claimed. The next
|
||||
hardware check must exercise the reported WSS presets together, verify rising
|
||||
publish counters and DMA headroom, then include a broker/WiFi reconnection
|
||||
and power-saving idle run with no reset or AES allocation error.</p>
|
||||
<p>All 43 focused Python MQTT tests, 1,794 native tests and 31 memory-budget tests
|
||||
passed. The focused MQTT tests are also connected to the GitHub unit-test
|
||||
workflow.</p>
|
||||
<p>Three Full MQTT repeater builds with USB packet logging passed on 10 October
|
||||
2026 at revision <code>7acc63746</code>. Their build logs report:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Build</th>
|
||||
<th style="text-align: right;">Application flash bytes</th>
|
||||
<th style="text-align: right;">Available internal heap bytes</th>
|
||||
<th style="text-align: right;">Required heap bytes</th>
|
||||
<th style="text-align: right;">Largest internal region bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Heltec V4</td>
|
||||
<td style="text-align: right;">2,182,125</td>
|
||||
<td style="text-align: right;">205,080</td>
|
||||
<td style="text-align: right;">198,432</td>
|
||||
<td style="text-align: right;">172,312</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Heltec V3</td>
|
||||
<td style="text-align: right;">2,125,149</td>
|
||||
<td style="text-align: right;">211,296</td>
|
||||
<td style="text-align: right;">209,184</td>
|
||||
<td style="text-align: right;">178,528</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Station G2</td>
|
||||
<td style="text-align: right;">2,017,685</td>
|
||||
<td style="text-align: right;">201,280</td>
|
||||
<td style="text-align: right;">200,480</td>
|
||||
<td style="text-align: right;">168,512</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Application flash is the PlatformIO size-check reading. Internal heap is
|
||||
linked capacity before dynamic allocation, not free heap measured after boot.
|
||||
All three RAM gates passed the startup policy; they do not qualify maximum
|
||||
TLS/WSS/outbox load. The default MQTT startup allowance remains 24,576 bytes,
|
||||
with runtime admission for additional connections. See
|
||||
<a href="../../research/firmware_memory_budget/#mqtt-startup-minimum-and-runtime-qualification">firmware memory checks</a>
|
||||
for the separate maximum-slot estimate and qualification limits.</p>
|
||||
<p>Live TLS 1.2 certificate chains from 12 audited preset endpoints were
|
||||
verified with the exact CA PEMs extracted from <code>MQTTPresets.h</code> using a native
|
||||
host build of the pinned mbedTLS 2.28.7 submodule from ESP-IDF 4.4.7, commit
|
||||
<code>2b8e772fc1cb0732cda3bae7d1e9d6f4cfaf63d9</code>. Hostname verification was enabled.
|
||||
All 11 GTS Root R4 endpoints and the ISRG Root X1 Cascadia endpoint returned
|
||||
verification result 0 and flags <code>0x00000000</code>. Wrong-hostname and unrelated-anchor
|
||||
negative checks were rejected. WAEV also passed with the server root omitted
|
||||
from its supplied chain.</p>
|
||||
<p>The existing cross-signed GTS Root R4 PEM is a valid trust anchor for that
|
||||
pinned mbedTLS verifier. Ordinary OpenSSL root-only verification rejected it,
|
||||
while partial-chain verification with the same PEM passed all 11 GTS endpoints.
|
||||
This host-probe policy difference does not establish a firmware CA failure or
|
||||
require a CA replacement for the reported AES allocation errors. The verifier
|
||||
used the native default mbedTLS configuration; this establishes pinned X.509
|
||||
chain and trust-anchor behavior, not an ESP32 hardware handshake.</p>
|
||||
<p>MercerWoodMesh is now reachable and live V4 testing is in progress. Live flash,
|
||||
MQTT publication, reconnect and soak outcomes remain pending. The hardware
|
||||
check must exercise the reported WSS presets together, verify rising publish
|
||||
counters and DMA headroom, then include a broker/WiFi reconnection and
|
||||
power-saving idle run with no reset or AES allocation error.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user