[Feature Request]: Option to limit traffic based on original hop settings about firmware HOT 7 CLOSED

Sounds like a very good idea to me.

from firmware.

I see two issues with dropping them:

• it's hard to debug, you raise your hop limit and things starts not working because your neighbors configured it, you don't get any error message and it still kinda work, as zero-hop messages, so it's flaky and extremely hard to debug.
• it actually promote worst routing topologies, because you don't relay the message other nodes in the mesh that are closer and in worst position to relay the message might relay the message instead. Relaying with a lower number will make anyone else who heard the original 7 hop and your 3 hop relay, cancel their own relay attempt.

from firmware.

A solution with less knobs could be to compute the next hop as min(msg.current_hop -1, node.hop_limit) so if you have MAX_HOP set to 3 and you receive a message with 6, you would relay with 3.

from firmware.

A solution with less knobs could be to compute the next hop as min(msg.current_hop -1, node.hop_limit) so if you have MAX_HOP set to 3 and you receive a message with 6, you would relay with 3.

Possibly. But if big-hop packets were simply dropped and not forwarded by nodes using the option I suggested it might encourage people not to use mesh-unfriendly settings in the first place. Although I do understand that in a few very special circumstances using a large hop count might be beneficial. So in those areas people could simply leave the option unticked.

from firmware.

This is similar to #3833

from firmware.

This is similar to #3833

Indeed. Although of course a repeater with ‘don’t decrypt’ enabled (as most routers seem to be) won’t do this. But I was thinking more of general nodes in the mesh, as opposed to routers and repeaters.

from firmware.

@Jorropo Has two valid points as to why this would not be desirable.

With the next-hop router (#2856), excess rebroadcasts due to high hop limits will be avoided for DMs already. Furthermore, already now the hop limit for ACKs and responses will be dynamically adapted based on the amount of hops that was required.

I'm converting this into a discussion. Don't think it's needed to implement this in the firmware. In my opinion you should either educate the people using your public mesh, or move to a private one. The hop limit is only one configuration setting that users can set wrongly/too aggressive. Enabling MQTT downlink or setting high update intervals for telemetry, position, etc. are also very important factors that contribute to the channel utilization.

from firmware.