Map line shows direct link for 1+ hops

[mblauser]

The map draws a direct line between nodes separated by 1+ hops, particularly noticed when a router node (not broadcasting its location) exists between two other client nodes.

Where client Node A and client Node Z (both clients broadcasting their locations) are not within range of each other, but router Node R (NOT broadcasting its location) relays messages.

The map (as expected):

• displays Node A
• displays Node B
• does Not display router Node R

The map (unexpectedly):

• incorrectly displays a communication line between both client Nodes

Real illustration example:

Nodes BLUE and MHB do Not communicate directly to each other, but are separated by a router node which does not broadcast its location. Nonetheless, the map illustrates direct communication.

I can/will provide JSON node detail upon request.

Solutions: Either 1) do Not display line between pairs of nodes unable to directly communicate with each other, or 2) allow the user the option of statically setting a (potentially) known location for nodes which do not broadcast their locations. {I would advocate for this new feature}

In the hypothetical above, if the location of router Node R is known, allow the user to set its location. The map would then draw a line between both:

• client Node A <-> router Node R, and
• client Node Z <-> router Node R

otherwise if location of router Node R remains unset, do Not draw a line between Node A <-> Node Z

[mblauser]

If the option for locally setting lat/long/alt override values were added for nodes (particularly for known static node locations which otherwise do not broadcast), where might we store this persistent data?

Perhaps in a new node override/static file using JSON? or in persistent storage which already exists (idb-keyval)?

Would we then A) first lookup (override/static) location data from persistent storage, then if needed B) lookup dynamic location info to see if it exists for the target node, when plotting nodes on the map?

[Kealper]

Would we then A) first lookup (override/static) location data from persistent storage, then if needed B) lookup dynamic location info to see if it exists for the target node, when plotting nodes on the map?

Oof, that's a good question, the old sysadmin in me wants to say that the local override should be checked before data from the node itself (for example, /etc/hosts and similar) but I can also see where if a node is unknown and is now sending a potentially-more-accurate position than what's in the override, or a new position due to the node being moved by the owner... I can also see where it might be helpful to treat location information coming from the node to be of higher priority than the local override...

However: I feel like the right move may just be to have the override be checked first and take priority and if that does cause problems due to the node's actual position no longer being accurate to the override, let that be the user's problem that set the override. I guess some sort of thing in the UI could show that the node on the map has an overridden fixed position, and if the node has position information coming from the local node's NodeDB that is farther away than some set value (say maybe 100 feet or something) then show something that implies that the overridden value may not be accurate. Displaying that in that manner may be too much work for something that isn't likely to crop up hardly at all, though.

[Soltares]

I added a calculation for approximate node position when a node (without a known position) is included in a traceroute for nodes that have position data. This way at least it is clear in the map that a node exists somewhere in the area to bridge the connection.

One confusing piece is that the broadcast id (4294967295) is showing up in some of the trace routes. It seems to indicate "Unknown Username" in the Android Meshtastic app.

It's unfortunate we can't tie this to a more specific node ID, but I still left in in the location calculation for now. I do like the idea of having the ability to override a node position if missing or incorrect, but at least this is a start and is automatically calculated.

[mblauser]

I had not considered including node hops with approximate positions, but I like this approach. It works well in my testing.

Which user preferences file makes most sense to contain override locations for specific nodes?

Can you shed more light on the broadcast id !ffffffff (4294967295)? Is this due to messages from Repeater nodes?

Recently seen in an updated Android client:

In this case, node 'ffff' does not actually appear in the Android client node list, and seems to correspond with !ffffffff in other client versions. In an iOS client, I simply see mention of --> Repeater (0.0dB) -->

An explanation of !ffffffff and the 'all' node found in some traceroutes might deserve mention in a FAQ.

[Kealper]

I'm not entirely sure what causes it, but I think it may be related to some weird (mis)handling of the 2.5 traceroutes by nodes running older firmwares. I've seen several times where one of the nodes in a hop that's known (a Heltec V3 set as ROUTER_CLIENT running firmware 2.3.9) will usually show up with the correct information in traceroutes but occasionally will just show as the broadcast address. It and my router act as a sort of "backhaul" link to connect two cities and there's no other nodes in the area that have the range to do that, so I'm sure that when the broadcast address shows up on traceroutes to nodes in that other city, it's actually that known node. It doesn't seem to be anything specific to MeshSense, as I'm seeing the same random quirk in MeshSense and the Android client, so I'm thinking that it's in the response payload itself.

I have yet to see any weirdness like that when all nodes involved in a traceroute are running some version of 2.5 though.

[Soltares]

Thanks for sharing! I'm hopeful as the ecosystem gradually upgrades firmware that the broadcast node will eventually disappear :crossed_fingers: