[Feature Request]: Limit messages forwarded by routers depending of max hops settings or hops used

[CamFlyerCH]

Platform

Cross-Platform

Description

My well positioned solar router hits regularly the TX limit we must obey in Europe. I would like to configure my router to only forward messages with reasonably limited max hops.

I can, somewhat reliably, only reach nodes that are 1 or 2 hops away via my router, since other nodes I receive have a max. hops setting larger than my 3 or other routers along the way are also reaching their TX limit and drop messages. I receive many nodes configured with a max. hops setting between 5-7. Even routers never used as clients, that broadcast their nodeinfo, position and telemetry packets to very distant nodes, but no one uses these messages anyway.

I analysis over 5 days show, that this setting would reduce the forwarded messages by a third. (I logged nodeinfo messages on my MQTT via the JSON messages . I only counted messages with a hop_start of 4 or more. I also have quite a few messages with a hop_start NULL and a hops_away larger than 3.

So on a router ,there should probably be two additional settings in the device configuration.

• Forward only messages with a sender max. hops setting of X or less (default 3)
• Forward only messages from nodes that are not further away than X hops (default 2)
  (They could be merged to one if the "hops away" is one less than the senders max hop limit)

I could not define the best short name or description for these 2 parameters (for the GUIs). Also the defaults are my preferred values, but I would like to have other opinions on this topic. I use the KNOWN_ONLY rebroadcast setting right now, that helped quite a bit to reduce the TX load, but new nodes are not able to use the router with this setting.

Similar request in this discussion: #3833

[b8b8]

This makes sense for Europe or other areas with limited transmit duty cycle, but this is def something i dont want to see where we can transmit 100% of the time. Maybe limited to EU868 only and Router only.

[Kealper]

This makes sense for Europe or other areas with limited transmit duty cycle, but this is def something i dont want to see where we can transmit 100% of the time. Maybe limited to EU868 only and Router only.

Perhaps the defaults for those options could be modified for regions that have duty cycle limits set below 100%, and if the region settings do have 100% duty cycle allowed, just set the default for the suggested new settings to 7, effectively disabling them but leaving them available to people who may wish to change them.

[b8b8]

I just want to make sure this doesn't lead to a tweak of the code where someone makes a malicious router that automatically reduces everyone's hops to 1 thereby killing the local mesh reach. I don't really like the idea of modifying anyone else's packets at all. It's like removing one of the stamps from someone else's letter

[thebentern]

We have some code macro-guarded in EVENT_MODE that hard-enforces a HOP_RELIABLE limit of 3 for rebroadcasting incoming messages from so called "Hop-maxers". I'm wondering if this makes sense as an additional rebroadcast mode which can be applied to Routers as ALL_HOP_RELIABLE for instance.

[GUVWAF]

First thing I would suggest is using CLIENT role instead of ROUTER if you're hitting the duty cycle limit. A router will always rebroadcast, and as fast as possible. However, if it's so busy it's likely it has multiple packets in the queue and thus it's not even the first to rebroadcast. A client, on the other hand, waits a bit before rebroadcasting and doesn't do it anymore when it hears someone else doing so already. This will thus significantly lower your amount of transmissions, while still providing routing capabilities when necessary.

If you want to provide routing to your mesh, it sounds a bit arbitrary to not rebroadcast packets with a high hop limit, as they might have a valid reason for it (e.g. when they're on the edge of the mesh). Yes, they have a higher load on the mesh, but having a node that generates packets every minute with a hop limit of 3 is still worse than one with a hop limit of 5 that transmits only every hour.

Lowering the hop limit before rebroadcasting might have merits in some cases, but doesn't lower the amount of transmissions of the router.

[CamFlyerCH]

I like all the diverse feedback posted here. I absolutely understand the concerns and also that this is not a typical configuration. But please understand, that when I put money and effort in building, placing and maintaining a router to serve me and mostly local Meshtastic users, i like to have it functioning and serving this purpose as good as it can. I can't and I don't what control how other people configure their nodes. We try already to inform others via a "Netiquette" document. But it has a limited effect. And nodes that are very far away I can't contact mostly even if I set my max hops to 7. But I don't want that anyways.

I am not the only one looking for a solution for this issue. See also post here: https://meshtastic.discourse.group/t/swiss-meshtastic-user/9688/126 . I was also think to set the node to client_mute, so I still can communicate with it and receive the telemetry reliably. I did not tried yet how client mode would help. Perhaps with telemetry, but my goal is to have a reliable router in and for my region.

@thebentern I like the idea of an additional rebroadcast mode. Probably this would be "in the right spot" as a configuration, but can't then be fine tuned. What it should not do is rebroadcast an modified message with reduced hops. I just should not rebroadcast it at all.

[meshtastic-bot]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/swiss-meshtastic-user/9688/129

[Kealper]

I just want to make sure this doesn't lead to a tweak of the code where someone makes a malicious router that automatically reduces everyone's hops to 1 thereby killing the local mesh reach. I don't really like the idea of modifying anyone else's packets at all. It's like removing one of the stamps from someone else's letter

I took the feature request to mean "if the received packet has a hop count over X value, don't rebroadcast it", where X would be configurable by the user who owned the node, and that no modification of the received packets would be done, it just doesn't add it to the rebroadcast queue. If that's what this request was intending, then it wouldn't hurt the local mesh any more than if the node wasn't there to begin with, and only for hop counts above the threshold.

[CamFlyerCH]

I did a test implementation (without the way to configure it) and flashed this modified firmware to a RAK 4631. It seams to work, but some else placed another router on a much more elevated position, and now i still get all these messages from nodes configured with max hops 5, 6, or even 7. So, yes, I have to work this out with the local router operators.

But while implementing the changes to the floodingrouter.cpp I had to think quite a lot how the best implementation should be:
(My goal is a soft limit of 3)

Version 1:
If the message has a hop_start >3 I will reduce the hop_limit by the amount hop_start is over my "goal" of 3. If after that the hop_limit is less than 1 the message is not sent/routed.
There is the negative effect, that when a node receives this message and calculates the "hops away" by subtracting hop_limit from hop_start, the distance is "raised" by the "penalty" it received during routing. Example: The router receives a message with hop_start of 5 and a hop_limit of 4 (so it was routed before once). I subtracts 2 (penalty for hop_start 5) and also subtracts 1 because it is getting routed. So the next node receives it with hop_start of 5 and a hop_limit of 1 and showing the the user hops away 4 instead of the real 2. But he also has a max hops of 5 he knows, that he still can reach this node with his settings and it will work even if he receives also a penalty of 2 while traveling my router.

Version 2:
Like in version one the hop_limit is reduced, but also the hop_start is reduced by the same amount.
There is the negative effect too. While the distance is shown correctly, if I monitor the mesh messages I don't know witch nodes are configured with max hops higher than 3. Only on the router itself this would be "visible" in the data. But I have no access to the router via serial/USB or MQTT to view that.

So version 2 is probably better as the "final" solution.

I also implemented an additional filtering, but it is a bit to harsh I think:
Every message received with a hop_start higher than 5 is never routed (despite the distance of the sending node). This is in this way not effective if my goal would be to ask node owner to please don't use such a setting in a mesh where my router receives way more than 100 nodes.

After this PoC work I am unsure what would be a feasible implementation into the firmware and how the option should be configurable. To implement it as an additional setting in the "rebroadcasting mode" and a fixed target of 3 implemented as described in version 2 is my proposal.

@thebentern My code is similar the the "EVENT_MODE" code, but subtracts not 2 but always the difference to the "desired" value of 3, and also checks if the hop_limit is >= 1 before sending the message.