Rate limit position replies to three minutes

[GUVWAF]

Fixes #5914.

In order not to overwhelm the mesh, let’s rate limit position replies. Meaning that if we sent our position already in the last three minutes, we’ll not reply to position requests. Since position packets are not using PKI and are “promiscuous”, every node that has the channel key would have seen the previous packet already.

Note that this is specifically for replies upon a request; setting the periodic broadcast interval (or smart position) less than three minutes is still possible.

[erayd]

Is there an alternative to this for getting an explicit manual ping response? I comonly use the "request location" option as a way to solicit a response from a node when I'm doing setup or coverage analysis, and explicitly want the remote node to respond right now - and that's often much more frequently than every three minutes. I don't really care what the response actually contains; and it doesn't need to hop (in fact, it would be best if it did not hop). I just want something to arrive that will allow me to observe the incoming RSSI / SNR from that node.

Range test has proven unreliable for this (doesn't always send at the configured interval, plus short intervals on that are obnoxious), and also requires a reboot to enable - which I generally prefer to avoid doing on infrastructure nodes unless there's a particular need for it.

[GUVWAF]

You can send it a direct message, to which it will always send an ACK. Alternatively, you can send a traceroute (which is rate limited to 30 seconds, but only at the sender).

[erayd]

Thanks. DMs are too cumbersome (because they aren't on the same screen set that the signal reports live on, and therefore aren't well suited to sending checks every few seconds while moving a node).

I had avoided traceroute due to the mesh overhead, but can live with it if necessary. 30 seconds is slow, but much more tolerable than three minutes, especially as this is a sometimes use-case, rather than the norm 🙂

[GUVWAF]

A traceroute will be more efficient than a position request. Routing is the same, but traceroute has a smaller payload.

On iOS you can long-press a DM to see the SNR of the ACK.

[erayd]

A traceroute will be more efficient than a position request. Routing is the same, but traceroute has a smaller payload.

That's good to know. I had thought it was the other way around, because it solicits lots of different responses.

On iOS you can long-press a DM to see the SNR of the ACK.

I'm an Android guy sadly, so not an option for me. That would have been an ideal solution.

[GUVWAF]

I had thought it was the other way around, because it solicits lots of different responses.

Only the node you're sending it to will respond, just like a position request. Other nodes only add their ID to the packet when forwarding it.

[erayd]

That is what I meant by responses when I was referring to traceroute (i.e. a series of packets that get progressively larger, rather than location response which is a constant size). I had assumed that the location response just contained the coordinates. Didn't realise it had enough stuff in there to bloat it past a traceroute, or I would have avoided it 🙂

[GUVWAF]

A position request actually exchanges position (that's also how it's called on iOS), so it sends coordinates, altitude, timestamp, position precision and all other flags that are enabled along with the want_response flag set, and the destination sends the same info back. For a traceroute, the initial message is empty and each hop only adds its ID (4 bytes) and SNR (1 byte).