MQTTClientGateway broken after upgrade - signature failure
-
Try increasing the timeout for the nonce. I don't know if MQTT logic results in a longer turnaround time for message processing.
-
@Anticimex I increased MY_VERIFICATION_TIMEOUT_MS to 15s. Isn't that the nonce timeout?
-
@Anticimex nonce requested from node 0 looks suspicious. Is that the correct node id?
-
@Anticimex Isn't node 0 the gateway node id? If not that might be something to follow up on.
-
Ah, it's the GW. But I see from gw log that you get st=fail on the nonce so the GW does try to send it but your node does not receive it. So you have communication problems. Bear in mind that with signing, the full payload size is used, which puts maximum strain on the rf link so you have to have a solid coverage.
-
@Anticimex Both node were lying side by side. And I had my small network working perfectly on an older dev branch. So I don't think it can be due to coverage or distance.
Arghhh: I an only post once within 2 minutes... -
@Anticimex Both node were lying side by side. And I had my small network working perfectly on an older dev branch. So I don't think it can be due to coverage or distance.
Arghhh: I an only post once within 2 minutes...@tomkxy well, your logs indicate signing works as it's supposed to. But the nonce fails to arrive, and this is also indicated by st=fail, so you have a radio issue. You probably get problems without signing as well if you transmit full length messages.
-
@Anticimex Both node were lying side by side. And I had my small network working perfectly on an older dev branch. So I don't think it can be due to coverage or distance.
Arghhh: I an only post once within 2 minutes... -
@Anticimex I will try it further apart. But I have other nodes having the same problem and they are sitting exactly where they were before the upgrade. The only thing I changed for the sensors is to re-compile with the latest development branch for the sensor nodes.
Only the MQTTClientGateway was running a sketch based on a rather "old" version. So that upgrade is significant.
-
Depending on the "leap" you have taken some changes in the rf stack could have affected things. The signing solution have been changed but it has not affected payload sizes so I do not think signing is causing this (other than forcing maximum payload sizes which it has all along).
-
@Anticimex I just tried to disable signing on the gateway and on the sensor and it works like a charme.
So I still hope there is some issue either in my sketch (defines etc.) or a bug. Without signing I do not consider MySensors for me as an option. :-( -
@Anticimex I just tried to disable signing on the gateway and on the sensor and it works like a charme.
So I still hope there is some issue either in my sketch (defines etc.) or a bug. Without signing I do not consider MySensors for me as an option. :-(@tomkxy like I said, from the logs I see nothing wrong with signing. But your nonce is not coming through due to rf issue. I have verified signing on development branch myself (since I developed it) so I am confident it works. But it is well known that rf performance is decreasing with increased message size and I assume you don't use full size transmissions with signing disabled. So I would suggest you check rf decoupling, PA levels and antennae. It is also known that keeping radios too close can cause bursts which appear as failed transmissions but I am no specialist in those areas. Signing assume a ideal transport mechanisms, so you have to ensure there are no st=fail:s for signing related messages. The signing backend cannot handle those for you.
-
@Anticimex thanks for your support. Don't get me wrong I think MySensors and the whole signing concept is great. It is just somehow frustrating to see how a whole installation - even small until now - which worked for more than half a year is just breaking down while not having a glue what I can do about it.
What in particular are you referring to with reference to rf decoupling?
Just wondering how does your config look like?
What radios? What configs? -
@Anticimex thanks for your support. Don't get me wrong I think MySensors and the whole signing concept is great. It is just somehow frustrating to see how a whole installation - even small until now - which worked for more than half a year is just breaking down while not having a glue what I can do about it.
What in particular are you referring to with reference to rf decoupling?
Just wondering how does your config look like?
What radios? What configs?@tomkxy I use rf24 with default settings (except some moved io pins) and a PA-enhanced radio on the GW. But getting the rf24 to behave can be tricky. And the larger the message, the trickier it gets. Unfortunately this means it gets trickiest with signing enabled as it makes most messages very large (thus making them more sensitive to rf disturbance). Unfortunately, it is not much I can do about it from a signing perspective. Reducing the message size for signatures and nonces or adding fault tolerance to the security messages compromises security quality, and I already to that with the truncation of the signatures (due to rf24 limitations) so I don't want to "nerf" if further. So the signing solution is quite rf sensitive. But the way I see it, that just serves as a good measure for the overall quality of the rf network. If it works with shorter messages, sooner or later, maybe you add a node that transmits longer messages and start to get issues. With signing enabled, you are forced to root out any lingering rf issues immediately, and is saved from unpleasant surprises later on. But of course I understand the frustration, having experienced it myself several times. But st=fail is not a signing problem, it is a rf problem. So I am afraid I am not the best resource to provide answers. @tekka has made an excellent pull request where he has optimized the rf24 stack significantly. Perhaps applying it could help solve your rf issue: https://github.com/mysensors/Arduino/pull/392
-
@Anticimex I fully agree to your judgement that the problem is not due to the signing as such. However, I also do not believe in the RF24 issue. I tried with a CUSTOM child and using the max payload size available which without signing went through.
I think there might be an issue related to the changed code pathes which is caused by "injecting" signing or a define or whatsoever in my sketch is wrong after the upgrade.
I tried @tekka pull request with the result that nothing arrived at the gateway at all.
Do you know why hardware signing is not supported in the MQTTClientGateway?
-
@Anticimex I fully agree to your judgement that the problem is not due to the signing as such. However, I also do not believe in the RF24 issue. I tried with a CUSTOM child and using the max payload size available which without signing went through.
I think there might be an issue related to the changed code pathes which is caused by "injecting" signing or a define or whatsoever in my sketch is wrong after the upgrade.
I tried @tekka pull request with the result that nothing arrived at the gateway at all.
Do you know why hardware signing is not supported in the MQTTClientGateway?
@tomkxy Both hardware and software signing has no knowledge about MQTT. They only handle signatures of messages passed between gw and nodes. How the gw communicates with controller is irrelevant. Unless MQTT messes up how gw adresses nodes, I cannot see how signing could not work for MQTT. And if it does, it is a bug in MQTT implementation and not signing.
-
@Anticimex I did not want to suggest that it is a bug in signing, I just referred to the comment in the W5100MQTTClientGateway sketch saying "Hardware SHA204 signing is currently not supported" and was wondering whether you know why.
Sorry for bothering you on that. As I said I agree that the problem must somehow be related to transmission.
