Node ID collisions

[ianmcorvidae]

It's possible for two nodes to have an identical ID (while it means two colliding int32s, it definitely happens -- I have a 3000km link showing for me to a different node that shares an ID with one a few meters away). I'm not sure what the best way to fix this would be, but it would probably be good, if possible, to treat these as several different nodes.

In this case, I think it may be a specific bad ID -- https://meshtastic.liamcottle.net/?node_id=115503498 has multiple cross-country links. Nevertheless, these collisions do seem to happen and it'd improve the map if they could be intelligently detected, probably.

I do also understand this isn't a very easy problem to solve, but perhaps things can be partitioned by uplink/source node to some degree; when a given ID consistently gets similar names and positions from one uplink and gets a different similar set of names and positions from another uplink, the existence of a collision can maybe be inferred.

[liamcottle]

Yeah, that's the unfortunate downside to small random node ids. A better approach would be public/private crypto keys, but it is what it is.

Another way around this is to run your own MQTT server and map instance, so it only collects information about nodes in your area. That way these distant nodes with the same IDs are never picked up, unless of course there was another node at your neighbours place with the same ID, you'd have the same issue...

Not sure what can be done in the codebase to fix this, but it is known and I have seen this happen with other nodes on the map.

There's just no globally unique way to differentiate each node, and it's easy enough to spoof and spam fake data as well...

[ianmcorvidae]

Yeah, for sure. I do think this specific one may be a factory issue with RAK; put a message in the meshtastic discord to see if others are seeing it, and if so that might reduce the incidence in this particular case if I'm right.

Notably, if the two nodes with the same ID see each other, one will actually choose a new ID, so if they're both actually in the same local mesh you generally won't see this issue. So it's more of a global-data-collation thing than a local thing.

As far as this codebase, here's what I could see happening (and please forgive me if I appear presumptuous -- I promise I'm not demanding this of you, just trying to lay out how I think it could get accounted for here):

• nodes (as well as things that reference nodes) in the DB store their gateway node as well as part of their primary key, so that it's possible to distinguish the same ID having come from multiple gateways, as well as distinguish the streams of names, positions, etc. from one another
• All the user packets would get held onto, so that the relationship between gateway, node ID, and short/long names can be correlated over time (I believe this is already done for positions and other stuff, but maybe not for short/long names)
• of course, some (most, possibly) of these will just be the same node legitimately getting uplinked by multiple gateways in the same area, or the result of nodes traveling a long distance and being seen by several gateways along the way
• to attempt to distinguish, some sort of background process runs from time to time and considers the data stream heuristically, and if the heuristics decide two nodes should be separate, records the derived relationships in another table. The heuristics here would be the most challenging thing to design, probably, but it'd all boil down to answering whether changes in data appear to be actual changes (movement, updates of names, temperature changes) or correlated with gateway ID (which looks more like oscillating between several nodes, really)
• probably, since the former step is heuristic, also allow manual intervention to separate or re-combine nodes as appropriate
• frontend is then given the nodes separately, and would need to be updated to account for the possibility of two nodes with the same ID (but differing gateway correlations), and probably could indicate the existence of the other nodes

Unsure how much effort it's worth. At least tracking the gateway correlations might be nice for identifying this sort of case, but maybe the heuristics would be too much, at least to start.

Anyway! Take what you will and all that, of course :)