meshtastic
[Feature Request]: Companion Node Forwarding for Edge Cases in Hop Count Limitation
Platform
other, ESP32, NRF52, RP2040, Linux Native, Cross-Platform
Description
It is common in certain deployments to have one node placed on the roof and another one indoors. Often, packets that are successfully received by the rooftop node are not forwarded to the indoor node, due to hop count limitations or routing constraints.
I propose adding a "companion node" option in the configuration. This node would serve as a designated peer to which packets are always forwarded, regardless of whether the hop count has been exhausted. Additionally, packets received from this companion node should not have their hop count decremented.
This would significantly improve reliability in edge scenarios and ensure better connectivity between nodes that are physically close but separated by routing barriers.
This issue is related to #6955.
The issue is probably not hop count limitations, but because of how a CLIENT works. It will only forward the packet if it does not yet hear another node doing so. One role that does what you're requesting, namely always forwarding even if someone else already did so, is the ROUTER_LATE role. However, it should be used with caution as it will increase channel utilization. I don't think this can be avoided if you want to make sure the indoor node always receives everything, unless you use UDP (when using ESP32/Linux native devices) for the last hop.
Do any two clients that can hear the same node will be split brain regarding messages?
I believe the routing algorithm needs to be rethought. Relying on specific roles leads to configuration errors and ultimately weakens the entire network.
As it stands, the more nodes are present, the higher the chance that a packet won’t be forwarded correctly. Additionally, a “deaf” node that still transmits could end up relaying the packet first, preventing another, better-positioned node from forwarding it. For example, a hiker on a higher part of the trail might have better connectivity, but if their node is acting as a client, it won’t forward packets from hikers further down.
Routing from point A to point B should prioritize the most reliable nodes, and node configuration shouldn’t be something users need to worry about.
Routing from point A to point B should prioritize the most reliable nodes, and node configuration shouldn’t be something users need to worry about.
Unfortunately this is much easier said than done. What defines "most reliable" and how do you measure that and convey to every node? Currently SNR is used as a proxy for "most reliable" or at least trying to use the least amount of hops, however, it is not perfect. Other things have been proposed but did not seem to outperform it: https://github.com/meshtastic/firmware/pull/5697
For direct messages, since 2.6 we already do not use managed flooding anymore. However, for broadcasts it's just very hard to optimize it without creating a lot of overhead in terms of routing control packets.