Signature verification failing.

[Anticimex]

@cgrf the obvious question here is that, did you validate that your personalization is intact, and since you erased eeprom, it isn't. So you must redo personalization, and then the question still stands: are you sure you have the same hmac key at both ends?

Edit: I see that you use the simple password flag, so personalization is not needed. However, if you use that flag, you should not set signing backend. The simple password flag sets everything you need to set with respect to signing.

[Anticimex]

@cgrf another thing is that you don't have the simple password option for version 2.1.1. It was only available as beta prior to 2.2.0.

[cgrf]

@anticimex Thank you very much for your quick response! I didn't realize that the simple password option was not supported in version 2.1.1. Since FOTA doesn't seem to work for me in version 2.2.0 I'll try personalizing my nodes instead, tonight.

[Anticimex]

@cgrf If something is broken in 2.2.0, please report a bug on it.

[cgrf]

@anticimex I will. Right now I'm not sure though, what is actually causing the problem. It might be the library, the bootloader, the controller (MyController), or my general lack of expertise on the topic...

[sindrome73]

But then if I understand correctly, with the current stable version 2.2.0 you can also use:
  #define MY_SIGNING_SIMPLE_PASSWD "mysecretpw"

And it is no longer necessary to customize the nodes and the Gateway ??

If it is so!! Is it safer or less secure ???

[Anticimex]

@sindrome73 it is obviously less secure to use the key directly in your software. It is not protected in any way this is also clearly stated in the documentation (if anyone bothered to actually read it). But many have requested a simpler way of getting "security" so this is the answer. If you want better security, you use the atsha204a and personalize it as documented.

[cgrf]

@anticimex I have configured both devices using the personalization sketch now, and message signing is working perfectly with version 2.1.1! Unfortunately though, this seems to break FOTA again for me. Do you know if this could that actually be related to using message signing?

These are the first lines I see on the gateway after I reset the node that I would expect to get a new firmware over the air:

0;255;3;0;9;TSF:MSG:READ,4-4-255,s=255,c=3,t=7,pt=1,l=1,sg=0:0
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=4
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;Skipping security for command 3 type 8
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=8,pt=1,l=1,sg=1,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,4-4-255,s=255,c=3,t=7,pt=1,l=1,sg=0:0
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=4
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;Skipping security for command 3 type 8
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=8,pt=1,l=1,sg=1,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,4-4-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=4
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;Skipping security for command 3 type 8

And I'd like to say that I appreciate the awesome work you are doing here very much! I really try to read and understand the documentation, but in some places it is not that easy to follow.

[Anticimex]

@cgrf Thank you. Regarding FOTA, I am no expert, but signing should not interfere. And I see nothing in the log that suggests it does.
Regarding the documentation, I would love to know what parts are unclear. I hear this a lot, but I have still not received constructive feedback so that I can improve it.

[cgrf]

@anticimex I would say you are right, signing does not seem to have anything to do with the FOTA problems I'm having. I've kept on try the last few hours and all I can say by now is that the firmware upload over the air works ... sometimes. Also rebooting the gateway seems to increase the probability for success. This is getting a little frustrating right now. Anyway, thanks again for your help with signing!

As for the documentation, I'm not very good at that myself. One thing I would suggest is breaking it up into smaller chunks. For example, separate the theoretical background from the technical documentation. Create smaller how-tos for single use cases, e.g. cover soft and ATSHA204 based signing separately. It could also help to state the library version explicitly that each part of the documentation is referring to.

That's probably not much help, but hopefully at least a little constructive.

[Anticimex]

@cgrf well, thanks for the feedback anyway. As for structure, I do have it in chapters. So the technical stuff is separated from other things, and the whole thing starts with how to actually use it, and the theory goes last for those interested. I could split it into separate pages but I feel that just fragments it.
As for the use cases, they are also split and I am not sure how to simplify them further.
As for what version they work with, the current setup is that there are always two versions. One for the most current release here: https://www.mysensors.org/apidocs/index.html
The other is for the beta releases (development branch), which is always bleeding edge here: https://www.mysensors.org/apidocs-beta/index.html

The version is currently to the git sha. But I have a pull request open that will make further releases show a version number instead which better link the documentation to a human readable version.
It will also update the security part of the "library customization" chapter a bit.