Add two-way traceroute result with SNR per hop

[GUVWAF]

Since the route a packet takes on the mesh is often asymmetric, this will record the nodes a traceroute passes through not only on the way towards the destination, but also when going back to the origin. Furthermore, a per-hop signal quality is useful to know, therefore each node also adds the SNR it received the packet with. The SNR values use 1 byte and are in dB, but scaled by 4, so e.g. a value of -65 is -16.25dB.

Since older firmware will not add the route on the way back and neither add SNR values, newer firmware will try to add unknown hops (represented by 0xFFFFFF NodeNum) and unknown SNR values (represented by INT8_MIN, which equals -128) based on the hop_start and hop_limit field, which are introduced in 2.3. If there's a node with even older firmware in between, the route back and SNR values will be incomplete.

Example serial output:

Route traced:
0x10 --> 0x11 (-5.50dB) --> 0x12 (-4.75dB) --> 0x13 (7.00dB)
(-5.50dB) 0x10 <-- (-4.75dB) 0x11 <-- (7.00dB) 0x12 <-- 0x13

Example output for the CLI (still needs to be implemented) when there's a node with old firmware in between:

Sending traceroute request to !43876839 on channelIndex:0 (this could take a while)
Route traced towards:
!bff18ce4 --> !fa6c5f90 (?dB) --> !43876839 (5.75dB)
Route traced back:
!43876839 --> ?? (?dB) --> !bff18ce4 (13.25dB)

[jp-bennett]

Tested with my collection of nodes, some running 2.4, some running 2.5. Seems to work as expected.

[djholt]

@GUVWAF I came looking for the possibility of a reverse traceroute feature, and found that you've just added it! Thank you!

I'm now working to test this out, but I'm only seeing the forward traceroute—the backwards route does not show. I'm running 2.5 on my nodes as well as the 2.5 CLI. Any suggestions to what I might be missing? Thanks!

[djholt]

A bit more investigation: it looks like the backward route was sent in the payload (pasted below for reference), but I'm seeing that the CLI requires the snrBack length to be exactly one larger than the routeBack length. This isn't the case in my test, and so the backward route output is omitted.

{ 'route': [1976486896], 'snrTowards': [18], 'routeBack': [1976488812], 'snrBack': [8] }

The back route is indeed different than the forward route, each direction taking a different intermediate node.

[GUVWAF]

@djholt Are all nodes in the route on 2.5? Indeed because both the intermediate nodes (the ones in the route) and the destination add their SNR, the SNR list should be one larger than the route. Otherwise, it might mean there is a node with older firmware in between, which doesn't add its SNR, nor the route back, so then we can't map the SNR to the correct nodes.

[djholt]

@GUVWAF Okay, that makes perfect sense. Yes, all of these nodes are 2.5. Could there be any reason a 2.5 node wouldn't add its SNR? I have verified that the route and routeBack lists are working across many different test routes. I'll do some more testing to be absolutely sure, but I've observed that snrTowards and snrBack have the same length as the route forward and back.

[GUVWAF]

@djholt No, I don't see a case where it would add itself to the route and not the SNR, and also the destination should always add its SNR. It was also the case in my testing. You get this info from the Python CLI, when printing the traceroute response packet, right?

[djholt]

@GUVWAF Yes, that's right, using CLI with --traceroute and --debug. I've verified the same details when sending a traceroute in my own Python script and checking the response.

I've tested a number of different routes—all 2.5.0 nodes—with either 1 intermediate node, or 0 intermediate nodes (direct), and in all of these cases, snrTowards and snrBack are length 1 in every instance. This leads me to suspect that destination nodes are including their SNR and intermediate nodes are not in my case.

[GUVWAF]

Thanks for reporting this, @djholt ! Found a bug and will look into fixing it soon.