💬 Security & Signing

[melwinek]

@Anticimex, @mfalkvidd But with the use of encryption so easily no one will take control, must break the code.
So it is best to simultaneously encrypt (eg RFID tag serial number when opening the gate) and sign (eg gate open message)?

[Anticimex]

@melwinek what prevents anyone from copying your encrypted message and record it. And then later send the same thing?
Encryption provides obscurity. You need signing for authentication. Signed messages cannot be repeated because they are always unique. Encryption does not necessarily guarantee that.

[t3chie]

@bilbolodz I am getting the same message with a Sensebender Micro. I configured it for soft-signing with LOCK_CONFIGURATION enabled. Now I wanted to switch to hardware based signing.

Any way to unlock a locked configuration?

[Anticimex]

@t3chie there is no configuration to lock for soft signing. Configuration locking only applies to atsha204a. And if locked it cannot be unlocked. And normally you shouldn't need to either as the default settings set are the one to use, and unless you have been very creative in hacking the personalizer that configured should work just fine.

[t3chie]

@Anticimex I tested first with softsigning but shortly after this realized that with soft signing the Sensebender has not enough space for debug messages.
I rerun the personalizer to switch to hardware based signing and hit the "Failed to wake device. Response: E7" message.
Played around and found that

#define MY_SIGNING_ATSHA204_PIN 17
instead of
#define MY_SIGNING_ATSHA204_PIN 4

made the personalizer happy again. I am still fighting with getting signing to work. Setting #define MY_SIGNING_REQUEST_SIGNATURES and MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL did not get me going.

[Anticimex]

@t3chie I assume you have personalized nodes and gw with the same hmac key?

[Anticimex]

@t3chie also that you also defined the signing enabled flag on all participants (but I think you get a preprocessor error if you don't)

[skywatch]

Is it possible to use the ATSHA204A along with the Rpi directly attached NRF24L01+ gateway? I can see how to attach the ATSHA to the nodes, but how to attach it to the pi?
Thank you.

[Anticimex]

@skywatch no, not to my knowledge. The atsha driver is Arduino specific. I would happily review a pull request that ports the bit banged driver for Linux though

[Anticimex]

@skywatch the use case for atsha204a backed signing on rPi is limited though. As it is used as I gw (I presume) it is considered "protected" and is less sensitive for key dumping.

[skywatch]

Thank you for the quick response. Maybe i mis-understand this?
I have got 10 ATSHA chips that I would like to attach to arsuino nodes to use with a raspberry pi based gateway/controller combo. Do I therefore need to attach the ATSHA to the rpi, or could I still use the ATSHA hardware on the arduinos without an ATSHA attached to the rpi?
I had assumed that the atsha chip would be needed at both ends for signing to work. Maybe that's not how it works?

[Anticimex]

@skywatch no, the software port is fully compatible with the atsha204a. So you can use Arduino nodes with atsha204a and they will work just fine with your rPi with software signing. Just as long as they all use the same hmac key.

[sineverba]

I'm hoping that I did done all ok.
I've personalized the Arduino that acts as Gateway (connected via USB to a Raspberry PI) and I've personalized first node (a DHT22).
Both with software signature.

This is the cat from Raspberry / Gateway Arduino:

0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;Skipping security for command 3 type 16
0;255;3;0;9;SHA256: 37FA7FD8F19D55E99C952F467E45D9A7439AAAAAAAAAA                                                                             AAAA
0;255;3;0;9;Skipping security for command 3 type 17
0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:37FA7F                                                                             D8F19D5CE9A07E95992C45D9A7439
0;255;3;0;9;Transmitted nonce
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=0,c=1,t=1,pt=7,l=5,sg=1:59.3
0;255;3;0;9;Signature in message: 010F55F31D04DBFCA0AFC7E139475
0;255;3;0;9;Message to process: 03033336D4201
0;255;3;0;9;Current nonce: 37FA7FD8F19D55E99C955992C45D9A7439AAA                                                                             AAAAAAAAAAA
0;255;3;0;9;HMAC: B50F55F31D04DBFFC7E139475D91093F0A1EABB174B86E9                                                                             E9
3;0;1;0;1;59.3
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=2,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;Skipping security for command 3 type 16
0;255;3;0;9;SHA256: 803B7127EB3B049768C59D328C89862FF731AAAAAAAAAA                                                                             AAAA
0;255;3;0;9;Skipping security for command 3 type 17
0;255;3;0;9;TSF:MSG:SEND,0-0-3-3,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:803B71                                                                             27EB3D0DED839579D328C89862FF731
0;255;3;0;9;Transmitted nonce
0;255;3;0;9;TSF:MSG:READ,3-3-0,s=2,c=1,t=38,pt=7,l=5,sg=1:3.42
0;255;3;0;9;Signature in message: 010E8B790708A39930F73D511F48DAECA
0;255;3;0;9;Message to process: 03002E23BAE5A4002
0;255;3;0;9;Current nonce: 803B7127EB3D0DED83957BB5C59D328C89862FF731AAA                                                                             AAAAAAAAAAA
0;255;3;0;9;HMAC: D10E8B79D511F48DAECAFB4A3D89F553A2DDB26F1614
3;2;1;0;38;3.42

and so on...

This is the Pro MIni serial console:

T: 28.00
1023
Battery Voltage: 3.44 V
Battery percent: 102 %
40413 Skipping security for command 3 type 16
40421 TSF:MSG:SEND,3-3-0-0,s=2,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
40429 Nonce requested from 0. Waiting...
40546 TSF:MSG:READ,0-0-3,s=255,c=3,t=17,pt=6,l=25,sg=1:9CC096EF18295BEFAC43638CA2673A1D759B0CEC6E49C3E060
40558 Skipping security for command 3 type 17
40562 Nonce received from 0.
40564 Proceeding with signing...
Message to process: 03002EF24002
Current nonce: 9CC096EF18295BEFA59B0CEC3E060AAAAAAAAAAAAAA
HMAC: 5D8E8A59EF1420406004E1318A650686E19E3A8
Signature in message: 018E8A5BD166D106004E
40740 Message signed
40749 Message to send has been signed
40755 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=38,pt=7,l=5,sg=1,ft=0,st=OK:3.44
40763 Skipping security for command 3 type 16
40769 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
40777 Nonce requested from 0. Waiting...
40900 TSF:MSG:READ,0-0-3,s=255,c=3,t=17,pt=6,l=25,sg=1:1C17F1A31D500CB0E840B7214BE961E
40910 Skipping security for command 3 type 17
40916 Nonce received from 0.
40919 Proceeding with signing...
Message to process: 03000E66
Current nonce: 1C17FE25D7B26441A31D961EAAAAAAAAAAAAAA
HMAC: D5992FF4CFB6238CD4062397EEE986F47E0BD65020F39C18662
Signature in message: 01992FF4CFB6238C0FDA62397EEE986F47E0
41095 Message signed
41101 Message to send has been signed
41109 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=0,pt=1,l=1,sg=1,ft=0,st=OK:102
41115 MCO:SLP:MS=5000,SMS=0,I1=255,M1=255,I2=255,M2=255
41121 MCO:SLP:TPD

Are they secure communicating?

PS I did delete some chars from the HMAC, nonces, etc etc

[Anticimex]

@sineverba the best way to determine that is to see if the messages you send arrive if you enable signing and require signatures, unsigned or incorrectly signed messages will be rejected.
I see no errors in the log so it seems it works. The logs however don't match up. The hmac:s in one log does not match the hmac:s in the other.

[sineverba]

@Anticimex
I can assure you that messages, nonces, hmacs and signatures are exactly the same in console gateway and in console of arduino mini.
I did delete some chars before posting for.... security (?)
Thank you for your answer!

[Anticimex]

@sineverba why did you delete them? There is nothing secret about them. They are sent over your radio link so they are to be considered very public, or signing wouldn't be useful, would it?

[sineverba]

@Anticimex
I understand
The last thing: what's the sense of this message:

Skipping security for command 3 type 17

?

Thank you!

[Anticimex]

@sineverba it means that message is not signed. Because it is of a type not suitable for signing. Typically an ack or a handshake message. You can look the type up in the api specification. In this case it is a handshake message (a nonce reply to be precise).

[sindrome73]

Hello!! I'm also trying to implement SOFT Signature, but because of my poor English I have many problems !!
Someone could post the socket of a node + a working MQTT gateway.

So you can study the code and understand how it works !!!

Thanks 1000 in advance to who can help me

[Anticimex]

@sindrome73 There is no difference for a MQTT gw than from other GW:s. There are code examples in the documentation. See this post and follow the Doxygen links.

[sindrome73]

As I said, my English is not good and therefore it is difficult for me to follow the discussions.

That's why I was asking for a snapshot already done, in order to study the code and understand how to solve ....
  If anyone can help me ????

[Anticimex]

@sindrome73 I am afraid it will be difficult to help if you can't read the code. There is code in the documentation, and you ask for code? There is also a sequence of steps required to do personalization, so you have to be able to understand english to some extent, or find someone who can translate for you.

If it helps, I have pasted the code here in case you for some reason can't find it (I assume you use a official 2.0 release):

How to use this

Before we begin with the details, I just want to emphasize that signing is completely optional and not enabled by default. If you do want the additional security layer signing provides, you pick the backend of your choise in your sketch. Currently, two compatible backends are supported; MY_SIGNING_ATSHA204 (hardware backed) and MY_SIGNING_SOFT (software backed). You can either enable these globally in MyConfig.h or in your sketch for sketch specific/local use.

Firstly, you need to make sure to pick a backend to use as described above.

//#define MY_SIGNING_SOFT
#define MY_SIGNING_ATSHA204
#include <MySensors.h>
...

Make sure to set the define before the inclusion of MySensors.h. It is legal to mix hardware- and software-based backends in a network. They work together.

You also need to decide if the node (or gateway) in question require and verify signatures in addition to calculating them. This has to be set by at least one of the node in a "pair" or nobody will actually start calculating a signature for a message. Just set the flag MY_SIGNING_REQUEST_SIGNATURES and the node will inform the gateway that it expects the gateway to sign all messages sent to the node. If this is set in a gateway, it will NOT force all nodes to sign messages to it. It will only require signatures from nodes that in turn require signatures. If it is desired that the gateway should require signatures from all nodes, MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL can be set in the gateway sketch.
If you want to have two nodes communicate securely directly with each other, the nodes that require signatures must send a presentation message to all nodes it expect signed messages from (only the gateway is informed automatically). See signerPresentation().
A node can have three "states" with respect to signing:

Node does not support signing in any way (neither MY_SIGNING_ATSHA204 nor MY_SIGNING_SOFT is set)
Node does support signing but don't require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is not set)
Node does support signing and require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is set)

Secondly, you need to verify the configuration for the backend.
For hardware backed signing it is the pin the device is connected to. In MyConfig.h there are defaults which you might need to adjust to match your personal build. The setting is defined using MY_SIGNING_ATSHA204_PIN and the default is to use pin A3.
Similar to picking your backend, this can also be set in your sketch:

#define MY_SIGNING_ATSHA204
#define MY_SIGNING_ATSHA204_PIN 4
#define MY_SIGNING_REQUEST_SIGNATURES
#include <MySensors.h>
...

For the software backed signingbackend, an unconnected analog pin is required to set a random seed for the pseudo-random generator. It is important that the pin is floating, or the output of the pseudo-random generator will be predictable, and thus compromise the signatures. The setting is defined using MY_SIGNING_SOFT_RANDOMSEED_PIN and the default is to use pin A7. The same configuration possibilities exist as with the other configuration options.

Thirdly, if you use the software backend, you need to personalize the node (see personalization).

#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#include <MySensors.h>
...

An example of a node that require signatures is available in SecureActuator.ino.

[sineverba]

#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7

I image not, but... the pin need to be to same in every node?

And.. will the library auto manage the PIN (in this case the #7) rendering it floating or need to explicity set it as INPUT on sketch?

Thank you!

[Anticimex]

@sineverba It is assumed that you do any configurations in your sketch, before including MySensors.h so no, it does not need to be the same on every node. It just need to be left unconnected. And yes, the library takes care of the rest.

[mfalkvidd]

The pin does not need to be the same.

The library will set it to the required mode, there is no need to do anything in the sketch.

[pepson]

Hi
I have a gateway mysensors on my RPI3 with radio RFM69HW. Is any chance to build gateway on RPI3 but also with chip ATSHA204A ? And how build it...

[Anticimex]

@pepson the driver has not been designed with rPi in mind. And you'd probably be better off with an I2C variant for rPi. But we currently don't offer a driver for that so you'd have to write it yourself.
But, for a gw, you typically keep those secured physically, so using a atsha device is less important, compared to "roaming" nodes.

[pepson]

@anticimex
I don't understand. I want secure my nodes... By Atsha204a. How I can secure it by other solution.

[Anticimex]

@pepson I have implemented a sw emulator for the atsha which offers compatible security infrastructure but without readout protection. Readout protection is needed if someone steals your node and extracts your hmac key. Your gw won't typically be stolen, so it don't need readout protection and can rely on the soft signing option which is compatible with nodes using atsha204a personalized with the same hmac key. The rPi port support the atsha204a emulator so you can use that to secure nodes that has a real atsha204a device.

[pepson]

@anticimex

Can you show me full manual how implement it on Gateway on RPI and how add this to sketch on nodes ? Please...
If you can describe me very good. I am begginer...

[Anticimex]

@pepson you have the links to the documentation in the article this thread is commenting on. At the very top.

[pepson]

@anticimex
But please show me as you have to have example...

[Anticimex]

@pepson I don't run on raspberry pi so I don't. But the documentation does have specific configuration examples for raspberry pi, so you have all information needed listed there in "how to use this" section.

[sineverba]

@pepson see here for 2.2.0 and on left menu for 2.3.0

https://github.com/sineverba/domapi/wiki/MySensors-2.2.0-Security-and-signin

[pepson]

@sineverba
Very very good manuals...
But i dont understand what i must type number in this placeand how get it ? It is MAC number network from RPI ?:

#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setup

And what is diffrent with MySensors 2.3.0 ?
I must do all point from MySensors 2.2.0 and additional point for 2.3.0 ?

After got your ./configure instruction, type
sudo nano /etc/mysensors.conf
And add your KEYs to the specific section on bottom of the file.
To get your first KEYs follow guide for 2.2.0

And in version 2.3.0 i must do this under building gateway ?

And add serial,HMAC,AES in this place in mysensors.conf

Software signing settings

Note: The gateway must have been built with signing

support to use the options below.

To generate a HMAC key run mysgw with: --gen-soft-hmac-key

copy the new key in the line below and uncomment it.

#soft_hmac_key=

To generate a serial key run mysgw with: --gen-soft-serial-key

copy the new key in the line below and uncomment it.

#soft_serial_key=

Encryption settings

Note: The gateway must have been built with encryption

support to use the options below.

To generate a AES key run mysgw with: --gen-aes-key

copy the new key in the line below and uncomment it.

#aes_key=

and then build gateway ?

[sineverba]

@pepson You use RFM69(H/W/HW). So I. My hint is remain with 2.2.0. I got so many issues with 2.3.0 and RFM that I reverted to 2.2.0 in 1 minute.

HMAC is not LAN MAC, is HMAC got from MYsensors gateway. Same for other 2 keyes.

I think that in long explain on my guide you have all info to get your keyes. I follow my same guide everytime I need to reinstall mysensors / domoticz / an entire PI. It is fully tested

[pepson]

@sineverba
Hi
Yes i use radio RFM69HW. I also on 2.3.0 have big problem... and back to 2.2.0. What you have problem on 2.3.0 with radio RFM69 ?

I read all your guide and it is ok. But i dont know what i must put in place:
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setup

Put serial from this:
sudo mysgw --gen-soft-serial-key

We will get:

SOFT_SERIAL | 7850987FA6601F6538

The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_SERIAL 0X78,0X50,0X98,0X7F,0XA6,0X60,0X1F,0X65,0X38

To use this key, run mysgw with:
--set-soft-serial-key=7850987FA6601F6538

And i must put my keys to mysensors.conf when i use version 2.2.0 ? Or only when use 2.3.0 ?

Software signing settings
Note: The gateway must have been built with signing
support to use the options below.
To generate a HMAC key run mysgw with: --gen-soft-hmac-key
copy the new key in the line below and uncomment it.
#soft_hmac_key=

To generate a serial key run mysgw with: --gen-soft-serial-key
copy the new key in the line below and uncomment it.
#soft_serial_key=

Encryption settings
Note: The gateway must have been built with encryption
support to use the options below.
To generate a AES key run mysgw with: --gen-aes-key
copy the new key in the line below and uncomment it.
#aes_key=

or only send command

sudo mysgw --set-soft-serial-key=7850987FA6601F6538 && sudo mysgw --set-aes-key=768859210B4A75FACC78B757ADAFE75B && sudo mysgw --set-soft-hmac-key=0298FF121DD3194BCC33DC8185055B9D981EBE0A90D847A4777A9E65CCE4F524 ?

[sineverba]

@pepson

Too many ack lost and slow communication. And other that I don't remember.

That line on the sketches means that you need add on the node that you want whitelist the serial of gateway.

You got serial gateway on the steps for 2.2.0.

You have it.

You don't need to put anything in no file with 2.2.0. In my guide is NOT mentioned. In my guide, at the bottom, there is the final "set keyes" with only a line OR you can set them everytime you get them.

Please, take your time to read 1, 2, 3 times before type anything. I think it is very clear, and every step is write down for you.

Enjoy

PS Don't offend, I want help you, 'cause I used a bit of times before getting security working. And I used so many time write down a guide. But you need to read and follow carefully

[pepson]

@sineverba I also have the same problem with communication. But tell me you send issue to developer ? I send but nothing done.

Ok in point 4 in your guide in sketch for node i must put serial key from gateway ? Yes ?

And tell me how remove setup serial, HMAC and AES when i dont want to use it ? How remove it from gateway ?
Thanks

[pepson]

Any help ?

[sineverba]

@pepson no need to remove. Simply, in your sketches, don't use signing at all.

[pepson]

@sineverba said in Security & Signing:

no need to remove. Simply, in your sketches, don't use signing at all.

ok but if on gateway it was generate and setup keys and when in skethces i dont use keys will nody connect? and what the purpose of the signature is then ?
I thought that if the gate has a set of keys and will try to connect noda without a key that it will not connect ....

[sineverba]

@pepson you can use a special flag define to "downgrade/reduce" security MY_WEAK_SECURITY

[pepson]

@sineverba

Ok summary
When i have setup on Raspberry Gateway , generate keys.

When i write in node all keys with sketches.... Node connect ok.

But when write to node only sketches without keys.,... node connect to gateway or not connect to gateway ?

[sineverba]

@pepson you need to setup gateway with weak security.

You need generate keyes and set in gateway.

You need to personalize nodes with the sketch and set keyes on Arduino EEPROM.

From now, you have two ways: Your node need security? Set use security bla-bla on top with other define(s).

Don't Need security? Don't define use security.

Simpler than ever.

[Anticimex]

@pepson if you find the security setup to be too complicated, I highly recommend sticking with the simple password flags. The documentation has it all.

[pepson]

@sineverba said in Security & Signing:

setup gateway with weak security.

But when configure my gateway without flag setup gateway with weak security i can only use nodes with setup in sketches keys. yes ?

[pepson]

@anticimex

Can you share me this document when is describe how define only pass ? I want also read this.

[sineverba]

@pepson

Let's summarize. Last time.

1. compile gateway with weak security (make your research, also in my github guide, there is )
2. create the 3 keyes for gateway
3. set the 3 keyes for gateway.
4. clean your EEPROM arduinos with the sketch present in my guide and in examples of library
5. set the keyes in EEPROM arduinos.

Stop. End. Fin. Fine. These steps are MANDATARY. You NEED to do.

You will have in EEPROM the keyes (arduino) and in gateway.

From now, you select:

a) Do I need security? Perfect, in sketch arduino add #define bla bla bla on top with security and other stuff.
b) Do I NOT need security? Perfect, in sketch arduino DON'T ADD #define bla bla related to security.

[sineverba]

@pepson And, last all, you can use the mysensors debug options. Try. Try. Try! This is the best option offered to you to learn. Try!
At max, nothing works

[pepson]

@sineverba
ok all is very good.

But what give me this if i can connect nodes also with defines bla bla bla in skethc and also without define bla bla bla in sketch?
But Do I think right ? In each of these accidents in the eeprom I need to have the keys loaded?

[sineverba]

@pepson only one word. Try. Really, you are lost in 1 cm of water. Try. And if it doesn't work, open your topic, showing exactly your sketches and what have you done.

[pepson]

ok thanks

[pepson]

Ok i build my gateway on RPI on MySensors 2.2.0 with this configuration:

./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003 --my-signing=software --my-signing-request-signatures

Then generate 3 key and setup it on gateway.

Then clear_epprom on Arduino MIni Pro, and then send sketch security with add serial, HMAC, and AES. Then put sketch with add this on top sketch with my SERIAL generated on gateway RPI.

#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X2C,0X61,0X17,0X2E,0XEE,0XDD,0XCC,0XBB,0XAA}}} // got from gateway setup

After that i run HA and he not found my nodes...
WHat is wrondg ?

[Anticimex]

@pepson well for starters, don't start out with whitelisting unless you know exactly what you are doing. First you have to verify that your network is stable enough to handle the security protocol. The simplest option is to only enable encryption, or use the simple password flag options. Once you have established that your gw and nodes are capable of communicating securely you can move on to personalization and whitelisting.

[pepson]

@anticimex
What you mean white list?

Before adding all security my nodes and gateway works perfect.

[Anticimex]

@pepson you define whitelisting so I presume you use it. But I don't see your gw flags specifying it so of course it does not work. So get rid of that flag from your config unless you know what it mean so that you set it up properly.

[pepson]

@anticimex

What flag i must remove ?
This :
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X2C,0X61,0X17,0X2E,0XEE,0XDD,0XCC,0XBB,0XAA}}} // got from gateway setup

But on GW i setup this:
sudo mysgw --set-soft-serial-key=2C61172EEEDDCCBBAA && sudo mysgw --set-aes-key=9D2AD43CF909875C4C77111111111111 && sudo mysgw --set-soft-hmac-key=A2A64C48EA6765C5DAEFA12A1E41E2F038515A9CAED9FED73D11111111111111

[Anticimex]

@pepson please just read the documentation. And more importantly, follow it.
Isn't it obvious that it is the flag that mention whitelisting that is supposed to be removed unless you intend to use whitelisting, in which case you ought to know how to set it up properly at both ends?

[pepson]

@anticimex

Sorry i dont undestand

[Anticimex]

@pepson https://www.mysensors.org/apidocs/group__MySigninggrpPub.html

Note that it is the documentation for the latest release (simple password flags work differently compared to previous releases, see release notes for the latest release).

[pepson]

HI
i don as describe...

1. install gateway on raspberry with this configuration:
   ./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18 --my-signing=software --my-signing-request-signatures --my-signing-weak_security --my-signing-debug

and then generate serial, aes and hmac

pi@raspberrypi:~/MySensors $ sudo mysgw --gen-soft-serial-key
SOFT_SERIAL | 8FC828503E6EB14C5D

The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_SERIAL 0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D

To use this key, run mysgw with:
--set-soft-serial-key=8FC828503E6EB14C5D
pi@raspberrypi:~/MySensors $ sudo mysgw --gen-soft-hmac-key
SOFT_HMAC_KEY | 0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514

The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_SOFT_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14

To use this key, run mysgw with:
--set-soft-hmac-key=0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514
pi@raspberrypi:~/MySensors $ sudo mysgw --gen-aes-key
AES_KEY | 8FDB1EE8D0351CFF874D337731BF37AE

The next line is intended to be used in SecurityPersonalizer.ino:
#define MY_AES_KEY 0X8F,0XDB,0X1E,0XE8,0XD0,0X35,0X1C,0XFF,0X87,0X4D,0X33,0X77,0X31,0XBF,0X37,0XAE

To use this key, run mysgw with:
--set-aes-key=8FDB1EE8D0351CFF874D337731BF37AE
pi@raspberrypi:~/MySensors $

and setup it on my gateway

sudo mysgw --set-soft-serial-key=8FC828503E6EB14C5D && sudo mysgw --set-aes-key=8FDB1EE8D0351CFF874D337731BF37AE && sudo mysgw --set-soft-hmac-key=0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514

all is ok to this moment

Then

1. clear eeprom in node Arduino pro mini with this sketch:
   https://github.com/sineverba/domoraspi/tree/master/utils/sketches
2. write sketch security with setup my serial, aes and hmac

https://github.com/sineverba/domoraspi/tree/master/utils/sketches

at the top setup...
/************************************ User defined key data ***************************************/

/** @brief The user-defined HMAC key to use unless @ref GENERATE_HMAC_KEY is set */
//#define MY_HMAC_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
#define MY_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14

/** @brief The user-defined AES key to store in EEPROM unless @ref GENERATE_AES_KEY is set */
//#define MY_AES_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
#define MY_AES_KEY 0X8F,0XDB,0X1E,0XE8,0XD0,0X35,0X1C,0XFF,0X87,0X4D,0X33,0X77,0X31,0XBF,0X37,0XAE

/** @brief The user-defined soft serial to use for soft signing unless @ref GENERATE_SOFT_SERIAL is set */
#define MY_SOFT_SERIAL 0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D

/***************************** Flags for guided personalization flow ******************************/

1. then write my sketch relay with added at the top this info:

#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D}}} // got from gateway setup

and now on my Home assistant in file
/home/homeassistant/.homeassistant/mysensors.json

found my node but wthout full information like name....
{
"0": {
"battery_level": 0,
"sketch_name": null,
"sketch_version": null,
"children": {},
"type": 18,
"protocol_version": "2.2.0",
"sensor_id": 0
},
"33": {
"battery_level": 0,
"sketch_name": null,
"sketch_version": "1.0",
"children": {
"1": {
"type": 3,
"id": 1,
"values": {
"2": "1"
},
"description": ""
}
},
"type": 17,
"protocol_version": "2.2.0",
"sensor_id": 33
}
}

and in Home Assistant is not show in devices this node. Not found it.
What i done wrong ?

[Anticimex]

@pepson said in Security & Signing:

MY_SIGNING_NODE_WHITELISTING

How many times do I need to tell you to get rid of the whitelisting flag?

[pepson]

@anticimex
Ok read... but...
when i use MY_SIGNING_NODE_WHITELISTING i must on node in sketch add serial number my gateway and also serial number for node. But from where i can get serial number for my arduino pro mini ? I dont know...becasue i don use ATSHA204 but i use only soft signing....

[sineverba]

@pepson This is the serial OF GATEWAY. Not your Arduino. You need to put serial of GATEWAY.

Please, first of all, DONT' USE WHITELISTING. And pay attention: if you enabled it, remove it and:

1 - clear eeprom
2 - flash eeprom with keyes
3 - reload sketch (without whitelisting)

[sineverba]

@pepson Don't need all copy and paste, enough link :).

Btw, before move to Home Assistant, where is the output of debug of MySensors?

sudo mysgw -d

Of course, you need before stop service.

Resetting the node, what you get in debug?

When ALL ok, move to HomeAssistant.

And remember, after check that debug is ok...

sudo make install && sudo systemctl enable mysgw.service && sudo systemctl start mysgw.service

[pepson]

In my first time I use only serial number gateway in flag whitelistening and also not working.

[sineverba]

@pepson Last time. Please.
REMOVE
WHITELISTING
FROM
YOUR
SKETCH

Clear EEPROM and paste here output of debug. No other.

[pepson]

@sineverba
OK wait for info

[pepson]

@pepson

Ok i removed Whitelisting and switch is show in Hoem Assistant and works.

pi@raspberrypi:~/MySensors $ sudo ./bin/mysgw -d
mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0
mysgw: MCO:BGN:INIT GW,CP=RPNGLS--,VER=2.2.0
mysgw: SGN:PER:OK
mysgw: SGN:INI:BND OK
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: TSM:INIT:TSP OK
mysgw: TSM:INIT:GW MODE
mysgw: TSM:READY:ID=0,PAR=0,DIS=0
mysgw: MCO:REG:NOT NEEDED
mysgw: Listening for connections on 0.0.0.0:5003
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
mysgw: !SGN:VER:NSG
mysgw: !TSF:MSG:SIGN VERIFY FAIL
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=1,pt=0,l=0,sg=1:
mysgw: SGN:BND:NONCE=44E4127024F4EB1003DCBF3701D8469E4664CC454E2A20A257AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=E1EE2D4046FEF0AEC323AA737A8367A2F290CCEFB7A4663448AD0B155FFD5A74
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
mysgw: SGN:BND:NONCE=4AD7D9430FA96BBD0B18D4F57480F009BE31C6F3821F182766AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=3AADB41A42B91C0B2137BE2C2C76F57E3ADB7082F3669DECCA85B993C955D36E
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: SGN:BND:NONCE=B272E537F5C6DAF21A0C5042078EFCFD3A02B5C61F698792AAAAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=5AF82BD16724069A436E0735229D32F532108A45407EF0DE7CABDADA1F7E39A0
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
mysgw: !SGN:VER:NSG
mysgw: !TSF:MSG:SIGN VERIFY FAIL
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
mysgw: SGN:BND:NONCE=61F78D66E675349B8A63B1370E81D2D1AB44BC1D0BB1F988D6AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=04EEE2B60E0C71CC092E13C68C07F3088D66F264A826C23426053C17C2353DED
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: SGN:BND:NONCE=627FAEEEFFFD6E55F371C07A54F785FDA3EE52EBD4092E0CE9AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=65503227CDB04C1A2DCB03D0E5BAFD35A4EBA956E8EBA917B2DF40FB09520092
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: !SGN:BND:VER ONGOING
mysgw: !SGN:VER:FAIL
mysgw: !TSF:MSG:SIGN VERIFY FAIL
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=1,pt=0,l=0,sg=1:
mysgw: SGN:BND:NONCE=32CE07784E14ED2B6D455C2C5C4D83E025185970838C0B743AAAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=F04885315D93DB7FC95F3B190D68009055495ECEE698E0ADF6F50292157A8927
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
mysgw: SGN:BND:NONCE=3DAAB19C10BB3CB8A08CDAACED4BFB385F1EB22AA9F926F940AAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=392AB4EAFDE59AC0CC9BE6EE667FC33A69A33E86AD5CB3EC49C6C114722941F5
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
mysgw: SGN:SKP:MSG CMD=3,TYPE=16
mysgw: SGN:SKP:MSG CMD=3,TYPE=17
mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
mysgw: SGN:NCE:XMT,TO=0
mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
mysgw: SGN:BND:NONCE=CF101801DA5324E2F66C3B9350E8FC2BCCBD337E3F588EBE2FAAAAAAAAAAAAAA
mysgw: SGN:BND:HMAC=53795E79C8FE9D599D1A88363F7E2BA607ADBB265E4E99356886B65C3D0A06D0
mysgw: SGN:VER:OK
mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
mysgw: !SGN:VER:NSG
mysgw: !TSF:MSG:SIGN VERIFY FAIL

[Anticimex]

@pepson your gw is configured to require signing from all nodes.
Your node 33 is set up to use signing. Your node 3 is not. Hence messages from node 3 will be rejected by the GW.
Either set up all nodes to use signing or set up weak security on the GW to only require signing from nodes that require it in turn.
This is documented behaviour. Please read the documentation. That is what it is for.

[pepson]

But still I don't know how use white listening...?

[Anticimex]

@pepson I suggest you avoid it. It require good tracking of all serials in your network and is part of the more advanced security mechanisms. And I suspect you will get issues when you add new nodes to your network as you cannot get it to work with just two nodes (you still have not enabled it on your gw). So just avoid whitelisting all together.

[pepson]

@anticimex
OK but how I can get serial from my Node on Arduino Pro Mini?

And when I want use chip AtSHA204A what I must change on my GW and on Node?
Can I build GW on Rpi with this chip AtSHA204A?

[Anticimex]

@pepson Please. Read. The. Documentation.
And no, atsha204a is not supported on rPi. Nor does it need to be.

[pepson]

@anticimex
But still I don't know how read serial number from Node on Arduino Mini Pro when I want use White Listening...

[Anticimex]

@pepson have you read the documentation? Do you understand the concept of personalization? Where have you found information on from where the serial number is obtained?
I will only say this once more: don't use whitelisting unless you know these things. Serial is only used for whitelisting. Don't use something you do not understand.
All your questions so far can be answered by citing the documentation so please read it!

[joaoabs]

I have my network with NRF24+'s with HW signing. Now, due to performance limitations of the NRF's I'll move to RFM69's which supports encryption.
How can I set encryption in Mysensors? Is it already available? Can I have both signing and Encryption?

[Anticimex]

@joaoabs yes, it's all in the documentation
Let me know if you can't find it. Links are in the readme.md in git and in github.

[Damian]

Hi,
I've been a while on MySensors forum, most time as a reader. Read the docs about signing and have a couple of questions - possibly stupid as I might not understand well the docs.

1. I'd like to ask if the flags --my-signing-weak_security and --my-signing-request-signatures (yes I have RPi gw) are complementary or separate: if I define both, do I get a "weak security" feature or the "request security" is on top of that and only signed messages would be accepted? Or maybe I need to define one of them only depending on security level I want to achieve?
2. Whitelisting - many things were said here, I am not planning to use it for now nor anytime for gateway on nodes as I do not find it necessary as gw is not supposed to be compromised, but did a quick test following the @sineverba tutorial and it failed indeed as pepson said. The serial which I provided in sketch in #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} was the one generated by mysgq --gen-soft-serial-key (and then applied by --set-soft-serial-key ofc) - is that correct? I also tried to replace GATEWAY_ADDRESS with 0 and no success. Maybe there are some other steps that I should take (@Anticimex said something like "But I don't see your gw flags specifying it" which I dont understand in this context)
3. Is the encryption possible to be enabled only by compiling the gw with --my-rf24-encryption-enabled (for my nrf24) and personalizing gw and node with the same AES key obtained in this docs and by defining the proper flags in sketches on all nodes or is this procedure is more complicated? If this is not the subject for the scope of this thread please tell me I will search more.

Thank you for understanding my possibly dumb questions I try my best but I am a beginner iot, but work in IT so not a total newbe in programming or technologies.

[Anticimex]

@damian There are no stupid questions on complex matters. Security is a complex matter (unfortunately).

1. The weak security flag allows a node to inform a GW that it no longer require signing. Thus, an attacker might "take over" a node and replace it with a non-secure one possibly without you noticing.
   The request signature flag lets a node (or GW) informe a GW (or node) that it require signatures. That allows the other side to understand that it has to sign messages sent to the destination. It is therefore not to be confused with "weak security". It is more a "enable security".

2. Writing #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} in a node, tells the node to requrie the GW to salt the signatures with it's serial (that should match the serial you entered in the node).
   If the messages fail to verify, it suggests that the GW either has not realized it is expected to salt the signatures, or it uses the wrong serial to do it. Unfortunately I do not have a rPi setup to check this, so any help in troubleshooting that would be appreciated.

3. Yes, just make sure to also enable encryption on the node. Also, do notice that ALL nodes on the same network needs to use encryption with the same key.

I hope this clarifies the things a bit

[Damian]

@anticimex thanks for the answer.

1. I understand the idea. However, I think I might asked not clear enough. I would like to know how the mysgw daemon would work after the compilation depending on the flags I provide.
   I understand that when I compile my gw with only --my-signing-request-signatures it will require all nodes in the network to sign messages. But if I want only some of them to sign messages and some not, do I have to compile the gw with both flags: --my-signing-request-signatures AND --my-signing-weak_security or only: --my-signing-weak_security ?
2. I think it might be an RPi issue, because the idea and setup seems to be correct. I'll try one day to test it in node-to-node communication or some test serial gw on Arduino. This is not so important to me as the signing itself works fine, just was curious.
3. clear, hope it work. In the meantime I found: https://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24 which looks worth testing as well. TL;DR carefully yet.

[Anticimex]

@damian

1. You need to compile with --my-signing-request-signatures AND --my-signing-weak_security. See https://www.mysensors.org/apidocs/group__SigningSettingGrpPub.html#gaf44407e0f498eca7069adf5e59ffe052
2. RF24 encryption is implemented in SW and currently available (with static IV). See https://www.mysensors.org/apidocs/group__EncryptionSettingGrpPub.html

[Damian]

@anticimex Thank you so much for clarification I owe you a beer

So another question for future considerations - is it possible to read eeprom to get the keys? I suppose the answer is yes as the whitelisting feature is introduced, but is it a hard task or keys could be fetched by a simple script reading eeprom?

[Anticimex]

@damian Reading EEPROM is quite trivial for a determined attacker, hence I discourage SW based security as it does not have the means of storing secrets securely on devices as the atmega328p.
HW based signing is available using the atsha204a in which case signing keys are protected. Encryption keys are not unfortunately as all encryption is currently SW based (or HW accelerated but still SW dependent).
"Security V3" will resolve this, but I unfortunately have no ETA.

You are welcome!

[Damian]

I've just applied signing to my own written sketch and hit a wall. Basically the signing works fine - I get time from controller and it works fine - any signed time packets from controller are read. However I've got issues with my receive(const MyMessage &message) function. The function gets the state change for the relay from the controller and to determine which relay should be changed it uses message.sensor method. When the signing is turned off it returns 0 or 1 (for 2 relays). However, when the signing is enabled it returns always 255. Any ideas why?

[Anticimex]

@damian the only thing I can think of is that you don't read the part of the message you think you read. Could you please provide some logs where you print the message in its entirety? The signing backend also has flags for verbose debugging (see the flags in the docs).

[Damian]

@anticimex I will send logs, for now do not have access to hardware (I'm out of home). I am curious what could be the reason, as I said, I set all keys and the signing itself seems to work well. When I disable:

//#define MY_SIGNING_SOFT
//#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
//#define MY_SIGNING_REQUEST_SIGNATURES

the sketch works fine. When they are enabled, I can see that the messages are received (I can see the change of the state of relay but I cannot read which relay should be change. Here's a part of my sketch, maybe there is a trivial mistake in it:

#define NUMBER_OF_RELAYS 2
#define R_CHILD_ID 0
#define RELAY_PIN 3

MyMessage msg[NUMBER_OF_RELAYS];
bool relayState[NUMBER_OF_RELAYS] = {false};
bool controllerState [NUMBER_OF_RELAYS] = {false};

void presentation() {

  for (int i=0, r_id=R_CHILD_ID; i<NUMBER_OF_RELAYS; i++, r_id++) {
  present(r_id, S_BINARY);
  msg[i] = MyMessage(r_id, V_STATUS);                                   
  }

}

void receive(const MyMessage &message) {
  if (message.type==V_STATUS) { 
    controllerState[message.sensor] =  message.getBool();                       
    if (controllerState[message.sensor] != relayState[message.sensor]) {                        
      relayState[message.sensor] = controllerState[message.sensor];                             
     }
    Serial.print("Message Sensor id: ");
    Serial.println(message.sensor);
    digitalWrite(RELAY_PIN+message.sensor, relayState[message.sensor] ? RELAY_ON : RELAY_OFF); 
        }
    }

when I dump to console controllerState[message.sensor] value I can see it changes, no matter the fact that it points on the table out of the range as I check it later when read message.sensor value. So it leads me to conclusion that message.getBool(); works OK (now I think I should Serial.println(message.getBool()) to get straight the value and make sure it really works fine... I will test it), however:

Serial.print("Message Sensor id: ");
Serial.println(message.sensor);

gives me always the value of 255 instead of 0 or 1 in this case. Of course I gave here only the most important parts of my code which I think causes problems.

[Anticimex]

@damian It sure looks like message.sensor is cleared/reset for some reason. The verbose logs should show more details and hopefully reveal when in the call path, this happens.

[Damian]

@anticimex
Should I look rather in gw logs or node's? Or both?

[Anticimex]

@damian I'd start with the nodes. I suspect it is at that end something is overwritten after the message is received and verified.

[Damian]

@anticimex here are some logs from the node:

1. Actions without signing - relay 0 on -> off -> relay 1 on -> off

message.getBool: 1
message.sensor: 0

message.getBool: 0
message.sensor: 0

message.getBool: 1
message.sensor: 1

message.getBool: 0
message.sensor: 1```

1. Actions with signing the same sequence as in the above:

message.getBool: 1
message.sensor: 255

message.getBool: 0
message.sensor: 255

message.getBool: 1
message.sensor: 255

message.getBool: 0
message.sensor: 255

1. Same as the 2nd but with debug logs from the node start:

39 SGN:PER:OK
66 SGN:INI:BND OK
73 SGN:SGN:NREQ=255
117 SGN:SKP:MSG CMD=3,TYPE=8
2111 SGN:SKP:MSG CMD=3,TYPE=24
2124 SGN:SKP:MSG CMD=3,TYPE=25
2127 SGN:PRE:SGN REQ
2129 SGN:PRE:WHI NREQ
2131 SGN:SKP:MSG CMD=3,TYPE=15
2136 SGN:PRE:XMT,TO=0
2138 SGN:PRE:WAIT GW
2147 SGN:SKP:MSG CMD=3,TYPE=15
2150 SGN:PRE:SGN REQ,FROM=0
2153 SGN:SKP:MSG CMD=3,TYPE=16
2157 SGN:SGN:NCE REQ,TO=0
2160 SGN:SKP:MSG CMD=3,TYPE=17
2163 SGN:NCE:FROM=0
2165 SGN:BND:NONCE=492B8B82E7FDCE9EB7C9DA704A61C8A421FCE7A4641E2C407AAAAAAAAAAAAAAA
2252 SGN:BND:HMAC=59CC2807188FF377BB1F83CB2DA7BC10A645A87453318738B3CCCD736468BA8B
2259 SGN:SGN:SGN
2265 SGN:SKP:MSG CMD=3,TYPE=16
2270 SGN:SGN:NCE REQ,TO=0
2277 SGN:SKP:MSG CMD=3,TYPE=17
2280 SGN:NCE:FROM=0
2282 SGN:BND:NONCE=679C140E7BD7A10EDC27B23E57F06821E9349DB6AD7BC3D90BAAAAAAAAAAAAAA
2369 SGN:BND:HMAC=16F18AB2C520A05498608CC2BFBA42889B02A694A2565160084EACCBCD1B9F1C
2376 SGN:SGN:SGN
2394 SGN:SKP:MSG CMD=3,TYPE=16
2411 SGN:SKP:MSG CMD=3,TYPE=17
2416 SGN:NCE:XMT,TO=3
2438 SGN:BND:NONCE=5E4BB1EA3185F4401A4EF3D9874CC26C5D811D0D3F258BFDF4AAAAAAAAAAAAAA
2525 SGN:BND:HMAC=671770009DDF1D4F1CA94CF9F13071E003346CB8C56222692DA13ECD73DD2F68
2532 SGN:VER:OK
2534 SGN:SKP:MSG CMD=3,TYPE=16
2539 SGN:SGN:NCE REQ,TO=0
2543 SGN:SKP:MSG CMD=3,TYPE=17
2546 SGN:NCE:FROM=0
2548 SGN:BND:NONCE=A022D15873F1D5CAF7DE6F1804CCCE96DFD950A3B62D22BE08AAAAAAAAAAAAAA
2635 SGN:BND:HMAC=ECFD84CCB0B8FCCBE8E6D4501F3405E6CCE99018A13D5D2859F43E58050B9508
2642 SGN:SGN:SGN
2647 SGN:SKP:MSG CMD=3,TYPE=16
2653 SGN:SGN:NCE REQ,TO=0
2660 SGN:SKP:MSG CMD=3,TYPE=17
2663 SGN:NCE:FROM=0
2665 SGN:BND:NONCE=B1851645BDE44AEA6BC82790365E810A85C5AFD1C5DFBA6EB0AAAAAAAAAAAAAA
2752 SGN:BND:HMAC=D6DC1E4A5BC8BF47DEE26831C97F7B83E6C8C0CEBACA27BB7A79366686D2AE1F
2759 SGN:SGN:SGN
2763 SGN:SKP:MSG CMD=3,TYPE=16
2768 SGN:SGN:NCE REQ,TO=0
2776 SGN:SKP:MSG CMD=3,TYPE=17
2779 SGN:NCE:FROM=0
2781 SGN:BND:NONCE=B719DBCF17B1C626FB26B9460857C4F83ED3F2F09B0D8509B8AAAAAAAAAAAAAA
2868 SGN:BND:HMAC=693077E51746266A70C0D8C28A8A9707E585F27FB7717D18E985AA6EC52A538C
2876 SGN:SGN:SGN
2880 SGN:SKP:MSG CMD=3,TYPE=16
2885 SGN:SGN:NCE REQ,TO=0
2892 SGN:SKP:MSG CMD=3,TYPE=17
2895 SGN:NCE:FROM=0
2897 SGN:BND:NONCE=B6525A06EE88D0705ADF1E96C6E183C2C495C97D9F729BDC63AAAAAAAAAAAAAA
2984 SGN:BND:HMAC=B17C1213603F41C583F92A70DF4D6F5D83ADB41DBC812F022A5ED4FE46A0B7F2
2992 SGN:SGN:SGN
2997 SGN:SKP:MSG CMD=3,TYPE=16
3002 SGN:SGN:NCE REQ,TO=0
3009 SGN:SKP:MSG CMD=3,TYPE=17
3012 SGN:NCE:FROM=0
3014 SGN:BND:NONCE=FB23A24F06C2D2A87E36D048354D5A0A8C56BD15C54444D6D3AAAAAAAAAAAAAA
3101 SGN:BND:HMAC=737991E978781664A5B3FC188BECA847272541F2FE4C8B21E9E769D886C7644A
3108 SGN:SGN:SGN
3112 SGN:SKP:MSG CMD=3,TYPE=16
3119 SGN:SGN:NCE REQ,TO=0
3126 SGN:SKP:MSG CMD=3,TYPE=17
3129 SGN:NCE:FROM=0
3131 SGN:BND:NONCE=14517440F7E1361682BB145FE43624B7EEB5434C86F13B49CBAAAAAAAAAAAAAA
3218 SGN:BND:HMAC=D869103E10D562870FBA6E5AC62085B9F905921B8EDAE6156E4D161ADBAAFB10
3225 SGN:SGN:SGN
3229 SGN:SKP:MSG CMD=3,TYPE=26
3243 SGN:SKP:MSG CMD=3,TYPE=16
3260 SGN:SKP:MSG CMD=3,TYPE=17
3265 SGN:NCE:XMT,TO=3
3287 SGN:BND:NONCE=7025F04837E08FAA04A3A58239C1AAED9278F5C6B8DF197C68AAAAAAAAAAAAAA
3374 SGN:BND:HMAC=7A5F0817D6F53120AD81F2C2BDE5DFF223677C0C21AED391B73B35827665C33C
3382 SGN:VER:OK
Setup b_pin:14
Setup b_pin:15
3389 SGN:SKP:MSG CMD=3,TYPE=16
3394 SGN:SGN:NCE REQ,TO=0
3402 SGN:SKP:MSG CMD=3,TYPE=17
3405 SGN:NCE:FROM=0
3407 SGN:BND:NONCE=5E16EC77B417638DBB3F43BDCA2735B6A1531082F59BF3800DAAAAAAAAAAAAAA
3494 SGN:BND:HMAC=71012A7427B1601C6D44EC925FFD8D5514A9165AC2D1CD0808EDDD1ABA9DED62
3502 SGN:SGN:SGN
3530 SGN:SKP:MSG CMD=3,TYPE=16
3548 SGN:SKP:MSG CMD=3,TYPE=17
3553 SGN:NCE:XMT,TO=3
3574 SGN:BND:NONCE=2718D9CD7DF4ABC41A0CCB0DCB34C4E1A66B96713667E2EF55AAAAAAAAAAAAAA
3662 SGN:BND:HMAC=EFDE9C7F1E12B34EDADDA2023F81516FD8874EBAF8B4F1D37326FA8DED62D5F9
3670 SGN:VER:OK
4171 SGN:SKP:MSG CMD=3,TYPE=16
4176 SGN:SGN:NCE REQ,TO=0
4179 SGN:SKP:MSG CMD=3,TYPE=17
4183 SGN:NCE:FROM=0
4185 SGN:BND:NONCE=8B545E858FA04E5A4727F1BF48B26EE26053A2CE8F5C7891A9AAAAAAAAAAAAAA
4272 SGN:BND:HMAC=5E5C4D1D6A3DFF01611E255672BB5400AD770CD2283A12513D3750D4BB6D2A62
4279 SGN:SGN:SGN
4312 SGN:SKP:MSG CMD=3,TYPE=16
4329 SGN:SKP:MSG CMD=3,TYPE=17
4334 SGN:NCE:XMT,TO=3
4356 SGN:BND:NONCE=6308AD00528416DA333EA85DDE684956B56223CDE6D11A5727AAAAAAAAAAAAAA
4443 SGN:BND:HMAC=0548D4EF289A5786E5406BCB77C7C890AD1AABE7A23481DD0C8B3F79165C74DF
4451 SGN:VER:OK
4452 SGN:SKP:MSG CMD=3,TYPE=16
4457 SGN:SGN:NCE REQ,TO=0
4461 SGN:SKP:MSG CMD=3,TYPE=17
4464 SGN:NCE:FROM=0
4466 SGN:BND:NONCE=3FB114975E4199204F9B011C209A9CEF8BBFFB4D4D60595449AAAAAAAAAAAAAA
4553 SGN:BND:HMAC=409A234B96D417FA1681C449A0C597B1FF907D25DE8758D534C0E77BEB3281E7
4560 SGN:SGN:SGN
4564 SGN:SKP:MSG CMD=3,TYPE=16
4571 SGN:SGN:NCE REQ,TO=0
4590 SGN:SKP:MSG CMD=3,TYPE=17
4593 SGN:NCE:FROM=0
4595 SGN:BND:NONCE=29AC0DDD57C989A0A03D0069DCFD1310199B6706DD8B1AE5F2AAAAAAAAAAAAAA
4682 SGN:BND:HMAC=723C8DFFA1C465D6694A5629D99EC4A09594830BABBA1A9CF6AE0156113BAEA3
4689 SGN:SGN:SGN
4717 SGN:SKP:MSG CMD=3,TYPE=16
4734 SGN:SKP:MSG CMD=3,TYPE=17
4740 SGN:NCE:XMT,TO=3
4761 SGN:BND:NONCE=5A53BA4D71C44DC0FFBE11D352EABD720804CDD9B286CE43BDAAAAAAAAAAAAAA
4848 SGN:BND:HMAC=758DAAA39E40F746690F6E02C6DE89310E936F57C493D5AC56097714A57D91FD
4855 SGN:VER:OK
4857 SGN:SKP:MSG CMD=3,TYPE=16
4862 SGN:SGN:NCE REQ,TO=0
4867 SGN:SKP:MSG CMD=3,TYPE=17
4870 SGN:NCE:FROM=0
4872 SGN:BND:NONCE=4D8B6539448F68BAB431858A0F77CB3C3FBF15E91AFB86D324AAAAAAAAAAAAAA
4959 SGN:BND:HMAC=9D408CB8DA13CFA94279EE0702E103781834A513C3F34AD717EFB5D14DB61F41
4966 SGN:SGN:SGN
5000 SGN:SKP:MSG CMD=3,TYPE=16
5005 SGN:SGN:NCE REQ,TO=0
5016 SGN:SKP:MSG CMD=3,TYPE=17
5019 SGN:NCE:FROM=0
5021 SGN:BND:NONCE=16862976C5196352B14CAE8F8A3B2E3CBFB4CE386634795AA3AAAAAAAAAAAAAA
5108 SGN:BND:HMAC=0378AC5CB5E8ABFAF33484182C562E07FF03E2912124B91A4B9C5F6F7F52EE5E
5115 SGN:SGN:SGN
5143 SGN:SKP:MSG CMD=3,TYPE=16
5160 SGN:SKP:MSG CMD=3,TYPE=17
5166 SGN:NCE:XMT,TO=3
5187 SGN:BND:NONCE=37EA5E4F0CD7D3D96781A987240DA4765244C8AFBFECC7E010AAAAAAAAAAAAAA
5274 SGN:BND:HMAC=7FCC823173527CABF27C64426A0D1AF07537FF15ABCB5028200F3DAA2BD07B2B
5281 SGN:VER:OK
5283 SGN:SKP:MSG CMD=3,TYPE=16
5288 SGN:SGN:NCE REQ,TO=0
5293 SGN:SKP:MSG CMD=3,TYPE=17
5296 SGN:NCE:FROM=0
5297 SGN:BND:NONCE=373E37CB72669C31D416237755EA68B89157428B655B6CC973AAAAAAAAAAAAAA
5385 SGN:BND:HMAC=9DA54DE18AF1CA6617FC43B0DDD01A2145326273DD74C22DDB6CCE1CD4E3F7AD
5392 SGN:SGN:SGN
5396 SGN:SKP:MSG CMD=3,TYPE=16
5401 SGN:SGN:NCE REQ,TO=0
5410 SGN:SKP:MSG CMD=3,TYPE=17
5413 SGN:NCE:FROM=0
5415 SGN:BND:NONCE=406A1D152B330A40A612A57D399559A8F47115693377E3B267AAAAAAAAAAAAAA
5502 SGN:BND:HMAC=5D1DA2557B3A97E62DF813F9541D7A127F8B438C5EB0196B1E76820B9C0F7D81
5510 SGN:SGN:SGN
10000 SGN:SKP:MSG CMD=3,TYPE=16
10005 SGN:SGN:NCE REQ,TO=0
10008 SGN:SKP:MSG CMD=3,TYPE=17
10011 SGN:NCE:FROM=0
10013 SGN:BND:NONCE=DDB151F944CFE259934F431F81CFC4CF91E60E26BBB2438D1EAAAAAAAAAAAAAA
10100 SGN:BND:HMAC=ADD52CA0428CB8A8903ECEF0A73F5CB38E20FED867B00D307A71F8E79789DCB4
10108 SGN:SGN:SGN
10135 SGN:SKP:MSG CMD=3,TYPE=16
10152 SGN:SKP:MSG CMD=3,TYPE=17
10158 SGN:NCE:XMT,TO=3
10179 SGN:BND:NONCE=146952F3EEDCA1473FF00A7D6D1E70DA2E3C912BFC6254116AAAAAAAAAAAAAAA
10266 SGN:BND:HMAC=20366FF89BB97D4CCBDCC50DF13AC8743B6A295CAC02250602C40EF3795325CA
10273 SGN:VER:OK
10275 SGN:SKP:MSG CMD=3,TYPE=16
10280 SGN:SGN:NCE REQ,TO=0
10285 SGN:SKP:MSG CMD=3,TYPE=17
10288 SGN:NCE:FROM=0
10290 SGN:BND:NONCE=A771EC7FE21219634A273E2DE06AB6AE55682BFCDEBCED2E8AAAAAAAAAAAAAAA
10377 SGN:BND:HMAC=BB4935918379CB79BBFB2A3D8F292E53B44E5FCB142922EE42C0E615DC525E2E
10384 SGN:SGN:SGN
10388 SGN:SKP:MSG CMD=3,TYPE=16
10394 SGN:SGN:NCE REQ,TO=0
10400 SGN:SKP:MSG CMD=3,TYPE=17
10403 SGN:NCE:FROM=0
10405 SGN:BND:NONCE=E99F224609C718E42AD2AC14EBFADF26950842F4CB063B2169AAAAAAAAAAAAAA
10492 SGN:BND:HMAC=866B4C8A5C1F8165A87BF84742EC952E05F743FC938CEF7B6D1B73A0885779F6
10501 SGN:SGN:SGN
15000 SGN:SKP:MSG CMD=3,TYPE=16
15005 SGN:SGN:NCE REQ,TO=0
15009 SGN:SKP:MSG CMD=3,TYPE=17
15012 SGN:NCE:FROM=0
15014 SGN:BND:NONCE=4061DC9EE0A1A503E978AA7EBFA14D7BC0A63C47FA77090DB7AAAAAAAAAAAAAA
15101 SGN:BND:HMAC=67DE95797F8E6CCC7B5309A8013705D4188BFC02A8674C7F2805268748108A25
15110 SGN:SGN:SGN
15136 SGN:SKP:MSG CMD=3,TYPE=16
15154 SGN:SKP:MSG CMD=3,TYPE=17
15159 SGN:NCE:XMT,TO=3
15180 SGN:BND:NONCE=8C36F618FA823CC1F3A58F0E66B7C017C17ECC76970A2F0190AAAAAAAAAAAAAA
15267 SGN:BND:HMAC=5AB3164CBB27647596B8D2B1B9F90117C6E08AADA353E2D34FED7F83778EE158
15275 SGN:VER:OK
15277 SGN:SKP:MSG CMD=3,TYPE=16
15282 SGN:SGN:NCE REQ,TO=0
15286 SGN:SKP:MSG CMD=3,TYPE=17
15289 SGN:NCE:FROM=0
15291 SGN:BND:NONCE=BCA87F3ABCCFC83E837335846C56ED229CBFC7006651F7DB38AAAAAAAAAAAAAA
15378 SGN:BND:HMAC=957C1BEC30090937D37D8A24FFC1BA14B555BD02EDD102604307AB13785252A0
15385 SGN:SGN:SGN
15389 SGN:SKP:MSG CMD=3,TYPE=16
15395 SGN:SGN:NCE REQ,TO=0
15411 SGN:SKP:MSG CMD=3,TYPE=17
15414 SGN:NCE:FROM=0
15416 SGN:BND:NONCE=56298BFDE86C4703C51543AE0871D81399B0E9145541409D9CAAAAAAAAAAAAAA
15503 SGN:BND:HMAC=7A6B3750629013E0BC83C10EC80AC1225FFA9A040FFBD3928241177AFAFA48DA
15511 SGN:SGN:SGN
20000 SGN:SKP:MSG CMD=3,TYPE=16
20005 SGN:SGN:NCE REQ,TO=0
20012 SGN:SKP:MSG CMD=3,TYPE=17
20015 SGN:NCE:FROM=0
20017 SGN:BND:NONCE=FF0556E0DFF7A13EF551B1B3E54AB9B13C63435CB48133C220AAAAAAAAAAAAAA
20104 SGN:BND:HMAC=5A9C54621EFF46E4C8A70EBA5F3B65FCE30B7796414FF42C4A3CC9FD7CA5DB3F
20112 SGN:SGN:SGN
20139 SGN:SKP:MSG CMD=3,TYPE=16
20156 SGN:SKP:MSG CMD=3,TYPE=17
20161 SGN:NCE:XMT,TO=3
20183 SGN:BND:NONCE=5F72D46B75A3E1BBEB0F81E932AA1A0E99A3D2E67059DB7356AAAAAAAAAAAAAA
20270 SGN:BND:HMAC=CDDB74748AB4E9D08125B8C52EE7D68BF1124ECC606CC130DBE3A678214393EE
20277 SGN:VER:OK
20279 SGN:SKP:MSG CMD=3,TYPE=16
20284 SGN:SGN:NCE REQ,TO=0
20288 SGN:SKP:MSG CMD=3,TYPE=17
20291 SGN:NCE:FROM=0
20293 SGN:BND:NONCE=CD06A773772E6B0B92A49BE56849DA60D7B454072899AAC3A6AAAAAAAAAAAAAA
20380 SGN:BND:HMAC=FF28B0DF2A3FB90C5B55C0CE2CCF33B8FD77D8BAA24A95BD4956A93449C8AE0F
20387 SGN:SGN:SGN
20392 SGN:SKP:MSG CMD=3,TYPE=16
20398 SGN:SGN:NCE REQ,TO=0
20404 SGN:SKP:MSG CMD=3,TYPE=17
20407 SGN:NCE:FROM=0
20409 SGN:BND:NONCE=6A915CB133C69C103E3DE553695780998995AD0BA05EA9DB5DAAAAAAAAAAAAAA
20497 SGN:BND:HMAC=BEB1AA435B6212CFFD7A67CE4B0A87AD94A132F9500DFFBAC101DAF6E4AF066D
20504 SGN:SGN:SGN
24542 SGN:SKP:MSG CMD=3,TYPE=16
24559 SGN:SKP:MSG CMD=3,TYPE=17
24564 SGN:NCE:XMT,TO=3
24586 SGN:BND:NONCE=16E64CA5D7019688D81965E587288B967D214AD5DE3567E064AAAAAAAAAAAAAA
24673 SGN:BND:HMAC=DB24231C4D79AC2CBDD8C1D9AD87103EC6B73ABD94F6E038BDE40406D929AF18
24680 SGN:VER:OK

message.getBool: 1
24782 SGN:SKP:MSG CMD=3,TYPE=16
24787 SGN:SGN:NCE REQ,TO=0
24794 SGN:SKP:MSG CMD=3,TYPE=17
24797 SGN:NCE:FROM=0
24799 SGN:BND:NONCE=260E9FC73FF1B54D7559524400F589FFC658DE8AEC707D09CCAAAAAAAAAAAAAA
24886 SGN:BND:HMAC=FE572B069ECD3303C73700F543A87FCB8CB106515A76D35379711DBBAADAA437
24894 SGN:SGN:SGN
message.sensor: 255
25000 SGN:SKP:MSG CMD=3,TYPE=16
25006 SGN:SGN:NCE REQ,TO=0
25015 SGN:SKP:MSG CMD=3,TYPE=17
25018 SGN:NCE:FROM=0
25020 SGN:BND:NONCE=285E2D30B1ECC8BF0625F022708E3FFC30D4831003BD358CDEAAAAAAAAAAAAAA
25108 SGN:BND:HMAC=D324AACB08FF60F71BFEE5747F7313FEF1C82CF2FE3455C350CB131F15C04EDB
25115 SGN:SGN:SGN
25148 SGN:SKP:MSG CMD=3,TYPE=16
25165 SGN:SKP:MSG CMD=3,TYPE=17
25170 SGN:NCE:XMT,TO=3
25192 SGN:BND:NONCE=931A1DE011E34E7D177D87295313CF9490FF5D42DF59B2A1CAAAAAAAAAAAAAAA
25280 SGN:BND:HMAC=CB7C16051F2CCA51A054FAE7327637DE3921A4C67D865F1859E21E763FB91698
25287 SGN:VER:OK
25289 SGN:SKP:MSG CMD=3,TYPE=16
25294 SGN:SGN:NCE REQ,TO=0
25297 SGN:SKP:MSG CMD=3,TYPE=17
25300 SGN:NCE:FROM=0
25303 SGN:BND:NONCE=08A188872AB23EA761709E2DB033898424A307D8019B42D048AAAAAAAAAAAAAA
25391 SGN:BND:HMAC=190D48C11DD42052CCBE6368EF48CB757B66E6E228247ECCCEA73680016C079F
25398 SGN:SGN:SGN
25402 SGN:SKP:MSG CMD=3,TYPE=16
25407 SGN:SGN:NCE REQ,TO=0
25427 SGN:SKP:MSG CMD=3,TYPE=17
25431 SGN:NCE:FROM=0
25433 SGN:BND:NONCE=40C6955CD073344B1624FEE815B91F31BE7AD215918727C1B5AAAAAAAAAAAAAA
25520 SGN:BND:HMAC=235D7ECC1516626F8BFF5F849FC6E3B9391549DC2BAD21694E55F734D3E3F676
25527 SGN:SGN:SGN
26334 SGN:SKP:MSG CMD=3,TYPE=16
26351 SGN:SKP:MSG CMD=3,TYPE=17
26357 SGN:NCE:XMT,TO=3
26379 SGN:BND:NONCE=4B62932D0B5AC2BF336C8D16E184503798CD3B5569D8872CC4AAAAAAAAAAAAAA
26466 SGN:BND:HMAC=30FC8A4DDFD59DAEFB11B1429A66A4AFE12E90BF9CD2E3B2673621536A1EAB84
26473 SGN:VER:OK

message.getBool: 0
26575 SGN:SKP:MSG CMD=3,TYPE=16
26580 SGN:SGN:NCE REQ,TO=0
26587 SGN:SKP:MSG CMD=3,TYPE=17
26590 SGN:NCE:FROM=0
26592 SGN:BND:NONCE=4CD7D5705365FF6D5D54EBBB52D5D3284AC93DD34FF4868AADAAAAAAAAAAAAAA
26679 SGN:BND:HMAC=88CDBE83E92EA22CE06347744EE117F2D7E5DA3BB9A391073A4709B0FD5F60B4
26686 SGN:SGN:SGN
message.sensor: 255
28345 SGN:SKP:MSG CMD=3,TYPE=16
28362 SGN:SKP:MSG CMD=3,TYPE=17
28368 SGN:NCE:XMT,TO=3
28381 SGN:BND:NONCE=3410F5DD4084EA0068B3F0C8F3A4D5DA7AC120762E5B606115AAAAAAAAAAAAAA
28468 SGN:BND:HMAC=8E073350CC53B595DA09FBF8A78450DFBDC3221014D3B4ECEB7ACD327BC4D61A
28475 SGN:VER:OK

message.getBool: 1
28577 SGN:SKP:MSG CMD=3,TYPE=16
28582 SGN:SGN:NCE REQ,TO=0
28589 SGN:SKP:MSG CMD=3,TYPE=17
28592 SGN:NCE:FROM=0
28594 SGN:BND:NONCE=4F49C817A6B4A064689E304275F1DFB4F294C84E49DCF9BD34AAAAAAAAAAAAAA
28682 SGN:BND:HMAC=0D40969334248E05273CC27EC628090DA6BA701D05D3CFF0C2EF41EA494C4DF0
28689 SGN:SGN:SGN
message.sensor: 255
29425 SGN:SKP:MSG CMD=3,TYPE=16
29443 SGN:SKP:MSG CMD=3,TYPE=17
29448 SGN:NCE:XMT,TO=3
29469 SGN:BND:NONCE=1A791FA57B8D29F02B6E90717970377F8BBC3BC91DF40AC63AAAAAAAAAAAAAAA
29557 SGN:BND:HMAC=8B41F3C94CB62376D5529C49A1B2E0C05E414149B087673570548A56949B8640
29564 SGN:VER:OK

message.getBool: 0
29666 SGN:SKP:MSG CMD=3,TYPE=16
29671 SGN:SGN:NCE REQ,TO=0
29678 SGN:SKP:MSG CMD=3,TYPE=17
29681 SGN:NCE:FROM=0
29683 SGN:BND:NONCE=3A2EC10C8B0FC4C069443A94DD64FAF550E62F14D4288B2CFCAAAAAAAAAAAAAA
29770 SGN:BND:HMAC=A942BFA7D6AC7108F0AFADA0F7C36D89582F2421E2012962526DECADCB8B7A0E
29777 SGN:SGN:SGN
message.sensor: 255
30000 SGN:SKP:MSG CMD=3,TYPE=16
30005 SGN:SGN:NCE REQ,TO=0
30009 SGN:SKP:MSG CMD=3,TYPE=17
30012 SGN:NCE:FROM=0
30014 SGN:BND:NONCE=64B61596FC3FDC279789EF4E74C2A833DA04EA7A5C0A36584BAAAAAAAAAAAAAA
30101 SGN:BND:HMAC=B7DE1CC94D2B2F889AD51703F0C314277FEFB23DF4DBAB0A169AC348E71D2D27
30108 SGN:SGN:SGN
30136 SGN:SKP:MSG CMD=3,TYPE=16
30153 SGN:SKP:MSG CMD=3,TYPE=17
30159 SGN:NCE:XMT,TO=3
30172 SGN:BND:NONCE=CFDE9FA70EA2C75F6D079E9DE8612B702DA8EFB444CA4697B0AAAAAAAAAAAAAA
30259 SGN:BND:HMAC=614DC54F0BCECADE45A0D32B1021FE4BDE17C70C61460DABDDFDA14039913A60
30267 SGN:VER:OK
30268 SGN:SKP:MSG CMD=3,TYPE=16
30274 SGN:SGN:NCE REQ,TO=0
30277 SGN:SKP:MSG CMD=3,TYPE=17
30280 SGN:NCE:FROM=0
30282 SGN:BND:NONCE=567D002CB82F6B8DEE82F874B97E5E31A51A8549345648C18BAAAAAAAAAAAAAA
30370 SGN:BND:HMAC=0AC28DBFBCF43A810C985DDD44E27752B681E22ADC6E95537B83D47BC2FF821C
30377 SGN:SGN:SGN
30382 SGN:SKP:MSG CMD=3,TYPE=16
30387 SGN:SGN:NCE REQ,TO=0
30394 SGN:SKP:MSG CMD=3,TYPE=17
30397 SGN:NCE:FROM=0
30399 SGN:BND:NONCE=DA8FD6EEA815AB4F503BE1B5EFA2C6081333740E05D38227AAAAAAAAAAAAAAAA
30486 SGN:BND:HMAC=A36CAC6FDD59A5E5D33E6E0FC49E0B5F52EB207EEC4B1A739C1572896534693B
30494 SGN:SGN:SGN
35000 SGN:SKP:MSG CMD=3,TYPE=16
35005 SGN:SGN:NCE REQ,TO=0
35012 SGN:SKP:MSG CMD=3,TYPE=17
35015 SGN:NCE:FROM=0
35017 SGN:BND:NONCE=2EE1A7C461A6D8FE724ED812906DFDF43D81A9D0FC6D43F743AAAAAAAAAAAAAA
35105 SGN:BND:HMAC=95B08DF42306303146921FAFBE413552BD5E759DD8E251BBAACA69F6C77B7677
35112 SGN:SGN:SGN
35139 SGN:SKP:MSG CMD=3,TYPE=16
35156 SGN:SKP:MSG CMD=3,TYPE=17
35163 SGN:NCE:XMT,TO=3
35184 SGN:BND:NONCE=CDB54E3F13BEDA3F9C7AF511D5BD80F71991E59A27CA61A62CAAAAAAAAAAAAAA
35271 SGN:BND:HMAC=5ABF9477680B454863769B902AD384002FAF779084FB1073DE82EFCD68150CBF
35278 SGN:VER:OK
35280 SGN:SKP:MSG CMD=3,TYPE=16
35286 SGN:SGN:NCE REQ,TO=0
35290 SGN:SKP:MSG CMD=3,TYPE=17
35293 SGN:NCE:FROM=0
35295 SGN:BND:NONCE=FA51A5E68AA1F62E7E1C172CDC07A96FDFC4407174BBB9BE9DAAAAAAAAAAAAAA
35382 SGN:BND:HMAC=E88AB002F0D6CFCADFF170B1DF79A703FF2D2EFF0B2E54D44B3BD53CADE1BCE8
35389 SGN:SGN:SGN
35393 SGN:SKP:MSG CMD=3,TYPE=16
35399 SGN:SGN:NCE REQ,TO=0
35405 SGN:SKP:MSG CMD=3,TYPE=17
35408 SGN:NCE:FROM=0
35410 SGN:BND:NONCE=428C535E657135E2F03563064E550BAEA922F19AE16CF4AB87AAAAAAAAAAAAAA
35499 SGN:BND:HMAC=4217532A927DEF4D1B0810B06EE32BC9BE3877C32CC3203B122576626A818E4A
35506 SGN:SGN:SGN
40000 SGN:SKP:MSG CMD=3,TYPE=16
40005 SGN:SGN:NCE REQ,TO=0
40013 SGN:SKP:MSG CMD=3,TYPE=17
40016 SGN:NCE:FROM=0
40018 SGN:BND:NONCE=8D65E89103046004EF7EC22E7D962F9ED3B687D509B2E4BA76AAAAAAAAAAAAAA
40105 SGN:BND:HMAC=3F900CD97363E50EE6B357613F769DAF886E048FFDA7C49151E2DEB21BF9F379
40114 SGN:SGN:SGN
40140 SGN:SKP:MSG CMD=3,TYPE=16
40158 SGN:SKP:MSG CMD=3,TYPE=17
40164 SGN:NCE:XMT,TO=3
40184 SGN:BND:NONCE=874FA416122E07E959949E7DE32BE457046122688B7977E971AAAAAAAAAAAAAA
40272 SGN:BND:HMAC=A7D7D8B4281C5F6F2C7B596928C5B109A177A90D376DBC64CC9824131BE5397D
40280 SGN:VER:OK
40282 SGN:SKP:MSG CMD=3,TYPE=16
40287 SGN:SGN:NCE REQ,TO=0
40290 SGN:SKP:MSG CMD=3,TYPE=17
40293 SGN:NCE:FROM=0
40295 SGN:BND:NONCE=B53BE35890A4BED128978360388906AC10959E2177B896F645AAAAAAAAAAAAAA
40383 SGN:BND:HMAC=37C7C6BF1B3E669444F0805DDB510954598E12AD1CB66D554B6F6F8860E341F1
40390 SGN:SGN:SGN
40394 SGN:SKP:MSG CMD=3,TYPE=16
40400 SGN:SGN:NCE REQ,TO=0
40407 SGN:SKP:MSG CMD=3,TYPE=17
40410 SGN:NCE:FROM=0
40412 SGN:BND:NONCE=F040D59227D7B10262574740CE5575419ABDADBF019EFEE09FAAAAAAAAAAAAAA
40499 SGN:BND:HMAC=6333224230F7EFFE3317FD7E139EDE907E0B2065F2C792AE9E8A59C74396426C
40507 SGN:SGN:SGN
45000 SGN:SKP:MSG CMD=3,TYPE=16
45005 SGN:SGN:NCE REQ,TO=0
45016 SGN:SKP:MSG CMD=3,TYPE=17
45019 SGN:NCE:FROM=0
45021 SGN:BND:NONCE=2AE090A7F9AAD1084FD641A5E8623D935F2FFC75CD16690AA8AAAAAAAAAAAAAA
45109 SGN:BND:HMAC=354D1FF390248F8870A76461996E9C6EC8C9B821470FDA6B6BD517B4D28AD054
45116 SGN:SGN:SGN
45143 SGN:SKP:MSG CMD=3,TYPE=16
45160 SGN:SKP:MSG CMD=3,TYPE=17
45165 SGN:NCE:XMT,TO=3
45187 SGN:BND:NONCE=BABCBF10FC16A16FE4DB3883A672D98DE9962E040F79F31DFDAAAAAAAAAAAAAA
45274 SGN:BND:HMAC=23843CEAE27BBE91CB06909B4C586289CFE6C44F568E337093D9025EF3FE786B
45282 SGN:VER:OK
45283 SGN:SKP:MSG CMD=3,TYPE=16
45289 SGN:SGN:NCE REQ,TO=0
45292 SGN:SKP:MSG CMD=3,TYPE=17
45295 SGN:NCE:FROM=0
45297 SGN:BND:NONCE=0EB891A61B11543A7790E05C52857CA3336974DD3A407E8783AAAAAAAAAAAAAA
45384 SGN:BND:HMAC=55A35830E7B6E445CFD2F37C49D893FAE25F03ED57AB651F765F877F8A1B7631
45392 SGN:SGN:SGN
45396 SGN:SKP:MSG CMD=3,TYPE=16
45402 SGN:SGN:NCE REQ,TO=0
45409 SGN:SKP:MSG CMD=3,TYPE=17
45411 SGN:NCE:FROM=0
45413 SGN:BND:NONCE=ACC5047C74CDE5746F7C174E6F6DAB7BEA032788B322C93660AAAAAAAAAAAAAA
45501 SGN:BND:HMAC=4DEAC30628039766C0B217A89F8A9F4B10C37CEB45529D04C108DE556541C17C
45508 SGN:SGN:SGN

I looked via log parser and it is not looking bad for me. Do you find any suspicious behaviour here? I didn't mention - I use MySensors 2.2. Should I switch to 2.3?

[Anticimex]

@damian interesting. It would appear that verified messages has part of the header overwritten. I will take a closer look tomorrow. If you want, please test with the latest release, although there have not to my knowledge been made any changes relating to this issue.
If you want, please also add some debug printing on the sensor value of the message buffer as it is received and goes though the process of verification and propagates out of the internals in the library. I will look in the code to see if I can find an explanation for the corruption.

[Anticimex]

@damian Can you please share your sketch including your debug statements? It appears to me that your node between the print "message.getBool: 1" and "message.sensor: 255" is sending something to the GW. That initiates security handshaking so "message" will not be the same between the first and second print.

[Damian]

@anticimex Sure, here it is (still under development so there are some minor, I hope, bugs)

// Enable debug prints to serial monitor
//#define MY_DEBUG

#define MY_DEBUG_VERBOSE_SIGNING
#define MY_SIGNING_SOFT
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
#define MY_SIGNING_REQUEST_SIGNATURES


#define MY_RADIO_NRF24
#define MY_TRANSPORT_WAIT_READY_MS 5000                         
#define MY_NODE_ID 3                                            

#include <MySensors.h>
#include <Bounce2.h>
#include <DHT.h>

/*ZMIENIAMY TYLKO TU*/
#define R_CHILD_ID 0                                          
#define BUTTON_PIN A0                                         
#define RELAY_PIN 3                                           
#define NUMBER_OF_RELAYS 2
#define RELAY_ON 1                                            
#define RELAY_OFF 0                                           

#define T_CHILD_ID 10
#define H_CHILD_ID 11
#define DHT_PIN 8
#define SENSOR_TEMP_OFFSET 0

unsigned long waitDelay = 100;                                  
unsigned long connStatusCheckPeriod = 5*1000.;                   
unsigned long tempHumCheckPeriod = 300*1000.;
/*KONIEC ZMIAN*/



Bounce debouncer[NUMBER_OF_RELAYS];  

DHT dht;
bool metric = true;
float temp = 0.0;
float hum = 0.0;

MyMessage msgTemp(T_CHILD_ID, V_TEMP);
MyMessage msgHum(H_CHILD_ID, V_HUM);
MyMessage msg[NUMBER_OF_RELAYS];                               

bool firstRun = true;                                          
bool relayState[NUMBER_OF_RELAYS] = {false};                   
bool connectionState = false;                                 
bool controllerState [NUMBER_OF_RELAYS] = {false};                                 
bool wasOffline = true;                                         

unsigned long currentTime = 0;
unsigned long oldTime = 0;
unsigned long oldTimeSensor = 0;

unsigned long receiveTimeOld = 0;
unsigned long receiveTimeNew = 0;

bool buttonValue[NUMBER_OF_RELAYS] = {0};
bool oldButtonValue[NUMBER_OF_RELAYS] = {0};                                         


void before() {

}


void setup(){                                                    
  for (int i=0, r_pin=RELAY_PIN, b_pin=BUTTON_PIN; i<NUMBER_OF_RELAYS; i++, r_pin++, b_pin++) {
    pinMode(b_pin, INPUT_PULLUP);                            
    debouncer[i].attach(b_pin);                                  
    debouncer[i].interval(5);                                         

    pinMode(r_pin, OUTPUT);                                   

    digitalWrite(r_pin, RELAY_OFF);
  Serial.print("Setup b_pin:");
  Serial.println(b_pin);                             
  }

dht.setup(DHT_PIN);
}

void presentation() {
  sendSketchInfo("MultiRelay", "1.0");                                
  for (int i=0, r_id=R_CHILD_ID; i<NUMBER_OF_RELAYS; i++, r_id++) {
    present(r_id, S_BINARY);
    msg[i] = MyMessage(r_id, V_STATUS);                                   
  }

  present(H_CHILD_ID, S_HUM);
  present(T_CHILD_ID, S_TEMP);
  metric = getControllerConfig().isMetric;
}


void loop() {                                                     
  currentTime = millis();                                      
  if (firstRun) {                                                 
    firstRunFunc();                                              
  }

if (currentTime - oldTime >= connStatusCheckPeriod) {             
  oldTime = currentTime;
  connectionState = checkConnection();
  if (connectionState && wasOffline){
    for(int i=0;i<NUMBER_OF_RELAYS;i++) {
      send(msg[i].set(relayState[i]), false);                            
    }
  }
  Serial.print("Temp / Hum: ");
  Serial.print(temp);
  Serial.print(" / ");
  Serial.println(hum);
}

if (currentTime - oldTimeSensor >= tempHumCheckPeriod) {             
  oldTimeSensor = currentTime;
  dht.readSensor(true);
  temp = dht.getTemperature();
  temp += SENSOR_TEMP_OFFSET;
  hum = dht.getHumidity();
  send(msgTemp.set(temp, 1));
  send(msgHum.set(hum, 1));
}

  for(int i=0;i<NUMBER_OF_RELAYS;i++) {
      debouncer[i].update();
      buttonValue[i] = debouncer[i].read();
      
    if (buttonValue[i] != oldButtonValue[i] && buttonValue[i]==0) {
      relayState[i] = !relayState[i];
      
      switch (connectionState) {
        case 0:
        workOffline();
        break;
        case 1:
        workOnline();
        break;
      }
    }
    oldButtonValue[i] = buttonValue[i];                                   
  }
}

void receive(const MyMessage &message) {
  if (message.type==V_STATUS) {                                     
      if (firstRun) {                                               
        relayState[message.sensor] = message.getBool();
        } else {                                                    
        controllerState[message.sensor] =  message.getBool();                       
        Serial.print("\nRelay State: ");
        Serial.println(relayState[message.sensor]);
        Serial.print("Switching to: ");
        Serial.println(controllerState[message.sensor]);
        if (controllerState[message.sensor] != relayState[message.sensor]) {                        
          relayState[message.sensor] = controllerState[message.sensor];                             
          wait(waitDelay);                                          
          send(msg[message.sensor].set(relayState[message.sensor]), false);                         
          }
        Serial.print("Relay state after if: ");
        Serial.println(relayState[message.sensor]);
        digitalWrite(RELAY_PIN+message.sensor, relayState[message.sensor] ? RELAY_ON : RELAY_OFF); 
        }
    }
}

void firstRunFunc() {
    
    connectionState = checkConnection();                          
    wait(500);
    for (int i=0, r_pin=RELAY_PIN, r_id=R_CHILD_ID ;i<NUMBER_OF_RELAYS;i++, r_pin++, r_id++){
      switch (connectionState) {
        case 0:                                                     
          relayState[i] = false;                                      
          Serial.print("First Run: Offline: ");
          Serial.println(relayState[i]);
          digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF);
          break;
        case 1:                                                    
          request(r_id, V_STATUS);                          
          wait(waitDelay);
          Serial.print("First Run: Online: ");
          Serial.println(relayState[i]);
          digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF); 
          send(msg[i].set(relayState[i]), false);                         
          break;
      }
    }
    firstRun = !firstRun;                                         
  }

void workOffline() {
  wasOffline = true;
  for (int i=0, r_pin=RELAY_PIN;i<NUMBER_OF_RELAYS;i++, r_pin++){
    Serial.print("Pracujemy offline: ");
    Serial.println(relayState[i]);
    digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF);
  }
}


void workOnline() {
  wasOffline = false;
  for (int i=0, r_pin=RELAY_PIN;i<NUMBER_OF_RELAYS;i++, r_pin++){
    Serial.print("Pracujemy online. Stan przekaznika ktory wysylamy do HA: ");
    Serial.println(relayState[i]);
    digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF);
    wait(waitDelay);
    send(msg[i].set(relayState[i]), false);
    Serial.println("");
  }
}


void receiveTime(unsigned long ts) {
  if (firstRun) {
   receiveTimeNew = ts;
   Serial.print("Receive time first run old / new: ");
   Serial.print(receiveTimeOld);
   Serial.print(" / ");
   Serial.println(receiveTimeNew);
  } else {
    Serial.print("Received time:");
    Serial.println(ts);
    receiveTimeNew = ts;
  }
}

bool checkConnection() {
    bool rt = requestTime(false);
    wait(100);
    if ((receiveTimeNew != receiveTimeOld)) {
      Serial.print("Online, odebrany czas: ");
      Serial.println(receiveTimeNew);
      receiveTimeOld = receiveTimeNew;
      return true;
    }
  Serial.print("Offline, received time: ");
  Serial.println(receiveTimeNew);
  return false;
}

[Anticimex]

@damian Hm, I don't find your debug prints you used earlier.
But in general, I would say that the message object might be overwritten by the library, so if you need to use parts of it, make a copy of the parts you use first and then reference the copy to make sure a new incoming message does not overwrite it.
Eg, in receive():

void receive(const MyMessage &message) {
  if (message.type==V_STATUS) {                        
      bool value = message.getBool();
      uint8_t sensor = message.sensor;
      if (firstRun) {                                               
        relayState[sensor] = value;
        } else {                                                    
        controllerState[sensor] =  value;                       
        Serial.print("\nRelay State: ");
        Serial.println(relayState[sensor]);
        Serial.print("Switching to: ");
        Serial.println(controllerState[sensor]);
        if (controllerState[sensor] != relayState[sensor]) {                        
          relayState[sensor] = controllerState[sensor];                             
          wait(waitDelay);                                          
          send(msg[sensor].set(relayState[sensor]), false);                         
          }
        Serial.print("Relay state after if: ");
        Serial.println(relayState[sensor]);
        digitalWrite(RELAY_PIN+sensor, relayState[sensor] ? RELAY_ON : RELAY_OFF); 
        }
    }
}

And I believe the cause for your problem is that you do

send(msg[message.sensor].set(relayState[message.sensor]), false);  

after

Serial.print("Switching to: ");
        Serial.println(controllerState[message.sensor]);

but before

Serial.print("Relay state after if: ");
        Serial.println(relayState[message.sensor]);

so message might be changed between since the send() will request a nonce from the GW which then overwrites the buffer referenced by message.

[Damian]

@anticimex Thank you, I'll test it and let you know if it helped. PS. debug prints sent before was created in cito, this is my original script. But you find it well, it was instead of:

Serial.print("\nRelay State: ");
Serial.println(relayState[sensor]);

and

Serial.print("Relay state after if: ");
Serial.println(relayState[message.sensor]);

So basically the sections that you've mentioned as a possibly buggy.

[Damian]

@anticimex Yep, remodelling receive() function by adding variables and assigning values respectively message.sensor and message.getBool at the beginning got the job done. Now it works like a charm. Moreover, the whitelisting feature also works now - I had to do something wrong previously. Thank you once again for your help.

[Anticimex]

@damian great to hear! Happy secure home automating

[alowhum]

This page is not up to date, and this is causing some confusion:
https://github.com/tsathishkumar/MySController-rs/issues/15