Feature: client-side Store & Forward replay (bypass firmware's LongFast restriction)

[Yeraze]

Feature request

Meshtastic's firmware StoreForwardModule refuses to serve request history on the default/public channel (LongFast). This is a hardcoded check:

https://github.com/meshtastic/firmware/blob/master/src/modules/StoreForwardModule.cpp — channels.isDefaultChannel(mp.channel) gates the history-request handler (lines ~364, 417, 482). Nodes on the default channel can never pull replay history from a Store & Forward-capable node, by design.

Ask: could MeshMonitor replicate Store & Forward client-side — replaying recent channel message history to a client (web UI session, or a Virtual Node-connected app) on request, sourced from MeshMonitor's own message DB, bypassing the firmware's LongFast restriction entirely since it never touches the S&F module?

Known limitations (confirmed, not hypothetical):

1. No sender spoofing. MeshMonitor can only transmit as its own connected node. A replayed message can't go out over RF as if from the original sender — it would need to be relayed/wrapped, e.g. "MeshMonitor relaying: [Alice @ 14:02] hey...". Attribution to the original sender is preserved in the message body/metadata, not in the packet's from field.
2. Same radio, same airtime. MeshMonitor transmits any replay through the same physical node as everything else. It does not relieve the congestion pressure that the firmware's LongFast gate exists to prevent — a client-side replay feature would need its own throttling/rate-limiting to avoid making the problem it's meant to work around.

Open question — NOT resolved, needs investigation:

Whether serial or direct-radio access (the kind used by tools that spoof node IDs) could let MeshMonitor originate a replayed packet with the original sender's node ID in the from field, removing limitation #1. This was raised in discussion but not investigated — a prior attempt hit unrelated technical issues and couldn't get to it. Do not assume this is feasible; it needs someone to actually check firmware/serial API behavior around from field spoofing before this is scoped as achievable.

Scope for implementation (not yet designed):

• Where the replay buffer/window lives (already have message history in MeshMonitor's DB)
• Rate limiting for replayed messages to avoid amplifying LongFast congestion
• UI/UX for requesting history replay (web UI button vs. Virtual Node companion command)
• Whether replay is per-channel or global

Authored by NodeZero 0️⃣

[Yeraze]

Researched null_v0id's question: "What about if it has serial access. I know people spoof the node id's on meshtastic devices so it must be possible."

Verdict: No — serial access does not change limitation #1. The from field is stripped and replaced regardless of transport. Here's the evidence.

1. The firmware zeroes from for every client-submitted packet, on every transport

MeshService::handleToRadio() — the single function that processes a ToRadio.packet from any connected client — unconditionally clears the sender field before the packet goes anywhere:

// src/mesh/MeshService.cpp:287-289
p.from = 0;                          // We don't let clients assign nodenums to their sent messages
p.next_hop = NO_NEXT_HOP_PREFERENCE; // We don't let clients assign next_hop to their sent messages
p.relay_node = NO_RELAY_NODE;        // We don't let clients assign relay_node to their sent messages

That zeroed value is then filled in with the local node's own identity when the packet is actually queued for transmission:

// src/mesh/NodeDB.cpp:656-659
NodeNum getFrom(const meshtastic_MeshPacket *p)
{
    return (p->from == 0) ? nodeDB->getNodeNum() : p->from;
}

// src/mesh/Router.cpp:433
p->from = getFrom(p);

2. Serial gets no elevated trust — it's the same code path as BLE/TCP

handleToRadio is reached through PhoneAPI (src/mesh/PhoneAPI.cpp), and serial is just another PhoneAPI subclass, not a separate privileged path:

// src/SerialConsole.h:10
class SerialConsole : public StreamAPI, public RedirectablePrint, private concurrency::OSThread
// src/mesh/StreamAPI.h:33
class StreamAPI : public PhoneAPI

BLE (NimbleBluetooth.cpp), TCP, and serial (SerialConsole/StreamAPI) all funnel into the exact same MeshService::handleToRadio() gate above. There is no serial-specific branch that skips the p.from = 0 line or grants a wired client permission to set an arbitrary sender.

3. The one real exception — and why it doesn't apply here

There is a compile-time-gated frame injection path (MeshService::injectAsReceived, src/mesh/MeshService.cpp:220-259) that can preserve a forged from, by delivering a crafted frame into the RX pipeline as if it arrived over LoRa — bypassing the p.from = 0 line entirely (it's reached earlier in handleToRadio, src/mesh/MeshService.cpp:278-286). But:

// src/configuration.h:91-97
// Debug/test only: let a wired client (serial/TCP) inject frames into the RX pipeline as if they had
// arrived over LoRa ... This forges over-the-air traffic, so it MUST stay 0 in
// any shipping build; enable per-build with -D MESHTASTIC_ENABLE_FRAME_INJECTION=1.
#ifndef MESHTASTIC_ENABLE_FRAME_INJECTION
#define MESHTASTIC_ENABLE_FRAME_INJECTION 0
#endif

It's off by default in every official/shipping build and requires flashing a custom-compiled firmware with that flag set — not something serial access to a stock device grants you. It's also not serial-exclusive in principle (the flag gate is transport-agnostic); the comment mentions serial/TCP because that's the realistic debug workflow, not because BLE is blocked by design.

The "people spoof node IDs" claim — likely a different thing

This almost certainly isn't about controlling MeshMonitor/a companion app via serial. The actual known "spoofing" issue in the Meshtastic community is protocol-level, not client-API-level: MeshPacket.from is unauthenticated at the radio layer, and the default public channel uses a fixed, universally-known PSK (AQ==). Anyone who can construct a valid encrypted LoRa packet — via a modified/independent radio stack (SDR, custom code), not through a stock node's phone/serial API — can claim any NodeNum on that shared-PSK channel. This is tracked as CVE-2025-55292 and documented independently at github.com/nightjoker7/meshtastic-spoof-research. It requires bypassing the official firmware's client API entirely (or using HAM/no-encryption mode), not merely plugging in over serial. I could not find any Meshtastic firmware or community source describing serial-console access as a way to set arbitrary sender IDs through the normal client API — if such a thing exists I haven't found it, and the code above says it doesn't.

Bottom line

• Serial vs BLE vs TCP: no difference — same handleToRadio() gate, same forced identity substitution.
• The only way to forge from on real hardware requires a custom firmware build with a flag that must never ship enabled — not achievable via serial access to a normal device.
• "Node ID spoofing" as discussed elsewhere refers to a protocol/PSK-layer weakness in raw packet construction, unrelated to what transport you use to talk to a stock node's client API.

So limitation #1 in the original writeup stands regardless of connection method (BLE, TCP, or serial).

Authored by NodeZero 0️⃣