Title: MeshCore Virtual Node: config/admin commands silently dropped with unhandled frame: code=142

[djvdberg94-hash]

Environment

• MeshMonitor version: 4.12.3 (Docker, ghcr.io/yeraze/meshmonitor:latest)
• Deployment: Docker Compose on Ubuntu 24 VM (Proxmox), device passed through via USB
• MeshCore source: USB/Serial, device type Companion, firmware v1.16.0-07a3ca9
• Hardware: Seeed XIAO nRF52840 (companion_radio_usb build)
• MeshCore mobile app: meshcore-flutter
• Virtual Node: enabled, port 5000, connecting over LAN WiFi

Summary

Connecting the MeshCore mobile app to a MeshMonitor-managed MeshCore Virtual Node works for read operations and messaging (nodes/contacts visible, messages send fine), but any config-mutating action from the app (e.g. changing radio params, device settings) fails silently on the app side with no clear error.

Confirmed not a permissions issue

allowAdminCommands is set to true on the source config, confirmed via direct API query:

"virtualNode": {
  "enabled": true,
  "port": 5000,
  "allowAdminCommands": true
}

Note: this field currently has no corresponding checkbox in the Edit Source dialog for MeshCore sources in the web UI — only Meshtastic TCP sources seem to render it. Had to PUT the full source object via a browser console fetch to set it, since PATCH isn't a supported method on /api/sources/{id} — only PUT. Might be worth a separate issue/PR for the missing UI control.

Logs

Every attempted config action produces repeated log lines like:

unhandled frame: code=142 [
142, 48, 206, 0, 146, 56, 51, 236, 114,
35, 200, 84, 213, 132, 9, 198, 239, 221,
...
]

This appears immediately after AppStart from mcvn-N (app "meshcore-flutter") → SelfInfo for "DJ_Meshcore_Base", and repeats for each attempted action. Messaging (send_msg etc.) works normally and produces no such warnings — this only happens for what appear to be config/admin frame types.

Expected behavior

Either the config command is forwarded to the physical node (per docs: "Enabling Allow admin commands forwards those configuration commands through to the real node"), or the app receives an explicit rejection/error it can surface to the user — rather than the request being silently dropped with only a server-side log entry.

Steps to reproduce

1. Add a MeshCore source (USB, Companion) in MeshMonitor
2. Enable Virtual Node, set allowAdminCommands: true
3. Connect the MeshCore mobile app to the VN over WiFi
4. Attempt any settings change from the app (e.g. rename node, change radio params)
5. Action fails/hangs in the app; server log shows unhandled frame: code=142

[Yeraze]

I have begun work on this issue, in branch claude/vibrant-volta-0friz5.

Investigation

Not a duplicate — searched open/closed issues for "unhandled frame", "Virtual Node admin", "allowAdminCommands" and found nothing matching.

Classifying this as a Bug Report, with two separable root causes:

1. The missing UI checkbox (the one you flagged as maybe-a-separate-issue)

Confirmed — and it's worse than just missing. In src/pages/DashboardPage.tsx, the MeshCore Edit Source form's Virtual Node fieldset only rendered the port field; the "Allow admin commands" checkbox that exists for Meshtastic TCP sources was never added for MeshCore. Worse, the save handler for formType === 'meshcore' hardcoded allowAdminCommands: false regardless of any state:

cfg.virtualNode = { enabled: true, port: vnPort, allowAdminCommands: false };

So even before your manual PUT, the web UI could never persist true for a MeshCore source. I've fixed both — added the checkbox (wired to the same formVnAllowAdmin state the Meshtastic form already uses) and removed the hardcoded false. This part is fixed in the branch above; I'll open a PR shortly.

(On the PATCH-vs-PUT point: /api/sources/:id is intentionally PUT-only — full-object replace — there's no PATCH route at all, for any source type. That's consistent, not a bug, just something to know when scripting against the API directly.)

2. The actual "config commands silently dropped" behavior — bigger, not fixed yet

This is the real root cause of the unhandled frame: code=142 / hung admin actions, and it's a gap in src/server/meshcoreVirtualNodeServer.ts, not a bug in the allowAdminCommands flag itself.

MeshCoreVirtualNodeServer.dispatchCommand()'s switch statement only implements: AppStart, GetDeviceTime, SetDeviceTime (no-op ack), DeviceQuery, GetContacts, GetChannel, GetBatteryVoltage, SyncNextMessage, SendChannelTxtMsg, SendTxtMsg, SetFloodScope (no-op ack). Every config-mutating companion command — SetAdvertName(8), SetRadioParams(11), SetTxPower(12), SetAdvertLatLon(14), SetChannel(32), SetOtherParams(38), etc. — falls into the default: branch and gets encodeErr(UnsupportedCmd) back over the wire, unconditionally.

The allowAdminCommands flag is threaded all the way from config → constructor → an isAdminCommandsAllowed() getter, but it's never referenced inside dispatchCommand. There's no forwarding path to the real node for any of these commands at all yet — the flag is effectively dead code today. (Contrast with the Meshtastic virtual node — src/server/virtualNodeServer.ts — which does implement the allow/block + forward logic for admin PortNums.) The class docstring calls this out as deferred: "Phase 2" forwards message/channel commands (which is done); a further phase for config/admin commands was never implemented.

unhandled frame: code=142 itself doesn't come from any MeshMonitor server-side log line (I grepped the whole repo) — code 142 is also outside our defined CommandCodes range (1–56), so that message is most likely emitted by the MeshCore app itself or by @liamcottle/meshcore.js in a different context, not by our dispatch loop. Our loop does return an explicit Err(UnsupportedCmd) for these commands already — so from MeshMonitor's side, "silent" mostly means "logged at debug, not info", not "no reply sent."

Remediation

• Done (this branch): UI checkbox + hardcoded-false fix, so the toggle exists and actually persists.
• Follow-up (larger, not in this PR): implement real forwarding for the config-mutating companion commands in MeshCoreVirtualNodeServer.dispatchCommand, gated on allowAdminCommands, mapping each SetXxx code to the corresponding MeshCoreManager operation against the physical node, mirroring the pattern already proven in virtualNodeServer.ts for Meshtastic. That's a multi-command protocol implementation, not a one-line fix, so I'm scoping it out of this PR rather than rushing a partial version. Happy to pick that up as a follow-up if you'd like — let me know.

-- Authored by Roger 🤓

---

Generated by Claude Code

[Yeraze]

PR #3905 has been merged — it fixes the missing/hardcoded-off "Allow admin commands" checkbox in the MeshCore Edit Source dialog you flagged (that part is now resolved, no more manual PUT needed).

Leaving this issue open, since the actual reported symptom — config/admin commands from the app still being dropped (unhandled frame: code=142 / hung actions) — is not fixed by that PR. As detailed in my earlier comment, the real gap is in MeshCoreVirtualNodeServer.dispatchCommand() (src/server/meshcoreVirtualNodeServer.ts): it has no forwarding path at all yet for config-mutating companion commands (SetAdvertName, SetRadioParams, SetTxPower, SetAdvertLatLon, SetChannel, SetOtherParams, etc.) — they still hit default: and get Err(UnsupportedCmd) regardless of allowAdminCommands, which is now at least correctly settable but still not consulted anywhere in the dispatch loop.

That's a larger follow-up (implementing real forwarding to the physical node, mirroring the pattern in src/server/virtualNodeServer.ts for Meshtastic) that I've scoped out of #3905 rather than rush. I'll leave it here for @Yeraze to prioritize / assign, or I'm happy to pick it up if asked.

-- Authored by Roger 🤓

---

Generated by Claude Code

[Yeraze]

Status update — config forwarding shipped in v4.12.4

Both halves of this issue are now implemented and released. Summary of what landed since my last comment:

Item 1 — the "Allow admin commands" checkbox (PR #3905): the MeshCore Edit Source dialog now renders the checkbox and actually persists it. The previous hardcoded allowAdminCommands: false is gone, so no more manual PUT needed.

Item 2 — config commands silently dropped / unhandled frame: code=142: MeshCoreVirtualNodeServer.dispatchCommand() now forwards config-mutating companion commands to the physical node, gated on allowAdminCommands, instead of unconditionally returning Err(UnsupportedCmd). The flag (previously dead code) is now actually consulted.

App command	PR
SetAdvertName, SetRadioParams, SetTxPower, SetAdvertLatLon, SetChannel	#3906
SetOtherParams (manual-add-contacts, telemetry visibility, advert-loc policy)	#3907
SelfInfo now reports real manualAddContacts (was hardcoded 0)	#3910

All of this is in v4.12.4 (ghcr.io/yeraze/meshmonitor:latest).

Please re-test 🙏

Could you pull v4.12.4, confirm Allow admin commands is checked on the source, and retry the actions that were failing before — rename node, change radio params, set coords, channel changes? Those should now forward to the physical node and succeed instead of hanging. If they work, I'll close this out.

One scope note

Device config/settings commands (the ones you reported) are all covered. A few other mutating commands are still intentionally out of scope here and would return an unsupported-command reply if triggered from the app — contact management (AddUpdateContact, RemoveContact, ShareContact, import/export), ResetPath, SendLogin, SendTracePath, SendTelemetryReq. If you hit one of those, it's a separate follow-up rather than a regression of this fix — let me know and I'll open a dedicated issue.

-- Authored by Roger 🤓