Direct Node to Node communications with Signing

[BenCranston]

@Anticimex Yes, I'm on the development branch. I'll give it a try and get back to you. Last night I was looking at the debug messages and then realized that the send was unsigned, hence the "Verify fail" on the receiving node. thanks. refreshing from git now....

[Anticimex]

@BenCranston The PR is not in yet so you need to apply that one manually though to get the updated API.
And please be advised that if you ever change the behavior of the node that require signatures to stop requiring it, you need to re-present it to the other node (even if they are no longer supposed to communicate), so it updates its stored preferences accordingly. Or it will still believe that the node expect signed messages and send requests for nonces to it. If you have the time, please also test that this "reversal" also works so that you don't get a node that gets locked in the preferences. You only need to present the node if you change signing preferences (or clear the eeprom at the destination).

[BenCranston]

@Anticimex Excellent, I'll apply the changes manually. I think I understand the process. I'm planning on adding the additional signing presentation call toward the other node in the presentation section of my sketch right after the regular "present()" calls. Will I need to have both nodes present to each other, or will the single call kick it into motion for bi-directional communications?

[Anticimex]

@BenCranston If you want signed messages in both directions, they both need to present themselves to each other. This is because you would otherwise get a loop where both sketches respond to a presentation with their own presentation.
In general, a node that has any requirements with respect to security, has to present this to any other node it expect to follow these requirements. The only exception is node/gw relationships which is handled automatically by the node2gw presentation done by the library.
It is safe to keep the node<->node signing presentation calls no matter what security requirements you enable. The function will always take care of presenting the current config. So you can still do a signerPresentation() even if you do not require any signatures/whitelisting and even if you don't support signing at all.

[Mr.Osaka]

@Anticimex I have a similar problem with my project of a thermostat. I use softsigned messages. I communicate from thermostat-node the aperture of valve to the valve-controller-node via gateway, but the message is not signed.
here I wrote the sketch and logs.
I also tried with MY_SECURE_NODE_WHITELISTING, but without results.

Is possible use this scenario with the stable branch?

Thanks for your help

Stefano

[Anticimex]

@Mr.Osaka there won't be any feature development of signing on stable brach except for eat eventually will come from development. But technically you should be able to send a signing requirement message from one node to another yourself to inform the nodes about who require signing and who does not.

[Mr.Osaka]

@Anticimex thanks for the answer

[Anticimex]

@Mr.Osaka
Not necessarily complicated (but untested).
Try this:

sendRoute(build(<message buffer>, <your nodeid>, <destination nodeid>, NODE_SENSOR_ID, C_INTERNAL, I_REQUEST_SIGNING, false).set(true));

This should be sent from the node that expect signed messages to the node that should sign messages.

[Mr.Osaka]

@Anticimex said:

@Mr.Osaka
Not necessarily complicated (but untested).

:relaxed: unfortunately my knowledge of C are very superficial

I do not know if I found the right place to put code:

#ifdef MY_SIGNING_FEATURE
		// Notify gateway (and possibly controller) about the signing preferences of this node
		//sendRoute(build(msg, nc.nodeId, GATEWAY_ADDRESS, NODE_SENSOR_ID, C_INTERNAL, I_REQUEST_SIGNING, false).set(signer.requestSignatures()));
		// STEF INSERT
		sendRoute(build(msg, 143, 200, NODE_SENSOR_ID, C_INTERNAL, I_REQUEST_SIGNING, false).set(true));

unfortunately it was not successful

To probe, I set the node that receives the signed message as a repeater and I forced the transmitting node to become a child of this node.

to explain
Before
A ----> GW -----> B
now
A ----> B ----> GW
it was not successful too.

[Anticimex]

@Mr.Osaka you do this once in your sketch during "boot up". Not inside the library.

[Mr.Osaka]

@Anticimex
I have put at end of setup(), but I have compile errors

/home/stef/Dropbox/Progetti/Thermostat.MySensor-v0.04/Thermostat.MySensor-v0.04.ino: In function 'void setup()':
Thermostat.MySensor-v0.04:192: error: 'build' was not declared in this scope
   sendRoute(build(msgHeater, 143, 200, NODE_SENSOR_ID, C_INTERNAL, I_REQUEST_SIGNING, false).set(true));
                                                                                            ^
Thermostat.MySensor-v0.04:192: error: 'sendRoute' was not declared in this scope
   sendRoute(build(msgHeater, 143, 200, NODE_SENSOR_ID, C_INTERNAL, I_REQUEST_SIGNING, false).set(true));

And what do you mean by <message buffer>?

MyMessage msgHeater(CHILD_ID_HVAC, V_STATUS);

msgHeater is <message buffer>?

ps: sorry for my essential english

[Anticimex]

@Mr.Osaka yes, well, you can either reuse that buffer or create a new one in the same way. Just make sure if you reuse the buffer that you need to make sure it contain the proper data before you use it the next time. The build function is used internally in the library to initiate a message buffer. It might not be available for use in a sketch. You can either use a constructor to initialize a new buffer with the proper settings, or manipulate ab existing buffer to get the data in the message using the api in MyMessage.h

[Mr.Osaka]

Tank's for help and your great work.
I will learn C.
At the moment is more important my entire project, i wait the next release of MySensors.

I will publish soon a "resilient" Thermostat.

By,
Stefano

[Anticimex]

@Mr.Osaka no worries. Thank you. Yes, the signing solution on development branch (which will be part of the next major release) is much easier to work with. Both with personalization, use and any maintenance required. It will also make node to node signing easier to initiate.