Help me understand LongFast PSK difference

[Th3H0ff]

Hi all
I have a three node setup which I use to try to understand the LongFast PSK setting. As I've read AQ== is a representation to a hardcoded key but what I don't understand is the difference in the result I get if I use a blank PSK or AQ==. I've tried to visualize it with these images.
My "Base" is a Heltec V3 with a rooftop antenna. LilyGo is a Lora 1.6 and Heltec is another V3 with the default antenna. Base and Heltec are version 2.5.7 and LilyGo is 2.5.9. On my Base and "Heltec" nodes I have a primary admin channel with a private key for GPS and telemetry, both these nodes have LongFast as a secondary channel and frequency is EU868. The Lilygo is flashed clean and my goal is to simulate a transient node/tourist passing through my coverage.

Below is where I have configured all nodes with AQ== as PSK for LongFast. Green lines is a received message, red silence.

This time I have configured all nodes with a blank PSK for LongFast.

On my private admin channel there is never any issues with messaging and telemetry flows back and forth but I still want to be sure I can pick up other nodes.
Can anyone shed some light on why I'm seeing this?

[adingbatponder]

Lovely test. Are the arrows all messages sent in LongFast i.e. NOT direct messages?

[Th3H0ff]

Correct. Everything is on the LongFast channel, no DM.

[ikearat]

I so want to see/read the answer to this. My single Heltec V3 exhibits symptoms of this kind of inconsistency. I sometimes can't see a target node however it can send to me but I can't send to it. Sometimes the same node comes into 0-hop range and I can see it but they can't answer my messages. Same settings however without the admin channel and channel 0 set to LongFast, PSK AQ==

[garthvh]

A device with no key won't communicate with a device using the default key. They also need to have the same Lora config values to communicate.

[Th3H0ff]

That is understandable. My issue is why I'm getting different result despite all settings being the same.

[adingbatponder]

A device with no key won't communicate with a device using the default key. They also need to have the same Lora config values to communicate.

Could you explain this in a bit more detail? Seems terribly important. How does one get a device to have "a key" ?

[UptonAK]

also having trouble with this. I have an older t-beam that is hard to reach running year old firmware, but network connected. I just got some new heltecV3's (just flashed latest beta) and are unable to communicate with the tbeam on LongFast/Primary/. tried AQ== and no password.
From forum posts on the old discourse channel, it sounds like this default channel name depends on the device the unit was setup on? ios and android had different default channel settings?
Too bad if true. I think its rather important to have an open hailing channel that is set on all devices by default.

[UptonAK]

th3hoff, I took my laptop up the hill and updated firmware on the tbeam. After lots of trial and error, I found a configuration that works. In the triangle below, I got all three devices to send and receive to each other.
on the top HtV3, I flashed firmware and did nothing besides set the country to US.
on the other two, I had custom channel names and passwords for Ch Primary and Ch. 1. On Ch. 2 I set the settings to:
SECONDARY
AQ==
LongFast

even after the update, the t-beam does not show the password or the bit length of the password. not sure why.

[Th3H0ff]

So you basically replicated my test and got positive results? That's both good and anoying on my part. Means I probably missed something.

[UptonAK]

that was after 4 or 5 hours. it did not work to begin with an im not exactly sure what changed along the way but that was the working condition in the end.
some things that caused problems:

1. chrome serial connection failures. by the end of this I had to physically reconnect each board I refreshed the client page. Resetting the com port permission made things go smoother.
2. not all of the messages arrived at the same time so I cant say that they werent being forwarded from one to another.
3. after updating the tbeam, the client page (connected over network), would only allow me to send one message and then I have to refresh and reconnect.
4. Initially, the channels were created on the tbeam before I updated it (this firmware was from before the major security update) and then copied over to the other board. this did not work and I had to use the channels created on one of the new HtV3's and then copy that over to the updated t beam.
5. I tried many combinations of , LongFast and Primary before discovering for sure that they all default to "LongFast" (which is displayed on the device screen... but i was looking on the web interface). it is rather confusing that the channel name on the menu will say Ch 2 if left blank in the settings, but is actually LongFast.
6. combinations of passwords, from the one you commented on in https://github.com/orgs/meshtastic/discussions/35 , and of course AQ==.
7. also notice that the unedited HtV3 on top only sees the t beam as UNK where as the one on the right gets the name correctly. no idea. also that 2:00PM time stamp came up on a lot of messages.
8. until the update, the lock icon for the t beam (when viewed from the HtV3) was yellow. after the update, it became green.

long way of saying what the documentation does in fact say, LongFast with AQ== but I think there is more to it than because I was just getting some very weird results along the way.