GUVWAF
commented
3 months ago I would simply ask the other side to increase their hop limit. Once people are experiencing that even 7 hops is not enough (and the mesh still works reliably otherwise), we can think of things like this, but it's currently unnecessary. It makes it more complicated and might lead to unexpected side effects, e.g. what happens if multiple "gateway" nodes are not decrementing the hop limit or endlessly rebroadcasting even if it is 0 already?
Also from 2.3.0 on, the hop limit is used to derive how many hops a received packet took, which would be incorrect with this. In 2.3.0 nodes will already increase the hop limit of a response (e.g. traceroute) or ACK if they noticed it used more hops than they configured on the way towards it.
Platform
NRF52, ESP32
Description
To access my local mesh I have a remote ROUTER_CLIENT node that my home/primary node connects to. The primary node is usually unable to access any other node except the remote node with the remote node acting as a gateway (in my area I am not alone in this regard).
The mesh is growing to the extent that 3 hops is sometimes needed to reach more distant nodes, even though the node count is still pretty manageable. (Geographically the nodes are fairly widely spaced).
For transmitting I can simply bump the hop count to 4 to account for the gateway but for inbound packets I am effectively limited to 2 unless someone else bumps the count.
My idea is that a node with role GATEWAY (or perhaps GATEWAY_ROUTER & GATEWAY_REPEATER) works as per the existing roles but for a predetermined list of clients it neither decrements the hop count when re-broadcasting the Sender messages of approved clients nor discards the Destination messages of these clients if the hop count is zero but rebroadcasts them.
Perhaps this could be extended a bit further without causing too much additional traffic by also handling messages from new (to the gateway) nodes in this manner to allow the possibility of node discovery at the "true" third hop. Possibly taking a Store and Forward approach to this as opposed to or instead of a simple re-broadcast in this case.