🚀 [Feature Request]: Mark nodes that correspond to nodes that didn't decrypt a traceroute

[ianmcorvidae]

OS

iOS, iPadOS, macOS

Description

meshtastic/firmware#4056 is only just merged, but will mean that (once nodes are updated, and all that), nodes along a traceroute path that don't decrypt the packet and therefore don't add themselves to that path will show up as 0xFFFFFFFF when detected by a later node along the path. these should appear as unknown nodes already, but they should be distinguished in the traceroute display so it's known when a hop doesn't share a channel or is an ALL_SKIP_DECODING repeater. Additionally, during the period of time where nodes after a missing hop may still not have recent enough firmware for that PR, these dummy nodes can in theory be added to the path in a spot later than their actual location in the path, since they'll be added just before the first node past the missing hop in the chain, that has recent enough firmware, which makes it beneficial to identify them specifically compared to "regular" unknown nodes.

(this is an issue paired with meshtastic/Meshtastic-Android#1080 and has the same/copy-pasted description)

Participation

• I am willing to submit a pull request for this issue.

Additional comments

No response

[garthvh]

Not sure end users really need to know if an Unknown node had a key or not.

[garthvh]

So I updated the trace route node name string to use if available

• User.LongName
• If nodeID == 4294967295 show "Repeater"
• Hex Node Number
• Unknown

If a client has a structure for handing nodes without a node info I think most of them are going to want to exclude the 4294967295 getting saved into the database / object graph.