deploy: 633e27f43f

cli_commands/index.html

@@ -3137,6 +3137,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#view-repeater-login-attempts" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        View repeater login attempts
+      
+    </span>
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -6173,6 +6184,17 @@
     </span>
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#view-repeater-login-attempts" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        View repeater login attempts
+      
+    </span>
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -11106,6 +11128,36 @@ They indicate an accepted session, not whether the guest is currently online.
 Entries can move between pages as clients change. A reboot or <code>set guest off</code>
 clears them.</p>
 <hr />
+<h4 id="view-repeater-login-attempts">View repeater login attempts</h4>
+<p><strong>Usage:</strong></p>
+<ul>
+<li><code>get logins</code> - first page</li>
+<li><code>get logins &lt;page&gt;</code> - a numbered page, starting at 1</li>
+</ul>
+<p>Available on repeaters through local administrative consoles, an authenticated
+remote admin session, or enrolled <a href="../fleet_management/">signed fleet commands</a>.
+Guests and delegated region/filter managers cannot read this list.</p>
+<p>The repeater keeps the 16 most recently attempted public keys in RAM, with the
+newest attempt first. Each row shows only the first <strong>12 hexadecimal characters</strong>
+of the key, the latest attempt's UTC epoch time, its result, and an attempt count.
+There are up to two rows per page. Attempts for the same full key update its
+existing row and count; the oldest key is replaced when the list is full.
+The count stops at 4,294,967,295. Two different keys can share
+the displayed prefix; their records and counts remain separate.</p>
+<pre><code class="language-text">Logins 1/1 (2)
+ABCDEF123456 n=3 last=1792600000 accepted
+123456ABCDEF n=1 last=1792599900 guests-disabled
+</code></pre>
+<p>Results are <code>accepted</code>, <code>wrong-password</code>, <code>guests-disabled</code>, <code>replay/state</code>, and
+<code>acl-unavailable</code>. An accepted login can be an admin, an assigned ACL client,
+or a guest. This history records
+actual login requests after packet authentication; anonymous owner, region, and
+clock requests, incomplete requests, and packets that fail authentication do not
+appear. Passwords and shared secrets are never recorded.</p>
+<p>This is recent attempt history, not a list of online users or a complete audit
+log. Pages can change as attempts arrive. A reboot clears it; <code>set guest off</code>
+does not. A zero timestamp means the clock was not set when the attempt arrived.</p>
+<hr />
 <h4 id="recover-a-repeaters-future-dated-replay-timestamp">Recover a repeater's future-dated replay timestamp</h4>
 <p>This is an explicit recovery operation after correcting a bad clock, not a
 contact deletion. It lowers selected replay timestamps to the repeater's

fleet_management/index.html

@@ -2921,6 +2921,10 @@ Reboot or changing enrollment discards the partial transfers.</p>
 <td><code>get guests [page]</code></td>
 </tr>
 <tr>
+<td>Repeater login attempts</td>
+<td><code>get logins [page]</code></td>
+</tr>
+<tr>
 <td>Filter rules</td>
 <td><code>get/set/del flood.filter[.n]</code>, <code>flood.rule[.n]</code></td>
 </tr>
@@ -2952,6 +2956,15 @@ installation, reboot, and unrestricted CLI are outside fleet capability.</p>
 <p>Repeater guest login defaults to off. <code>set guest off</code> saves that choice and
 clears existing guest sessions immediately. Enabling it uses the existing
 guest password; this switch does not change any password or assigned ACL role.</p>
+<p><code>get logins [page]</code> returns recent repeater login attempts, two per page, showing
+only 12-character public-key prefixes, latest UTC epoch times, results, and
+attempt counts. The 16 most recently attempted full keys are kept in RAM;
+repeated attempts update the existing key's record. Results distinguish accepted
+logins, wrong passwords, disabled guests, replay/state rejection, and unavailable
+ACL capacity. The history clears on reboot and survives <code>set guest off</code>.
+It contains no passwords or shared secrets and is not an online-user list.
+Anonymous owner, region, and clock requests and packets that fail authentication
+are excluded. Ordinary channel messages cannot read this list.</p>
 <p><code>set radio2 mediamesh</code> saves 911.150 MHz, 250 kHz, SF7, CR 4/5, <code>rxtx</code>,
 with automatic scan-aware preamble. <code>mediamesh-range</code> uses 125 kHz instead.
 These presets preserve the primary profile and crossing policy; new

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>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

terminal_chat_cli/index.html

@@ -2619,6 +2619,10 @@ the corresponding feature:</p>
 <td><code>get guest</code>, <code>set guest on</code>, <code>set guest off</code>, <code>get guests [page]</code></td>
 <td>Repeater guest-login control and current guest sessions</td>
 </tr>
+<tr>
+<td><code>get logins [page]</code></td>
+<td>Recent repeater login attempts, with 12-character public-key prefixes</td>
+</tr>
 </tbody>
 </table>
 <p>The command text is the same for direct connections. A binary Companion app
@@ -3098,6 +3102,18 @@ repeater's guest entries. Each page shows one full public key and its last
 activity time in UTC epoch seconds. Guests are held in RAM, so this is a list of
 accepted sessions rather than proof that a device is currently reachable. They
 are cleared by a reboot or <code>set guest off</code> and remain separate from <code>get acl</code>.</p>
+<p>Use <code>cmd get logins</code> or <code>cmd get logins 2</code> from an admin session to inspect recent
+login attempts. The repeater retains up to 16 distinct public keys in RAM, newest
+attempt first, with up to two rows per page. Each row shows a 12-character hex
+key prefix, the latest UTC epoch time, result, and attempt count. Repeated
+attempts update the same full key's row; different keys sharing a displayed
+prefix remain separate records.</p>
+<p>Results distinguish accepted logins, wrong passwords, disabled guests,
+replay/state rejection, and unavailable ACL capacity. Only authenticated,
+complete login requests are recorded; anonymous owner, region, or clock requests
+are excluded. Passwords and shared secrets are never stored. This bounded
+history clears on reboot, survives <code>set guest off</code>, and does not show who is
+currently online. A zero timestamp means the node's clock was unset.</p>
 <p>The exact commands and permissions depend on the target firmware. <code>cmd</code> does
 not run a command on the local Companion; it sends the text over LoRa to the
 selected node.</p>