Share the saved admin password across ESP32 management services

Use the committed node credential for setup WiFi, WebConfig and browser OTA. Add persistent ESP32 WiFi Companion management credentials without changing preferences layouts, revoke stale browser sessions on rotation, retain scoped save receipts, and coordinate credential changes with flash uploads. Keep external-service credentials and trusted TCP protocol compatibility independent. Update live join QR codes, failure handling and documentation.

Validated 51 native cases, 158 related host and browser methods, and serial Full V4 Companion, Station G3 Repeater, ESP32-C6 Room Server and V4 Sensor firmware builds.

docs/WiFi.md

@@ -148,19 +148,39 @@ The bootstrap uses ES5 syntax and Promise-based loading, including on Android
 Most full-size ESP32 MQTT observer builds have the shared WebConfig portal. On a
 fresh device with no saved SSID:
 
-1. Join the open `MeshCore-Setup-XXXX` access point.
+1. Join `MeshCore-Setup-XXXX` with the node's admin password (factory default
+   `password`). A display's WiFi QR code uses the hotspot's current credential.
 2. If the captive page does not open, browse to `http://192.168.4.1/`.
 3. Enter WiFi, radio, identity, and MQTT settings.
 4. Select **Save & Reboot**.
 5. After reboot, check `get wifi.status` and `get mqtt.status`.
 
-First-time provisioning with no saved SSID does not require a portal admin
-login. A setup AP opened with a saved SSID, including saved-network recovery,
-requires the existing admin password before changing settings. Repeater and
-room-server builds also require that password on the normal LAN; deliberately
-passwordless images retain their no-password policy. `WEBCONFIG_AP_PASSWORD`
-controls access to the WiFi network separately. The portal uses plain HTTP, so
-use a trusted network.
+ESP32 management uses one saved admin password for WebConfig login, browser
+firmware uploads, and setup WiFi. Choose 8–15 printable ASCII characters so the
+hotspot can use it for WPA2. Other valid admin passwords (1–15 UTF-8 bytes,
+without CR or LF) leave the hotspot open and require an HTTP admin login.
+There is no separate setup WiFi password. A protected first-time setup AP with
+no saved SSID retains its provisioning flow; recovery with a saved SSID requires
+the existing admin login. Deliberately passwordless images retain their local
+no-password policy. The portal uses plain HTTP, so use a trusted network.
+
+Changing the password ends existing browser sessions after the save succeeds.
+The submitting page keeps the save result and tries the new password once,
+then asks you to sign in if needed. A partial save shows which settings failed
+and does not reboot. If the setup hotspot restarts, reconnect with the new
+password when it is eligible for WPA2. An unconfirmed password save keeps the
+previous runtime password active, but the saved state after reboot may differ;
+read the reported error before retrying.
+
+Credentials for other systems or different permissions remain separate:
+
+| Credential | Why it does not become the node admin password |
+|---|---|
+| Router WiFi and MQTT broker login | These are issued by the network or broker, which may serve many devices. |
+| Bluetooth pairing PIN | BLE pairing requires its numeric PIN format. |
+| Guest and room passwords | Members and guests should not receive node administration access. |
+| Channel, bridge, fleet and alert keys | These are shared with peers or recipients and have their own protocol requirements. |
+| SNMP community and management-report credentials | Monitoring systems receive these credentials; they should not also receive the node admin password. |
 
 Admin login limits apply on both LAN and recovery AP: five failures lock the
 failing address for 30 seconds after its fifth failure. All addresses also share
@@ -442,9 +462,11 @@ of running both. On a WiFi-selected boot, the LoRa layout accepts
 accepts `min|max` for the saved WiFi setting, while ESP-NOW + BLE requires
 `min`. Device power saving remains independent of this modem policy.
 
-WiFi companions do not have the repeater/room-server admin CLI password model,
-so their LAN WebConfig page is intentionally unauthenticated. Use them only on
-a trusted LAN.
+ESP32 WiFi Companions also have a saved admin password for LAN WebConfig and
+browser OTA, initially `password`. Their `get password` command reports status
+without revealing it. The credential is stored in NVS alongside the WiFi
+settings and survives a filesystem erase. Use `password <new_password>` through
+an available administrative connection to change it.
 
 The WebConfig **Advanced** card exposes device power saving on WiFi Companion,
 repeater, and room-server builds. It also exposes RX power saving on radio chips
@@ -496,9 +518,12 @@ motatool serve --dir ./motas --tcp <repeater-ip>:5001 -v
 
 The TCP connection supplies `.mota` files for the node to advertise and relay
 over LoRa; it is not a raw `.bin` uploader. `start ota` continues to provide the
-direct browser uploader on HTTP port 80. A FULL role without WebConfig but with
-browser OTA support can use the `MeshCore-OTA` access point raised by
-`start ota`; its seeder address is `192.168.4.1:5001`.
+direct browser uploader on HTTP port 80. Sign in with HTTP Basic username
+`admin` and the node's current admin password. A FULL role without WebConfig
+but with browser OTA support can use the `MeshCore-OTA` access point raised by
+`start ota`; its seeder address is `192.168.4.1:5001`. The runtime OTA hotspot
+uses the same WPA2 eligibility rule as setup WiFi. Temporary partition migration
+and recovery applications retain their own documented access policy.
 
 For browser uploads from an existing 1.17.1.8 ESP32 node, see the
 [1.17.1.9 WiFi upgrade guide](upgrading_1.17.1.8_to_1.17.1.9.md).
@@ -511,6 +536,10 @@ removes the TCP folder. Port 5001 has no login layer, so expose it only on a
 trusted LAN or temporary setup network. Firmware target and hash checks still
 apply at the receiving node, along with its configured signature/trust policy.
 
+The HTTP admin login does not protect trusted TCP consoles or delegated remote
+CLI access. Those administrative paths can change the node's admin password;
+limit them to trusted users and networks.
+
 When the shared seeder is running, `get wifi.status` appends its live state:
 
 ```text
@@ -840,8 +869,9 @@ Common causes are:
 - the wrong firmware role or an older compact-CLI build without WebConfig.
 
 For a WiFi companion, find its station IP in the router, connect the client to
-TCP port 5000, and use the open `MeshCore-Setup-XXXX` AP at
-`http://192.168.4.1/` if it cannot join the saved network. Current firmware
+TCP port 5000, and use the `MeshCore-Setup-XXXX` AP at
+`http://192.168.4.1/` if it cannot join the saved network. The hotspot uses the
+admin password when eligible for WPA2, as described above. Current firmware
 uses standard b/g/n for the setup AP, including ESP-NOW-capable targets.
 A running LR mesh conflicts with a conventional access point; current firmware
 refuses that AP startup and defers LR startup while an AP is active. A primary

docs/cli_command_availability.md

@@ -100,7 +100,8 @@ over the normal binary USB, BLE, or TCP connection:
 | `set freq <MHz>` | Local terminal, binary command `0x42`, and authorized LoRa CLI; reboot to apply |
 | [`get public.key`](cli_commands.md#view-this-nodes-public-key) | Companion text terminal and binary command `0x42`; read-only, no private-key export feature required |
 | `get prv.key` | Local terminal and binary command `0x42`; requires private key export enabled |
-| `get password` | Reports that Companion has no admin password; infrastructure returns its password locally |
+| `get password` | ESP32 WiFi Companion reports management-password status without revealing it; other Companions report no admin password; infrastructure returns its password locally |
+| `password <new-password>` | ESP32 WiFi Companion and infrastructure: change the saved admin password; ESP32 setup WiFi, WebConfig and browser OTA reuse it |
 | [`get/set lost.reply`](companion_lost_reply.md) | Local Companion CLI and framed command `0x42` when `MESH_ENABLE_LOST_REPLY` is enabled; saved `off`, `no` or `yes` private-message auto response |
 | `get wifi.pwd`, `get mqttN.password`, `get mqttN.token` | Local terminal and binary command `0x42`; corresponding WiFi/MQTT feature required |
 | [`board`](cli_commands.md#show-the-hardware-name) | Every Companion text terminal and command `0x42` |

docs/cli_commands.md

@@ -266,6 +266,12 @@ access point. The reply gives the URL to open and tells you which network to
 use. `start ota ap` always selects the access point, including when OTA is
 already running on a LAN address. This is useful with client-isolated networks.
 
+The runtime browser uploader uses HTTP Basic authentication: username `admin`,
+password the node's saved admin password. The OTA hotspot reuses that password
+for WPA2 when it is 8–15 printable ASCII characters; otherwise it is open and
+the HTTP login still applies. Temporary partition migration and recovery apps
+retain their documented access policy.
+
 Starting OTA automatically stops WebConfig and reports `WebConfig stopped` in
 the reply. The existing LAN connection stays up; a setup hotspot is replaced
 by `MeshCore-OTA`. WebConfig's delayed HTTP cleanup cannot stop OTA's WiFi.
@@ -318,15 +324,18 @@ off while a temporary WebConfig session is currently active at that URL.
 It serves the shared WiFi, radio, flood, loop, and status page and reports its
 URL. MQTT builds also show the MQTT tab and wizard step; non-MQTT builds remove
 them entirely. Sign in with the node's admin password. If the node has no saved
-WiFi SSID, the command starts the open `MeshCore-Setup-XXXX` captive AP at
+WiFi SSID, the command starts the `MeshCore-Setup-XXXX` captive AP at
 <http://192.168.4.1/> instead.
 
 If a saved WiFi network is unavailable and the node falls back to its setup
 AP, sign in with the existing admin password before changing settings. Joining
-that AP does not grant permission to replace the password. First-time setup
-without a saved SSID keeps its AP provisioning flow. Images deliberately
-configured without an admin password, including passwordless Companions,
-retain their local no-password policy; use them only on a trusted network.
+that AP does not grant permission to replace the password. The hotspot uses
+the same admin password for WPA2 when it is 8–15 printable ASCII characters.
+Other valid admin passwords leave the hotspot open and require the HTTP admin
+login. Protected first-time setup without a saved SSID keeps its provisioning
+flow. ESP32 WiFi Companions also have a saved admin password, initially
+`password`. Deliberately passwordless images retain their local no-password
+policy; use them only on a trusted network.
 
 `start webconfig ap` forces captive-AP mode. It will not interrupt an active
 MQTT bridge, so run `set mqtt.enabled off` first. Use `stop webconfig` to
@@ -352,8 +361,8 @@ paused, rather than starting services from saved intent alone.
 Every ESP32 build with WebConfig supports the browser command terminal,
 including WiFi Companion and Full Companion. Companions use their complete
 USB/TCP terminal on the trusted LAN, including contact import, chat, recipient
-selection, and delayed replies. Repeater and Room Server use their local CLI
-after admin authentication.
+selection, and delayed replies. ESP32 roles require their WebConfig admin
+login before browser terminal access; the HTTP login does not protect TCP.
 
 To add a Companion contact, run `import meshcore://<full-contact-card-data>`,
 then `list` to confirm it appears. Get the complete card with `card` on the
@@ -365,9 +374,10 @@ The saved `wifi.cli` setting defaults to `on`. Use `set wifi.cli off` to disable
 the **CLI** tab.
 `get wifi.cli` reports `off`, `on, waiting for WiFi client`, or `on, active`.
 The saved setting becomes active only in station/LAN mode while the WiFi client
-is connected. It is deliberately unavailable on the open setup access point.
+is connected. It is deliberately unavailable on the setup access point.
 The tab displays each reply in the browser, including local diagnostics,
-`get password`, private-key and WiFi/MQTT credential reads, and `erase`.
+infrastructure `get password`, private-key and WiFi/MQTT credential reads, and
+`erase`. ESP32 Companion's `get password` reports status without the secret.
 Infrastructure `get acl` and raw `log` stream to the requesting browser, with
 backpressure for slow clients. These maintenance commands retain their LoRa
 restrictions. `set freq` works both here and through authorized LoRa CLI.
@@ -2172,7 +2182,7 @@ Older Companion firmware is not a safe transport for this backup flow.
 - `password <new_password>`
 
 **Parameters:**
-- `new_password`: New admin password
+- `new_password`: New admin password (on ESP32, 1–15 UTF-8 bytes without CR or LF)
 
 **Set by build flag:** `ADMIN_PASSWORD`
 
@@ -2180,8 +2190,27 @@ Older Companion firmware is not a safe transport for this backup flow.
 
 `get password` returns the current admin password only on a local connection:
 USB, Ethernet, or the authenticated LAN browser CLI. It is rejected over LoRa.
-Companion has no local admin password and reports that explicitly, including
-through binary command `0x42`; this command does not report the Bluetooth PIN.
+ESP32 WiFi Companion instead reports management-password status without revealing
+the secret. Its password is stored in NVS, survives a filesystem erase, and
+defaults to `password`. Other Companion builds retain their existing no-admin
+response. This command does not report the Bluetooth PIN.
+
+On ESP32, empty and overlong new passwords are rejected rather than truncated.
+Leading spaces are part of the password. For ESP32 setup WiFi protection, choose 8–15
+printable ASCII characters; other accepted passwords use an open hotspot with
+an HTTP admin login. WebConfig and runtime browser OTA share this admin
+credential (OTA's HTTP Basic username is `admin`).
+
+A confirmed password change invalidates existing browser sessions. The page
+that submitted it keeps a save receipt, tries the new password once, and reads
+the same result again after login; it does not resend commands. If another
+setting fails, the result remains visible and reboot is withheld. An
+unconfirmed password save keeps the previous runtime password active, but the
+saved state after reboot may differ; the error reports this uncertainty.
+
+Trusted TCP consoles and delegated remote CLI remain administrative paths and
+can change this password. The HTTP credential does not protect those ports or
+replace radio ACL permissions.
 
 **Note:** The password setter replies with confirmation.
 

docs/companion_protocol.md

@@ -305,9 +305,16 @@ Direct USB, BLE, WiFi TCP, and Ethernet clients can also use this command for
 `stats-core`, `stats-radio`, `stats-radio-diag`, `stats-packets`, `erase`,
 and `get prv.key` (when private key export is enabled).
 WiFi/MQTT builds accept `get wifi.pwd`, `get mqttN.password`, and
-`get mqttN.token`. `get password` reports that Companion has no admin password;
-infrastructure roles return their own admin password on a local CLI connection.
-These privileges do not apply to CLI commands relayed over LoRa.
+`get mqttN.token`. On ESP32 WiFi Companion, `get password` reports whether the
+management password is available without revealing it. `password <new-password>`
+changes the saved password shared by setup WiFi, WebConfig and browser OTA.
+Other Companion builds report that they have no admin password; infrastructure
+roles return their own admin password on a local CLI connection.
+These direct-client maintenance and secret-read privileges do not apply to
+CLI commands relayed over LoRa.
+Existing trusted Companion transports and contacts explicitly granted remote
+CLI access retain their command privileges. The browser login does not add a
+password handshake to those transports.
 ESP32 WiFi Companion builds expose the official app's `get/set wifi.enabled`,
 `get/set wifi.ssid`, and `get/set wifi.pwd` controls. Credentials use the shared
 WiFi store, and enablement is saved in node preferences. WiFi/BLE builds apply

docs/companion_radio_full.md

@@ -405,6 +405,8 @@ get wifi.ssid
 get wifi.status
 get wifi.powersave
 get webui
+get password
+password my-admin-pass
 set wifi.ssid MyNetwork
 set wifi.pwd my-password
 set wifi.powersave min
@@ -416,9 +418,20 @@ stop webconfig
 ESP32 WiFi Companions with WebConfig, including Full Companion, expose a
 **CLI** tab at the node's LAN address. It defaults to on; use `get wifi.cli`,
 `set wifi.cli on`, or `set wifi.cli off`. Older builds that report the browser
-terminal as unavailable need a firmware update. The open setup AP does not
+terminal as unavailable need a firmware update. The setup AP does not
 expose this tab.
 
+ESP32 WebConfig and runtime browser OTA share the saved node admin password,
+initially `password`; the OTA HTTP Basic username is `admin`. `get password`
+reports status without revealing it. The password is stored in NVS and survives
+a filesystem erase. New values must be 1–15 UTF-8 bytes without CR or LF. Use
+8–15 printable ASCII characters to protect setup WiFi with the same password;
+otherwise the hotspot is open and requires an HTTP admin login. The display's
+WiFi join QR uses the hotspot's current credential. After a successful change,
+the submitting page keeps its save result and tries the new login once; other
+browser sessions must sign in again. An unconfirmed save keeps the previous
+runtime password active, but the saved state after reboot may differ.
+
 The browser accepts Companion configuration commands, including `get powersaving`,
 `set usb.logging on|off`, WiFi controls, and MQTT settings. `set mqtt.enabled on|off` controls MQTT
 without erasing broker settings; `get mqtt.enabled`, `get mqtt.running`, and
@@ -716,8 +729,12 @@ stealth remains enabled. Repeating `on` keeps an existing bond. Toggle `off`,
 then `on`, then reboot to reset first pairing. All flag changes need reboot.
 The node still sends directed or allowlisted BLE packets; it is not radio silent.
 
-ESP32 ports 5000, 5001, 5002, and WebConfig have no independent login layer.
-Expose them only on a trusted LAN or temporary setup network. See
+ESP32 TCP ports 5000, 5001, and 5002 remain trusted-network services. The HTTP
+admin login protects WebConfig and runtime browser OTA, and does not protect
+these ports or delegated remote CLI. Administrative console access can change
+the admin password. Expose TCP services only on a trusted LAN or temporary
+setup network. Temporary migration/recovery apps retain their documented
+access policy. See
 [WiFi setup](./WiFi.md) for credential setup and reconnect behavior.
 
 ## USB Binary and text terminal modes

docs/terminal_chat_cli.md

@@ -17,7 +17,8 @@ select **CLI**. The browser runs the same commands as the USB terminal and
 Full Companion's TCP terminal on port 5002, including contact import, contact
 selection, messages, remote login/commands, and delayed RF replies. Run `help`
 to list commands compiled into the device. Enable the tab with
-`set wifi.cli on`; the open setup AP does not expose it.
+`set wifi.cli on` and sign in with the node admin password. The setup AP does
+not expose this full terminal.
 
 For example, copy the complete `meshcore://...` string from `card` on another
 Companion, then run these commands on the receiving Companion:
@@ -101,7 +102,8 @@ the corresponding feature:
 | `stats-core`, `stats-radio`, `stats-radio-diag`, `stats-packets` | Runtime diagnostics |
 | `get public.key` | Read-only node identity public key; Companion returns `> ` followed by 64 uppercase hex characters |
 | `get prv.key` | Node identity private key; Companion requires private key export enabled in the build |
-| `get password` | Infrastructure admin password; Companion reports that it has no admin password |
+| `get password` | Infrastructure admin password; ESP32 WiFi Companion reports management-password status without revealing it; other Companions report no admin password |
+| `password <new-password>` | Change the saved admin password on infrastructure and ESP32 WiFi Companion |
 | `erase` | Erase stored identity and settings; reboot for a fresh node |
 | `get wifi.pwd` | Stored WiFi password on WiFi builds |
 | `get mqttN.password`, `get mqttN.token` | Stored credentials for MQTT slot N |
@@ -126,9 +128,12 @@ the binary contacts operations for Companion contacts. Interactive chat
 commands still use the text terminal or their corresponding binary protocol
 operations.
 
-The browser CLI requires station/LAN mode and `wifi.cli on`. Infrastructure
-uses its admin login; Companion uses the trusted LAN. Configuration forms keep
-password fields masked; explicit local CLI getters return their values.
+The browser CLI requires station/LAN mode, `wifi.cli on`, and the node admin
+login. Configuration forms keep password fields masked; explicit local CLI
+getters return their values, except ESP32 WiFi Companion's status-only
+`get password`. Existing USB/BLE/TCP clients and explicitly authorized remote
+CLI contacts retain their administrative command access. HTTP authentication
+does not add a password handshake to the raw TCP services.
 
 ## Companion contact and channel TX profiles