What Is The Actual Default Character String (PSK) That "AQ==" Points To In Firmware?

[ikearat]

I am using AQ== for my PSK in Longfast Channel 0. What is the complete string that comes from the Firmware when this "default" is called? I "found" an answer but it is in HEX and I don't trust my Hex editor to render the string correctly for "reasons". (Windows, Mac, Android, IOS, UTF-8, any of the conflicts usually found when dealing with cross-platform development). Sure I can try it myself but I would prefer to get the correct answer form someone who knows or has built this wheel before.
The reason I want to try this is, when I first received my Heltec V3 and without screwing around with it, another node was visible and the owner took pity on me and responded to my noob plea for contact. Now having changed the PSK to AQ== I see and get traffic from people when I enable MQTT but that node from the before-time is lost.

[ianmcorvidae]

The key within the firmware source is not base64-encoded, but is available at https://github.com/meshtastic/firmware/blob/master/src/mesh/Channels.h#L140

AQ== corresponds to the very last byte in that, the 0x01. That key, base64'd, is 1PG7OiApB1nwvP+rz05pAQ==

Other one-byte keys are possible, and replace the final 0x01 byte of the key.

[ianmcorvidae]

The value stored on the device as part of the channel definition is the 0x01 value, though. The firmware automatically expands it to the full value before using it when it sees a one-byte key, since that data is hardcoded within the codebase.

[ikearat]

Thank you very much! My reason for asking has too do with my lack of understanding of the inner workings of the firmware. I was searching for confirmation that I had Not done something that was screwing up my communications. I put the PSK in full in the field and get the same results as allowing the hidden default to work it's magic. That other node is just not there anymore and it's coincidence that it went away at the same time I was trying to get the channel and position stuff to work. I have many more trials to overcome as yet but I will try not to bring them to discussion before trying everything I can find first.

[Th3H0ff]

Hi all
My apologies for injecting a question but I feel it's related. Is there a difference between using AQ== as PSK or leaving the PSK blank?
I'm at a situation where I use LongFast as a secondary channel and I'm experiencing "inconsistencies" where AQ== have my nodes not receiving messages but can transmit whereas a blank PSK works 100% for all my nodes.
I use a private primary channel for all my location and sensory data but it would be nice to connect with someone else and it would be shame to miss out just because I have a blank PSK for LongFast.

[ikearat]

I was watching this question in the hope someone who knows the answer would respond. I am getting use to not seeing responses from the developers or anyone at all. Near as I understand it when you leave the PSK field blank your messages are sent unencrypted. This may be why it works across your setup on all unencrypted channels. Something is wrong (as far as I can see) with the routing of encrypted messages and no one who understands how this works is making any comment.

[Th3H0ff]

Agree. Hence my urge to create a thread on the topic. https://github.com/orgs/meshtastic/discussions/57
Could be we will get something forthcoming.

[garthvh]

The docs have great search just for stuff like this https://meshtastic.org/docs/configuration/radio/channels/#psk