MySensors Library & Examples
2.3.2
|
Typical signing related failure cases and how to solve them.
The first thing to do if you suspect signing is causing problems, is to enable the verbose debug flag for the signing backend.
If you are having trouble getting signing to work, please see the following troubleshooting tips.
This is actually not a signing problem, although often st=fail becomes st=ok when signing is disabled. This is by far the most commonly reported problem with signing, but the problems is not with signing, it is with radio performance.
This is a typical log which might look like a signing related issue but isn't:
The reason for this is that when signing is used, the messages transmitted become relatively large.
Because of this, the message is more sensitive to noise, and the chance for a message to get scrambled increase with the message size. Please refer to the troubleshooting section at the MySensors forum for information on how to improve radio performance.
This is a good place to start: https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help
The signing backend failed to generate the nonce needed to sign a message. This indicate a hardware problem. Please post the debug info on the forum together with a description of your hardware setup.
The signing backend failed to sign the message. Typically this happens if your message is so large, that there is no room left in the buffer to store a signature.
This should not really happen. The reason for this message is that the signing backend is only capable of handling one signed message session at any time. If for some reason multiple nodes send a nonce message to the same node, only the nonce from a node that is the destination of the current message signing session will be accepted. Any other nonces will be dropped. This should not happen as no node should send a nonce unless asked to, and a node will only ask for a nonce to one destination for every signing session.
If you see this message, please post the debugging details on the MySensors forum so it can be investigated further together with a description of your setup.
A node has failed to comply with the signing preferences of this node. Check that the node has received a signing presentation message from this node. This is automatically transmitted to gateways. For other nodes, you need to transmit the presentation from the sketch.
Make sure you have enabled the flag to require signatures to require signatures and have enabled one of the signing backends.
Make sure both source and destination of the signed message has undergone personalization with the same HMAC key.
Also, if whitelisting is used, make sure the proper serial is paired with the proper node ID at the destination. Whitelisting preferences are communicated with the signing presentation (done automatically from nodes to gateway but has to be explicitly done by sketch for node to node communication).
The signing backend validates that the secure elements in EEPROM remain unmodified after personalization using a checksum. If the check fails, the backend reports
This usually indicate that the sketch has modified the secure elements in EEPROM, but if you experience this even after a node is freshly personalized on a atmega device, it could be that the EESAVE fuse bit is not set which mean that the EEPROM is erased when a new firmware is flashed. You will need to enable the EESAVE bit in order to have the security personalization persist in the node.