Armachat - standalone offgrid messenger

bobricius · September 9, 2020, 9:17am

Hi everybody,

I am working on this standalone messenger, is based on SAMD21+RFM95 with QWERTY kayboard
and small tft display

I have now only simple device to device communication

Thinking about meshtastic compatibility but it look like very complex device + android app.

Supporters are welcome http://patreon.com/bobricius

drewsed · September 9, 2020, 6:06pm

Hi,
I already stumbled over your projects/youtube videos and was really impressed by your PCBs. The devices look really retro, which I think is very nice.

Only the fancy interface is a little bit too much for my taste.

When I was was a child, I dreamed of such devices to text with my friends in our small village. Would be great if I can give such devices to my childs (some time I have some^^).

lburrowes · September 10, 2020, 3:07am

I remember this project when I was doing research and it looked very promising. Still has potential for multiple applications where there is no smartphone involved. Would be good to find a way to protect your messages to have some privacy.

Spor7biker · September 10, 2020, 6:24pm

As long as there is enough RAM I think running Metastatic would be relativity easy.

This could be an excellent stand alone device without Bluetooth or the Android app.

geeksville · September 10, 2020, 8:07pm

Yep. I haven’t looked but if it is esp32 based I suspect it would be a fairly straightforward effort (a couple of days?). At least initially - then you’d want to add a local message composition UI to take advantage of that nice keyboard.

bobricius · September 10, 2020, 8:39pm

It is based on SAMD21 I am not good programmer, I read your protocol and everything here is super high level. Maybe I will succeed with only forward messages over Meshtastic network between 2 armachat units, or I just use your addressing scheme and radio settings.

bobricius · September 12, 2020, 9:49pm

I configured radio, rewritten addressing.
now I receiving encrypted meshtastic packet, I can decode header
Also I can send packet to meshtastic network, nodes forward empty package
with message I receive debug “Invalid protobufs in received mesh packet!”
protobufs are far away from may skils, also encryption, maybe if meshtastic can forward raw packet
etc some flag in header. With this I can use meshtastic network as relay between armachats.

is somewhere described FLAGS bytes in header? I received etc FLAGS: 15:fd:45:03

geeksville · September 13, 2020, 7:44pm

re: FLAGS encoding documentation.
Sort of ;-). Here https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/mesh-alg.md and https://github.com/meshtastic/Meshtastic-device/blob/915427c9649364f03ca18c281f84998bfe0f2afe/src/mesh/RadioInterface.h#L14

Though I’m not surprised that your packet got dropped (because yeah - it didn’t like the encryption of the payload). Alas, currently meshtastic assumes that (even for routing other packets) that the payload is protobufs. I wouldn’t be too scared of protobufs because the tools to convert proto files into C++ code are pretty painless (see bin/regen-protos.sh for how we do it). Also - the generated code is tiny.

I’m a huge fan of protobufs because they are a) pretty small on the wire, b) nicely self documenting, c) cross platform (which was important for meshtastic talking to outside devices/APIs/apps). For instance, here’s how the payload portion of a meshtastic message is representated:

github.com

meshtastic/Meshtastic-protobufs/blob/28243316862f3827d6f173e35edbaf5ed7cee739/mesh.proto#L174


  NO_ROUTE = 1;

  // We received a nak while trying to forward on your behalf
  GOT_NAK = 2;

  TIMEOUT = 3;
}

// The payload portion fo a packet, this is the actual bytes that are sent
// inside a radio packet (because from/to are broken out by the comms library)
message SubPacket {

  // Only one of the following fields can be populated at a time
  oneof payload {

    Position position = 1;
    Data data = 3;
    User user = 4;

    /**
    A route request going from the requester

That said: It wouldn’t be too hard for me to add a “send this opaque blob” flag like you describe. Would you mind putting a bug in meshtastic-device? Though there are some higher priority 1.1 features ahead of it, so it will be a couple of months.

bobricius · September 13, 2020, 7:38pm

Thanks for links, I am watching to your sources every day, your points are very helpful.
Now are packets encrypted or they are only protobufs? one packet is is entire text message or is divided to more packets ?
I created github issue for this feature https://github.com/meshtastic/Meshtastic-device/issues/383

Thanks for help.

geeksville · September 13, 2020, 7:43pm

the headers are never encrypted, but the payloads are encrypted when sent over the wire (these payloads correspond to “SubPacket” in the protobuf documentation).

And entire packet corresponds to “MeshPacket” in the protobuf docs, but that’s the one place we don’t use protobufs when going over LoRa (though we do when sending them over bluetooth, serial or wifi). Because we want the radio chips do do their own filtering based on addresses (eventually), we send all of those packet headers as the 16 bytes described in mesh-alg.md.

bobricius · September 17, 2020, 6:36am

If I good understand…
I receive header 16bytes (This easy and I have encoded)
next is payload encrypted with AES256 … where is encryption key?
key is fixed or changing?
After encryption I need received part encode do protobufs OK?

bobricius · September 17, 2020, 6:53am

one more stupid question where is etc “aes_wrap.h” or where is crypto library?

retrodime · September 17, 2020, 9:50am

Hey, I just saw your device.I would really consider buying some if they can handle the Meshtastic protocol.
It would be verry cool if you could try to make one dedicated for the meshtastic protocol by using a compatible chip and good amounts of ram.I don’t know how difficult this is but I would love to see an ARMA device with GPS and LORA independent from the phone.Thank you

bobricius · September 17, 2020, 11:56am

I have no programing skils for displaying meshtastic messages, maybe in future I can trasmitt messages in meshtastic network if autor implement raw forwarding. Also I want keep simplicity with using SAM21 as main MCU, which mave some advantages as native usb with simple drag&drop update to MSD device and low power consumption. Complete armachat with full bright display consume 60mA and with low bright 30mA. (30mA display, 10mA lora module, 20mA MCU)

geeksville · September 17, 2020, 8:37pm

I think I can help with those questions:

the encryption key is channel specific and shared as part of the channel ‘URL’.
the default channel key is well known (therefore not particularly secure) it is

    /// 16 bytes of random PSK for our _public_ default channel that all devices power up on (AES128)
    static const uint8_t defaultpsk[] = {0xd4, 0xf1, 0xbb, 0x3a, 0x20, 0x29, 0x07, 0x59,
                                         0xf0, 0xbc, 0xff, 0xab, 0xcf, 0x4e, 0x69, 0xbf};

The algorithm for the crypto is described here https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/crypto.md
aes_wrap.h comes in from the ESP32 toolchain. That toolchain gets fetched automatically into ~/.platformio when you do “pio run”. On the ESP32 processors I use their hardware AES implementation, on the NRF52 processors I use a ARM library that implements AES-CTR.
The keys for a channel can be set with the python tool or the android app. If the key is 16 bytes long we use AES128, if 32 bytes long AES256. ** if zero bytes long ** we turn off encryption. This might be useful for you. I think "meshtastic --setchan psk “” " should do this.

Oh yes, I forgot to record your request to support totally opaque payloads. I’ll put that in the wiki to do soonish.

Does that help?

bobricius · September 17, 2020, 9:29pm

Everything helps, THANKS
I am checking android app form all sides but I not found button for psk change, also no button for chat clear

geeksville · September 17, 2020, 9:36pm

Alas the Android app generates and installs auto generated random AES256 keys any time you make a new channel. If you want to turn off the enc currently the only way is the python cmd.

bobricius · September 17, 2020, 10:05pm

D:\PYTHON\Meshtastic-python-master\meshtastic>meshtastic.exe --device COM46 --setchan psk “”
Trigger powerFSM 9
Trigger powerFSM 11
Transition powerFSM transition=serial API, from=ON to=SERIAL
Shutdown BT: 237112 heap size
Connected to radio
Setting channel parameter psk to
Can’t set psk due to Cannot set ChannelSettings.psk to ‘’: ‘’ has type <class ‘str’>, but expected one of: (<class ‘bytes’>,)
Writing modified preferences to device

D:\PYTHON\Meshtastic-python-master\meshtastic>pause

I try everything

geeksville · September 17, 2020, 10:59pm

oh oops - I forgot, that field is a byte array, not a string. I’ll fix tomorrow: