ops(meshcentral): diagnose and fix HW Connect stuck at Setup (stale CIRA tunnel); add relay probe

servers/esh-pve-2/README.md

@@ -56,5 +56,11 @@ after). Address disks by `/dev/disk/by-id/…` (serial), never `nvmeXn1`.
   two keep sharing one IP.
 - Power schemes offered: "Mobile: ON in S0" and "ON in S0, ME Wake in S3, S4-5 (AC only)". Not checked which is
   active. Its twin nh3-pve-2 kept its tunnel while powered off (2026-10-02 2221), so this one probably does too.
+- ⚠ **If "HW Connect" sticks at "Setup…" after a power cycle, look for a stale second tunnel** (2026-10-02 2247;
+  fix in `servers/pfi-tacticalrmm/README.md`). Because AMT shares `nic1`, the link drops whenever Linux
+  starts or stops, and AMT can leave its old tunnel half-open.
+- Remote desktop works only while the host is ON (AMT mirrors the iGPU). Power it up from MeshCentral first. AMT
+  itself stays reachable when the host is off (both MS-03s, 2026-10-02 2229).
+- Display: a 1080p HDMI plug is fitted (`HDMI-A-1` connected, 1920x1080, 2026-10-02 2241).
 - **KVM needs an active iGPU output.** A 4K dummy plug blacked the AMT console on nh3-pve-2 once Linux took the
   display; use a 1080p plug.

servers/pfi-tacticalrmm/README.md

@@ -54,6 +54,18 @@ Monitors and manages endpoints, pushes patches, runs scripts, etc.
   has none and its two first connects did not crash. That is inferred, not measured. Reconnects of
   an existing device take the other branch and are safe. **Onboard new AMTs at a quiet hour**; expect one ~7 s
   MeshCentral restart.
+- ⚠ **"HW Connect" stuck at "Setup…" = a stale CIRA tunnel** (2026-10-02 2247, esh-pve-2-amt; Prime power-cycled
+  the host several times). The AMT opened a new tunnel without closing the old one. MeshCentral then held two:
+  the live one (power actions and the AMT manager worked through it) and a dead one, `backoff:14`, nothing
+  received for 782 s. `webrelay.ashx` (KVM, SOL, IDE-R, MeshCommander) picked the dead one. A relay TLS failure
+  is only logged at debug level and never closes the websocket, so the browser waits forever. MPS's 90 s idle
+  timeout did not fire, because MeshCentral's own writes to the dead socket kept resetting it. TCP gives up on
+  its own after ~15–30 min of retransmits.
+  **Fix:** `sudo ss -tnio state established "( sport = :4433 )"`. Find the device's public IP with a large
+  `lastrcv` (ms) or a `backoff`. Healthy tunnels show `lastrcv` of seconds. Then
+  `sudo ss -K -tn "dst [::ffff:<ip>]:<its port>"`. Verify with `scripts/meshcentral-amt-relay-probe.js`, using
+  another AMT as a positive control. Likely whenever a host whose AMT shares its NIC (esh-pve-2) power-cycles.
+  Seen once so far.
 - Before 2026-10-02: `"WANonly": true` (TacticalRMM's install default). In that mode MeshCentral SILENTLY DROPS
   "Add Intel AMT computer": `meshuser.js` line 2682, `if (args.wanonly == true) return;`. No error, no
   event. LAN-mode AMT needs `WANonly` false (hybrid) + a service restart; CIRA works in WAN mode. TacticalRMM's