Send data to a private Meshstatic channel?

[plight2060]

Thank you for sharing this very well-crafted project. I've been looking for a way to send text (sensor data)
from an ESP directly to a private Meshtastic channel for a long time.
I've tried your code, and it works, partly successfully on the primary channel (AQ==).
I'd like to ask if there's a way to send text to a private channel using your code.
In practice, you need to specify the same channel name in addition to the same key for it to work.
This would probably need to be expanded in your code?
Perhaps you can give me a tip.
Daniel

[bertrik]

If the private channel uses the same radio settings as the LongFast channel, it should just be a question of using a different key. How the "short" keys work (like AQ==), is that they just replace the last X bytes in the default key
https://github.com/bertrik/mesh-backend/blob/master/esp32/esp32.ino#L17

So "AQ==" is base64 for 0x01, so the key corresponding to that is already the "default" key, with the last byte being 0x01.
If you have the base64 representation of your private key, you can convert that to hex, for example using
https://base64.guru/converter/decode/hex
Then use those bytes to replace the lower bytes in the default key to get your full private key.

I don't plan on extending this code much further, it is meant as a minimal basic example and as template for copy-pasting into other projects. Maybe I could add the base64 decoding / padding in the code.

[plight2060]

@bertrik
I've now converted the base64 key from my private channel into hex numbers and
replaced them in Line17. Unfortunately, I can't see the data in Meshtastic yet.
I probably haven't fully understood it yet, but I'll try again and I'm sure it will eventually work.
Thank you for the information and the quick reply.

[bertrik]

Sorry, line 17 is not correct, I pasted a misleading link.
The key is the one at DEFAULT_KEY at line 20.

In the meantime, I added a 'key' command to set the key as base64, so type
key AQ==
for the default key for example.
It then prints the new combined key and uses that until you set a new key, or reboot.

[plight2060]

Yes, I saw it and tested it right away. I think the key thing is great.
I'm still trying to send/write to a private channel, but unfortunately, I haven't succeeded yet.
I have a monitor running at LongFast, and it seems that the packets are being sent out cleanly.
Could it have something to do with the encryption function? Or with the longer key in general?
(e.g. I use CAvFrKXnOQfXYaOI9uZuZA== and the channel name is channel2)

[bertrik]

There is talk of a 'channel hash' in the 16-byte header here: https://meshtastic.org/docs/overview/mesh-algo/
I don't know exactly what it does, how it is calculated and if it's value is critical for mesh behaviour (or just a 'hint'?)
It could be that this needs a specific value for the packet to be processed/recognised.

This is the byte at offset 0xD (13 decimal).

[bertrik]

I think I understand now, the hash is just the XOR of the channel name in ASCII and the 16 bytes of the channel key. This has to match the hash at the receiving end exactly. The current 0x08 value is the magic value for "LongFast" and the default channel key.

I think I'll fix this tomorrow, change the 'key' command to a 'channel' command where you specify both the name and the base64 short key.

[plight2060]

Congratulations, excellent, it works now, you've hit the right spot.
I've done some tests and transferring to a private channel now works perfectly.
Perhaps one more general note that may be disruptive during testing: in order for the app to display the
sent text, packet_cnt is increased by 1 after each transmission.
This means that if the app is recompiled in the meantime, packet_cnt reverts to the initial number,
which means that the packet is no longer displayed in the app (but would be automatically reset after about a day).
To prevent this, the Mestatic device must be reset after compiling so that the new transmissions are displayed again immediately.

Thank you again for the great software.

[bertrik]

I'm familiar with the LoRaWAN specification. LoRaWAN requires that the message counter increases strictly. This helps against replay attacks and detecting duplicates. Meshtastic does something similar, but I don't know exact requirements. So probably when meshtastic receives something with a source id and packet id that it has seen already before, it probably ignores it as a duplicate.

A solution could be to store a packet counter/id in non-volatile memory so it increases independently of firmware updates.
On the other hand, we should probably try to avoid wearing out the flash memory with frequent writes.
A solution could be to increase the counter with each message, but store it to flash only every 16 transmissions or so. Then on reboot we skip the counter ahead by 16 steps to account for the counter values we might not have stored.

[plight2060]

There is no need to take any action here. I only mentioned it because it can be irritating during testing.
This situation does not occur during normal operation, so it is not a problem.
Perhaps one more question: I have noticed that the transmission also works with other modem settings, not just with LONG_FAST, which is very good.
Is it correct that the channel_hash can always remain at 8, even if a setting other than LONG_FAST is selected?
I did some more testing today and everything works perfectly.
Thank you very much.

[bertrik]

The channel hash only depends on the channel name and the channel key, not on the radio properties. So yes.