Meshtastic feature would recover missed broadcasts from roof nodes

A roof node that hears a broadcast too early can become part of the problem instead of the fix. On June 13, Hamberthm opened Meshtastic issue #10704 with a simple idea: when an indoor node misses a broadcast, it should be able to command the roof node to fetch that message back out of cache instead of waiting for the mesh to sort itself out.

The request targets a very specific failure mode. In CLIENT_BASE, and in any mode other than ROUTER or ROUTER_LATE, a node will not retransmit a broadcast packet if it has already heard another node rebroadcast it first. That behavior makes sense for flood control, but in a house, shed, vehicle, or event space, it can leave the node you actually depend on with a blank spot even though the rest of the mesh heard the traffic.

Meshtastic already works as a managed-flood system. Its overview says radios retransmit a message up to three times if they do not get confirmation, ignore messages they have heard before, and keep only around 30 packets in memory when they are not connected to a client app. That small cache is exactly why the new request is framed as a recovery path, not a routing overhaul. The proposal is to ask the roof node for a missed broadcast from its heap cache, similar in spirit to Store & Forward but without turning the node into a full history server.

That distinction matters. Meshtastic’s Store & Forward feature already lets a client ask a special server to resend text messages after it has been out of LoRa range, and since firmware 2.4 a connected client app gets history automatically. But Store & Forward carries much more history than the default 30-packet cache. The June 13 request is narrower and more practical: it would use the roof node you already have in place as a local recovery point for missed broadcasts.

The timing fits a long-running pattern in the project. Meshtastic’s ROUTER_LATE guidance says that role is meant for infrastructure in places where existing router sites cannot be seen, like behind hills or at the bottom of a canyon. Earlier feature requests in September 2025 pushed in the same direction from different angles, one arguing that client nodes should ignore router and repeater rebroadcasts when deciding whether to rebroadcast, and another proposing CLIENT_BASE attic and roof nodes that behave like routers for favored nodes. Even the traceroute module, introduced in firmware 2.0.8 and expanded in 2.5 to show the return path with SNR, reflects the same reality: messages often arrive by more than one route.

One commenter on issue #10704 put the daily impact in blunt terms, saying text messages are only about 5% of their mesh traffic, while position updates, telemetry, and node_info make up most of the load. That is exactly why this proposal lands well. It does not try to rewrite Meshtastic’s flood model; it tries to make missed broadcasts less invisible for the people sitting inside the weakest part of the link.