Bug: Relay Nodes do not show what they are in packets/etc.

[Littleaton]

OK so looks like you recently added a relay node feature when listing packets/etc.

the problem is that those do not point anywhere, we cant see who/what they are.

If I open the packet, and mouse over the last node the packet hit, it shows me who/what it is but the relay node is red and does nothing

Another area, like on traceroute page, i click on the TR packet, and at the bottom we see the gateways that heard the packet, and see the relay nodes in the list, but they are again not click/linkable

This looks a lot like meshcore, and how they do their paths for packets. I think if you are going to have the relay node in there, make it pull the nodes short name, not its first byte or what ever that is.

[zenitraM]

I'll look into fixing the links not working, however, the reason for those not to be linked/computed in the relay list is because the Meshtastic packets only contain the last byte, not the whole node ID.

Therefore the packets page does a "optimistic" attempt of tracking which node ID may it be: it finds the nodes that received/sent direct packets to this node (via traceroutes or direct receptions) and then filters that list to nodes that match the relay node byte. This works pretty well in meshes that are not-dense, but is still prone to collisions (like in your last example in the screenshot, we can't know if the packet was relayed by WC2 or dsr1 as their IDs both finish in 6b). So that's why it shows both the byte (as that's unique) and the node (which may or may not be the node)

This computation is done in the packet details page, however in the packets list it gets harder to compute as it needs to run the same for every single packet*node combination on that list. Therefore why the packets lsit does not have the same, unless we add something to precompute those "relay candidate nodes" map and keep them up to date. 🤔

[Littleaton]

Cool thanks for looking into that. and thanks for the info on how it works and why.