Firmware 1.14.1 not obeying path.hash.mode, sending adverts of different hash sizes randomly

[kbatespdx]

Hello everyone,

I operate a repeater (a heltec T114v2) currently running firmware 1.14.1 I have set via the CLI "set path.hash.mode 1" and have confirmed via get path.hash.mode. I am seeing the node advertise both 1byte and 2byte path hashes seemingly randomly upon its advert interval. I have reflashed 1.14.1, rebooted, set path.hash.mode multiple times and I still am unable to get the device to consistently adhere to the advert hash mode.

I do not seem to have this issue on repeaters with other boards (such as the heltec v4) I have ordered another T114 for testing, I will attempt to reproduce the issue on the new node and update this.

[liamcottle]

Hey there, thanks for the report.

For flooded adverts, this was fixed in fcfdc5f.

However, I'm assuming that those 1-byte adverts you're seeing are zero hop adverts?
Would you be able to check the path of them in the analyzer?

From what I can tell, sendFlood is now correctly using the path hash mode in v1.14.1, however sendZeroHop used for the next "local" advert, doesn't use the path hash mode.

There's no intention of flooding/hopping here so the path hash mode isn't used, as there's no path segments in the packet. This would however mean that the zero hop packet shows as a 1-byte path (0x00 path_length encoding) rather than 2-byte (0x64 path_length encoding)

[kbatespdx]

Wonderful, that makes sense and I do believe you are correct. I was able to speak with another local user who confirmed their companion saw my advert as 2byte correctly.

This must be an issue in our implementation of the mqtt data. Repeater and the observer are within direct range of each other, and when initiating a flood advert from the repeater, the advert is seen by letsmesh and others but the geographic data and route info seem incorrect/do not make sense. Thanks for your time, I will continue to investigate and raise another issue if needed. Appreciate it!

[vaizki]

From what I can tell, sendFlood is now correctly using the path hash mode in v1.14.1, however sendZeroHop used for the next "local" advert, doesn't use the path hash mode.

Yes, my repeater 4201 with hash mode 1: when doing flood advert starts with 11 04 42 01 while direct (local) advert starts with 12 00 42 01. This has caused my repeater ID to flap between 4201 and 42 in CoreScope etc. This is now fixed in CoreScope it seems and it will use the flood advert hash size.

There's no intention of flooding/hopping here so the path hash mode isn't used, as there's no path segments in the packet. This would however mean that the zero hop packet shows as a 1-byte path (0x00 path_length encoding) rather than 2-byte (0x64 path_length encoding)

@liamcottle: my question is that is this intended behavior or will the zerohop packets also change later to reflect the hash mode in the high bits of the path length? Or would that break something in older firmware where there is a == 0x00 comparison without a bitmask?

I've submitted a PR to CoreScope to ignore zero hop adverts when determining repeater path hash size.

[IZ1HMT]

I ran some tests and found with other friends using different firmware (from 14.0 to 15.0 and with various hardware) that all RPTs are configured in 2-byte mode, but if we read the spontaneous Adverts, i.e. those that are executed every 3, 6, 12, or 24 hours depending on the configuration, they output at 1 byte; while if we force them manually, they output at 2 bytes. We saw this in "Tools" "RX Register".

[vaizki]

I ran some tests and found with other friends using different firmware (from 14.0 to 15.0 and with various hardware) that all RPTs are configured in 2-byte mode, but if we read the spontaneous Adverts, i.e. those that are executed every 3, 6, 12, or 24 hours depending on the configuration, they output at 1 byte; while if we force them manually, they output at 2 bytes. We saw this in "Tools" "RX Register".

Yes, exactly as my previous comment described.. DIRECT adverts are sent often and for some reason don't have the byte-mode bits set in the path length (it's always 0). In FLOOD adverts the path mode is set. They are basically the same packet but with different routing, the direct one is only for direct neighbors (they are not allowed to repeat it) while the flood is meant to traverse the mesh.

Why this difference I don't know. I've also tried asking about it on Discord and in GH issues but no answers.

[TeTeHacko]

@vaizki your question from April was never answered, so for the record — the compatibility concern does not apply, and it is checkable in the tree:

Dispatcher.cpp already masks the two halves of that byte apart on receive:

pkt->path_len = raw[i++];
uint8_t path_mode = pkt->path_len >> 6;  // upper 2 bits (legacy firmware: 00)
...
uint8_t path_byte_len = (pkt->path_len & 63) * pkt->getPathHashSize();

The legacy 00 is explicitly accounted for, and nothing in the tree compares the whole path_len byte against zero to detect a zero hop packet — zero hop detection goes through getPathHashCount(), which is path_len & 63. So a zero hop packet that declares 2 or 3 bytes parses correctly on existing firmware; there is no == 0x00 comparison to break.

I have opened #3293 with the fix. path_hash_size defaults to 1, so every caller that does not pass a size produces byte-identical output to today, and the examples that have a path.hash.mode setting now pass it — mirroring their adjacent sendFlood() calls.

@IZ1HMT's reproduction matches: the spontaneous (local/zero hop) adverts were the 1-byte ones, the manually forced flood adverts the 2-byte ones.

For anyone else censusing hash sizes from live traffic in the meantime: the same caveat as your CoreScope fix applies, zero hop packets have to be excluded. Counting only packets carrying at least one hop, where the width is corroborated by the path length rather than merely declared, a sample of 1041 packets on the Czech mesh came out at 849 packets / 158 senders on 2 bytes, 107 / 4 on 3 bytes and 85 / 32 on 1 byte.