[Bug]: LongFast secondary channel not sending messages with AQ== as PSK

[Th3H0ff]

Category

Other

Hardware

T-Lora v2 1.6, Heltec V3

Firmware Version

2.4.2.5b45303 and 2.5.4.8d288d5

Description

I just went to 2.5.4.8d288d5 Beta and then back to 2.4.2.5b45303 on my Lilygo 1.6 and Heltec-V3. During both migrations I did a flash erase using the Meshtastic web flasher. Now I cannot send messages on my secondary LongFast which I have set up according to https://meshtastic.org/docs/configuration/tips/#creating-a-private-primary-with-default-secondary. I have a primary admin channel with a PSK which works for both remote administration and messaging.

Both units have the same frequency slot, 1 for EU_868. Same PSK for LongFast, AQ==

If I create a third channel with random name and PSK, messaging works on that one. If I change the PSK to either none or a random one for LongFast, messaging works. If I change PSK back to AQ== it doesn’t work. If I use LongFast as primary channel with PSK AQ== it works. Even if no message is delivered, either in the app or shown on the device screen, the app show the cloud with the tick mark for each message.

What bothers me is that I’m pretty sure it worked before I went reflashing the devices

Relevant log output

No response

[caveman99]

AQ== is not really the PSK, but a placeholder for 'default key'. Try setting the one here instead ... https://github.com/meshtastic/firmware/blob/ddd4a45bc3a9d8e227f532d1a04a5508ecf54e31/src/mesh/Channels.h#L139

[Th3H0ff]

I see. In what format should I enter the PSK in the app (I use Android)? "d4 f1 bb 3a 20 29 07 59 f0 bc ff ab cf 4e 69 01" or just copy-paste from the code?

[Th3H0ff]

Update: I've tried to do some testing on this and whatever PSK i set for LongFast works, obviously if the key is the same on all devices, but not AQ==. My main concern isn't the key as such, I just want to be able to mesh and receive messages on the "default public" channel, while still having admin and telemetry on a separate channel

[GUVWAF]

It may be you're unlucky and one of your private channels ends up with the same hash as LongFast with AQ== (it's only a 1-byte hash, so collision is possible). You could try generating a new PSK for the primary channel, then it will create a new hash.

It makes sense that if you make LongFast with AQ== as primary it works, because it would choose the first channel where the hash matches.

[Th3H0ff]

A hash collision would be unlikely. My primary admin channel has a 16 bit key.

[GUVWAF]

@Th3H0ff that doesn't matter. When receiving a packet, the node doesn't know which key to use to decrypt. For that, there is a 1-byte hash in the header as a hint. It may happen that two channels end up with the same hash and it will try to decrypt with the wrong key.

I would suggest changing the key of your primary admin channel and try again.