deploy: fdad79eaf7

fleet_management/index.html

@@ -1360,6 +1360,23 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="Supported controls">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#two-packet-delivery" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Two-packet delivery
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -2350,6 +2367,23 @@
     </span>
   </a>
   
+    <nav class="md-nav" aria-label="Supported controls">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#two-packet-delivery" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Two-packet delivery
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -2457,7 +2491,9 @@ get fleet.stats
 last accepted sequence. It does not reveal the channel key. <code>set fleet.channel
 off</code> disables reception; <code>set fleet.controller off</code> revokes the publisher. Key
 changes use the existing individually authenticated admin path, never fleet
-commands.</p>
+commands.
+<code>get fleet.stats</code> includes <code>parts</code>, the number of fragments currently buffered
+for an incomplete two-packet command.</p>
 <p>Nodes need a clock set to current UTC. Commands expire after ten minutes and may
 be at most one minute ahead of a receiver's clock. A bad clock fails closed;
 correct it through the normal administration path.</p>
@@ -2492,10 +2528,9 @@ command only once, and the signature protects the entire list.</p>
 <p>On air, full keys use a 128-bit SHA-256 digest; prefixes use their original
 public-key bytes. Whole-fleet commands use the compact FMC2 format with no target
 records, whether the CLI target is omitted or explicitly <code>all</code>. This reduces the
-header from 29 to 14 bytes. Whole-fleet, multiple-target, and prefix commands
-require receivers that support FMC2. A single complete key keeps the legacy FMC1
-format, and updated receivers also accept legacy whole-fleet packets. Separate
-fleets use separate channel keys; named subgroups are not part of this first version.</p>
+header from 29 to 14 bytes. A single complete key uses the smaller fixed-target
+FMC1 format. Separate fleets use separate channel keys; named subgroups are not
+part of this first version.</p>
 <p>Only local commands on the publishing Companion can originate fleet sends. A
 remote CLI command cannot turn that Companion into a multicast signing proxy.
 An <code>OK</code> means the Companion queued the command, not that every receiver applied
@@ -2505,18 +2540,79 @@ durable storage <strong>before</strong> dispatch. The same sequence is never exe
 including after reboot or a lost reply. Retry an uncertain command with a fresh
 sequence; the operation should be chosen to be idempotent.</p>
 <h2 id="supported-controls">Supported controls</h2>
-<p>The command body is limited to <strong>72 ASCII bytes</strong>. Targets and command must also
-fit one signed <strong>165-byte envelope</strong>. An 8-character target uses 5 bytes, a
-12-character target uses 7, and a complete key uses 17. The fixed envelope and
-signature use 78 bytes, leaving 87 bytes for the target list and command together.
-For example, two complete keys leave 53 bytes for the command. Lists are capped
-at 17 entries; packet-size limits usually allow fewer. Omitting targets or using
-<code>all</code> saves 15 header bytes; the command limit remains 72 bytes. A single complete
-key uses the legacy 29-byte header and also allows a full 72-byte command.
-The local app/console's command-length limit also applies. Oversized or invalid
-lists are rejected as a whole, without sending or truncating any targets.
-The short legacy USB rescue console cannot fit a full-key command; use the app
-or normal terminal for longer lists.</p>
+<p>The Companion automatically uses <strong>one or two LoRa packets</strong>, depending on the
+signed command's size. Whole-fleet commands fit <strong>87 ASCII bytes</strong> in one packet
+or <strong>230 bytes</strong> across two. Targets consume some of that allowance:</p>
+<table>
+<thead>
+<tr>
+<th>Targets</th>
+<th style="text-align: right;">One packet: command bytes</th>
+<th style="text-align: right;">Two packets: command bytes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Omitted or <code>all</code></td>
+<td style="text-align: right;">87</td>
+<td style="text-align: right;">230</td>
+</tr>
+<tr>
+<td>One 8-character public-key prefix</td>
+<td style="text-align: right;">82</td>
+<td style="text-align: right;">225</td>
+</tr>
+<tr>
+<td>One 12-character public-key prefix</td>
+<td style="text-align: right;">80</td>
+<td style="text-align: right;">223</td>
+</tr>
+<tr>
+<td>One complete 64-character public key</td>
+<td style="text-align: right;">72</td>
+<td style="text-align: right;">215</td>
+</tr>
+<tr>
+<td>Two 8-character public-key prefixes</td>
+<td style="text-align: right;">77</td>
+<td style="text-align: right;">220</td>
+</tr>
+<tr>
+<td>Two complete public keys</td>
+<td style="text-align: right;">53</td>
+<td style="text-align: right;">196</td>
+</tr>
+</tbody>
+</table>
+<p>Each prefix in a list uses 5 or 7 bytes; each complete key in a list uses 17.
+A single complete key uses the smaller fixed-target format with a 29-byte header,
+so its limits come from packet space. Lists are capped at 17 entries. Requests
+exceeding their target-specific budget are rejected before signing or sending,
+with no partial target list.</p>
+<p>The existing app/console input limit also applies. The app's normal 176-byte
+command frame fits <strong>161 command bytes</strong> after <code>fleet send 3</code>; a correlated
+request uses three more bytes, and explicit targets reduce the space further.
+The shorter USB rescue console has an 80-byte input buffer. The 230-byte limit
+is the fleet protocol's capacity, rather than a promise that every console can
+enter that much text. Oversized or invalid lists are rejected as a whole,
+without sending or truncating any targets.</p>
+<h3 id="two-packet-delivery">Two-packet delivery</h3>
+<p>Longer commands keep <strong>one 64-byte signature over the entire command</strong>, including
+its channel, targets, sequence and expiry. The signed envelope is split into two
+<code>FMP1</code> fragments. Each fragment has an 11-byte collection header and up to 154
+envelope bytes, within the existing 165-byte group-data limit. Together they can
+carry a 308-byte signed envelope. No third packet is used.</p>
+<p>The Companion reserves both packets before sending. If either cannot be queued,
+it cancels the queued part and any radio copy, reports an error, and leaves the
+sequence available for a retry. Successful queueing still does not guarantee
+delivery over LoRa.</p>
+<p>A receiver accepts either arrival order and identical duplicates. It executes
+and acknowledges <strong>only after both parts arrive and the complete signature,
+target, clock and replay checks pass</strong>. Missing or altered parts cannot execute
+a partial command. One bounded assembly is kept for up to five minutes from the
+first part; duplicates do not extend that deadline. A fresh command with a newer
+eligible sequence replaces an incomplete older transfer, so a lost part does
+not block retries. Reboot or changing enrollment discards the partial transfer.</p>
 <table>
 <thead>
 <tr>
@@ -2627,7 +2723,7 @@ recovery path before changing network-wide filters. Primary-radio schedules can
 move nodes off the normal network; use a temporary window or a planned recovery
 path for experiments. A forwarding policy can also partition the fleet.</p>
 <p>The receiver is allocated lazily when fleet settings are present or queried, with
-one bounded mailbox. Cryptographic work and storage writes occur after the receive
+one bounded mailbox and one 308-byte fragment assembly. Cryptographic work and storage writes occur after the receive
 stack unwinds. Signature-validation
 attempts are bounded to protect the radio loop from matching-hash junk. A corrupt
 or unreadable fleet store denies commands rather than discarding its replay state.</p>

search/search_index.json

@@ -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>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 Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct onLine 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>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 Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct onLine truncated