Version 2 and RFM69

[shabba]

I want to update my sensors to 2.0 - I had a look at the options in keywords.txt and MyConfig.h and I am trying to figure out where to set the ENC key for RFM69s.

My defines at moment are :
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RF69_868MHZ
#define MY_GATEWAY_SERIAL
#define MY_RFM69_NETWORKID 100
#define MY_RFM69_ENABLE_ENCRYPTION

Can I use #define ENCRYPTKEY "sampleEncryptKey" from the RFM69 lib?

PS Are the examples on the website still 1.5 based ? eg https://www.mysensors.org/build/serial_gateway

Thanks!

[hek]

The encryption key must be written into the EEPROM, see an example here how to write it here:

https://github.com/mysensors/MySensors/blob/f0f2542df40c1ac3d4bb6d43b856bc8c6fc61a21/examples/SecurityPersonalizer/SecurityPersonalizer.ino#L1052

And then (like you do) enable MY_RFM69_ENABLE_ENCRYPTION

[shabba]

Ok so to be clear - all users of RFM69 will need to add a function to their sketches to do this? OR does it have to be done in advance with a separate sketch?

Thanks!

[hek]

It can be done once in a separate sketch. Using something like this:

#define MY_CORE_ONLY
#include <MySensors.h>

/** @brief The user-defined AES key to use for EEPROM personalization */
#define MY_AES_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
/** @brief The data to store as AES key in EEPROM */
const uint8_t user_aes_key[16] = {MY_AES_KEY};

void setup() {
    uint8_t key[32];
    memcpy(key, user_aes_key, 16);
    hwWriteConfigBlock((void*)key, (void*)EEPROM_RF_ENCRYPTION_AES_KEY_ADDRESS, 16);
    Serial.println("Encryption key written successfully.")
}

[shabba]

Thanks @hek - it might benefit others to have this somewhere more obvious? Maybe on the serial GW page?

[hek]

Yes,

I wasn't aware of these changes by @Anticimex (had to read the code :) ). We should probably have a sketch ready in the examples for loading/setting the encryption key. @Anticimex, will you fix that or should I?

[Anticimex]

All security related functionalities are documented using doxygen. If it is not documented there it should be. If documentation is for any reason needed elsewhere, it should link to doxygen.

[shabba]

@Anticimex I read the doxygen docs and was still not clear on what I needed to do as this was a define in 1.5. Also there will be a lot of users who are not s/w devs etc and this might be a stretch to figure out.

Also can this be done in a pre function?
I could try and submit a patch to set it via a define?

[Anticimex]

@shabba no, I do not want secrets in the code as defines. If you find the documentation inadequate, please help me understand what information is missing or unclear.

[shabba]

@Anticimex I just did not even know where to start looking. I read in another thread to look in SecurityPersonalizer.ino but it was still not apparent if I had to do that etc. People who came from 1.5 would not know that it was not a software defined setting. Not sure how many people just use the examples to base their sketches on but I really don't know the user base like you do!

[Anticimex]

@shabba to be honest, you are the first one that have had difficulties understanding the documentation (to my knowledge). So I would really appreciate any feedback on how it can be improved.

[shabba]

I guess I don't think people should have to dig into the doxygen docs for this stuff.
It is not even mentioned in https://www.mysensors.org/download/sensor_api_20 so do people need to clone the repo (like I did and build the doxygen docs) to figure it out?
When I first starting using MySensors I derived all my knowledge from the example sketches. Only when I could not figure stuff out that I even looked at the api and serial docs etc.

Don't get me wrong - I really hope this is construed as feedback and not criticism in any way!

[Anticimex]

@shabba doxygen documentation is linked directly from the github front-page. It is rendered and browseable for anyone. But if there is an example for rfm69 and encryption it should mention the need for personalization for sure. But I was not aware such an example existed.

[martinhjelmare]

@Anticimex

Maybe going off topic:

Have you considered converting the doxygen ouput to Sphinx docs, via eg Breathe, and hosting it on Read the Docs, or your own RTD server?

https://readthedocs.org/
https://breathe.readthedocs.io/en/latest/

Personally I think the doxygen docs site is very unintuitive. Disclaimer: I'm not experienced in reading doxygen docs. I think Sphinx output and categorization is closer to how the code is structured, and it's easier to find what your looking for. This is very hard on the site in my opinion, eg the base MySensors API methods, send, wait etc, where are they?

I really appreciate all the hard work from the core team and not least from you, @Anticimex. So don't take this the wrong way. It's my biased view, coming mostly from Python.

[Anticimex]

@martinhjelmare no offense taken at all. The situation with doxygen is that it is very much in progress and essentially is it only the signing parts that are completed. So you won't find the docs complete nor comprehensive in any way (except perhaps for signing/security) and even that could very well need some updated if it is not clear enough already. I personally find doxygen as good as you make it. So hopefully, with time, the overall state of the documentation will improve and with it, the readability of it as well.

[Anticimex]

@martinhjelmare @shabba @hek I've updated the sketch conversion post with a note about security settings: https://forum.mysensors.org/topic/4276/converting-a-sketch-from-1-5-x-to-2-0-x

[shabba]

Great stuff @Anticimex - Now IMHO all we need to do is link the sketch and maybe pin that forum post or link from main page or similar.

Thanks!

[Anticimex]

@shabba thanks, main site matters I leave to @hek to decide upon.