Potential bug: routing loops

[awhite2000]

Recently I've been looking at the traffic in Warsaw, Poland area (WAW) using logs from the meshcore-bot. Currently there's over 250 repeaters in our area, with moderate traffic and with occasional hotspots (e.g. where the bots are). Most repeaters are on fw 1.11 although there are probably some on 1.10.

I noticed several times (e.g. once-twice a day) packets with abnormally long paths, and actually with loops in them. Here are some examples:

... FLOOD | Path: e6,a9,df,7e,38,c3,7a,a4,9d,15,c5,15,89,2a,df,39,43,76,4c,d6,2f,aa,87,c3,81,62,e2,2f,12,db,63,2d,c6,8e (34 bytes) | Payload: 151 bytes | Type: RESPONSE
Jan 11 06:29:12 meshcore-bot[941]: 2026-01-11 06:29:12 - MeshCoreBot - INFO - 🛣️  ROUTING INFO: FLOOD | Path: ae,7d,cf,1a,f7,56,0a,18,2b,33,ba,a5,dc,08,dc,b1,5e,8f,2f,64,c9,19,1f,7e,22,16,32,34,2c,d4,37,e1,cf,ca,06,14,13,a0,9a,a4,fb,26,50,16,50,93,b5,85,26,28,90,3c,62,96,c9,1f,63,ad,34,e0 (60 bytes) | Payload: 76 bytes | Type: RESPONSE

Jan 11 07:23:32 meshcore-bot[941]: 2026-01-11 07:23:32 - MeshCoreBot - INFO - 🛣️  ROUTING INFO: DIRECT | Path: ee,b0,6a,42,61,ae,1f,f7,66,35,c5,84,cc,92,c6,34,e0,07,4f,1e,7d,aa,4f,0b,0d,94,03,68,d5,dc,21,f2,05,c5,72,27,5f,b6,9a,42,04,6b,66,09,2b,5e,cd,c9,f5,32,cf,35,8b,e3,74,ea,b9,3f,4e,89,a1,cd,33,b6,ac,70,c9,09,76,81,30,6d,b5,60,57,07,ee,de,66,da,20,4a,b4,86,88,37,86,e0,25,77,09,f4,dd,e1,c6,f8,63,8c,7a,c5,4d,10,6d,82,05,6e,b7,af,47,38,1f,6d,24,41,52,ad,d2,b8,ef,a2,23,3d,21,c8,8a,f5,bc,9e,c3,81,4b,c3 (132 bytes) | Payload: 153 bytes | Type: REQ

Jan 13 18:35:05 meshcore-bot[941]: 2026-01-13 18:35:05 - MeshCoreBot - INFO - 🛣️  ROUTING INFO: FLOOD | Path: 4c,cd,c6,9e,b8,1f,b3,f1,c5,b9,cc,ae,42,1d,91,61,ae,c5,84,ad,c6,e0 (22 bytes) | Payload: 75 bytes | Type: GRP_TXT

This is a small sample but it means it's a relatively frequent occurrence and not a fluke. Also, the one packet with 132-byte long path should be an impossibility, right? Nonetheless, it was there.

Is there anything we can do to help diagnose the source of these loops?

[awhite2000]

And even more loops today:

Jan 14 13:02:37 meshcore-bot[941]: 2026-01-14 13:02:37 - MeshCoreBot - INFO - 🛣️  ROUTING INFO: FLOOD | Path: 9e,92,96,bc,42,4e,f3,61,93,61,5e,13,41,93,c1,8d,1a,34,78,d0,c1,86,61,0d,ed,b9,4e,96,92,8e (30 bytes) | Payload: 82 bytes | Type: ANON_REQ
Jan 14 13:02:44 meshcore-bot[941]: 2026-01-14 13:02:44 - MeshCoreBot - INFO - 🛣️  ROUTING INFO: FLOOD | Path: 9e,92,96,bc,42,4e,f3,61,93,61,5e,13,41,93,c1,8d,1a,34,78,d0,c1,86,61,0d,ed,b9,4e,96,9e,51,e0 (31 bytes) | Payload: 83 bytes | Type: ANON_REQ

[lkosson]

This is not a routing loop - it's a single node making random bitflips when retransmitting packets. See this example from today:

It received a packet with E0-84-AE-1D-61-4E path (marked "1") and a few seconds later reported it back, but with different hash (marked "2").

Original packet contained the following payload:

while a second one (non-decodable) contains:

Often the node hears back mangled up packet, can't find it in its PacketQueue (hasSeen returns false), rebroadcasts it with yet another bitflip on same or similar path, which gets reported by other observers looking as if same nodes kept circling repeating the packet.

[awhite2000]

Indeed, this looks like data corruption, between D and 7 there are two bits flipped. It's a pity the protocol doesn't have any place for a few CRC bits over the whole packet so that corrupted packets can be quickly dropped. Still, the end result of this is similar to looping in that it needlessly generates and forwards useless traffic.

[awhite2000]

Also, the packet with path_len=132 is obviously corrupted - although path_len is 1-byte long and can be set up to 255 the clients should recognize that anything above MAX_PATH_LEN is invalid.