Implement LRU cache for storing hashes to filter out for flood repeating

[weebl2000]

Currently, some busy nodes are seeing more than 128 packets before they are being received again. It's only some hashes that make another full cycle, so I feel having an LRU cache would maybe fix the problem.

Opted for uint16_t instead of uint32_t in order to save memory. Useful, or opt for uint32_t and remove the 60 second expiry?
I think we will need full timestamps.

Would be very interesting to see a very central node in the network try this out.

For example, the Utrecht repeater is seeing ~658 packets/20 min even at low activity times, with 72 neighbors it's not hard to imagine a message arriving again after looping through the network, after the node has seen 128 different hashes.

658 packets / 1200 seconds = 0.548 packets/second

Time to see 128 packets = 128 / 0.548 = 233.6 seconds ≈ 234 seconds

So with FIFO (dev branch):

• A hash enters the buffer
• 234 seconds later, after 128 new packets arrive, it gets evicted
• If the original packet returns after that point -> not filtered -> loop

The question becomes: what percentage of flooded packets take longer than 234 seconds (~4 minutes) to potentially return to node Utrecht (cc)?

Given the mesh topology with 72 neighbors and long multi-hop paths, packets taking 4+ minutes to traverse a long route back isn't unusual - especially with randomized retransmit delays adding up over 30-50+ hops.

Even if only 5-10% of packets return "late," that's:
658 × 5% = 33 loop events per 20 minutes
658 × 10% = 66 loop events per 20 minutes

[weebl2000]

I have no clue how this is happening.

[oltaco]

There's no reason they are both the same repeater, they are just two repeaters which share the same first byte.

[weebl2000]

There's no reason they are both the same repeater, they are just two repeaters which share the same first byte.

I would like to think so too, but how likely is the path 2b,d0,cc,2b,d0,cc,cc and then more d0 showing up later?

I've even observed this packet:

21320a837fe3e9cc2778c1d87706d0cc634dd0cc88a8163ed0cdd0acd079cccdd02b4dd079d0cc1d18d0cc88dd3ed03ad0cc16ee158936f4250eb42568758c1b6d4e9e7a7318ef2db20f30b2fa86b4b6ed1e8dc02e0eb9e47e1b2d573b3bcaab51f45196aae3c4e53b58c5c2d8c9c9c7366e853025be7adc

d0 occurs a staggering 11 times.

sequence d0cc occurs 5 times!

[oltaco]

I would like to think so too, but how likely is the path 2b,d0,cc,2b,d0,cc,cc and then more d0 showing up later?

Sorry, I missed that part and only saw the highlighted pair of e5. I agree that does look odd, I would even say it looks deliberate. Is it possible that the entire beginning of the path is faked, and the packet was custom built and injected somewhere closer to the receiving node?

[weebl2000]

I would like to think so too, but how likely is the path 2b,d0,cc,2b,d0,cc,cc and then more d0 showing up later?

Sorry, I missed that part and only saw the highlighted pair of e5. I agree that does look odd, I would even say it looks deliberate. Is it possible that the entire beginning of the path is faked, and the packet was custom built and injected somewhere closer to the receiving node?

Somehow I doubt that. Hash is still calculated on the non changing parts of a message and that should cause the message to not be repeated more than once.

If this is malicious it's more likely that someone is spamming d0 with dozens of unique packets causing its hasSeen array to be evicting hashes very quickly.

The fact that's it's occurring with cc too makes me wonder if it's just a really busy network. 👀

Ways to trigger this would be to send repeater discovery requests near those nodes since that would yield a lot of unique packets.

If the packet is fresh close to d0 or cc I would expect it to live in their hasSeen array for a while before they evict it.

Something that is strange is that packets are showing up on mctomqtt analyzer with only long paths. I.e below

This either means the packets traversed the mesh a bunch of times before an observer picked them up, or it's a packet that has already been evicted from the aggregation on mctomqtt because its been too long since it was last seen. (I think you can only see the last 2000 packets). Would need to do some local packet analyzing to get to the bottom of this

[ViezeVingertjes]

Hmm, i thought loops occur in a much shorter timeframe too, like with only 1-2 hops before it happens, my conclusion was before that its not possible to have 128 packets in that time (due to airtime etc).

[Edit]
We also seen it happen with the hashtable not even filled up to 128*

[awhite2000]

@weebl2000 see also #1386 , we're seeing such loops daily. There's definitely something fishy here because I don't think we have that much traffic to fill the hashtable.

[weebl2000]

@weebl2000 see also #1386 , we're seeing such loops daily. There's definitely something fishy here because I don't think we have that much traffic to fill the hashtable.

It would be interesting to see if some of the more central nodes in the network could run with LRU eviction and see if anything changes.

I'm running this PR on two of my repeaters - they are behaving like normal - but they are not really central nodes.

[pon-wessel]

@awhite2000 also: question - do you know if and how many nodes have rxdelay set? (anything other than 0)