MQTTClientGateway broken after upgrade - signature failure
-
@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. -
@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.@tomkxy it does? That's a surprise for me. I see no reason for why it should not be supported. Perhaps the guy who did the initial implementation of it did not have atsha204 on the existing target hw, but I cannot imagine a reason for it not being supported for MQTT. Currently the only target architecture that does not support hw signing is esp I believe. At least I do not think it will work as the low level io looks different and the driver is not adapted to handle it.
-
It is interesting that you could get your own "big" message through, but it could be depending on how it actually look. A nonce is pure random and therefore more sensitive to noise (perhaps, I'm not an expert on rf). And I have no knowledge of MQTT at all either but if it affects signing, I probably need to read up on it. @hek perhaps know if I need to :) I have assumed with signing support that a gw communicates with all nodes the same way, MQTT or not.
-
@hek @Anticimex Ok. I switched to hardware signing. HMACs are being generated. So that is ok. When I yesterday saw the issue with the nonce and the comment in the header I switched to soft signing assuming unsupported hardware signing could have caused that.
@hek what is exactly the define
/ W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal) #define MY_W5100_SPI_EN 4 ``` for. I am using an Arduino Mega and I remember that with my old sketch I did not need to use Soft SPI. Is this define on a Mega necessary and if yes pin 4 correct? -
The comment says it all. :) If you have a W5100 module with a SPI-enable pin (not many of them have this) you don't need to enable the Soft-spi for the radio (If I remember correctly it is disabled automatically if the MY_W5100_SPI_EN is defined).
4 is the (default) pin where you should connect it to on your Arduino board. You can change this to fit your setup.
-
@hek Thanks!
After uploading to the Mega I receive intermittent the following error during initialization:
0;255;3;0;9;read register, reg=6, value=0 0;255;3;0;9;Sanity check failed: RF_SETUP register=0 instead of 39, check wiring, replace module or non-P version 0;255;3;0;9;Radio init failed. Check wiring.Most of the time unplugging the Mega from power it goes away. This happens with two different modulesm one with external antenna and one without. Any idea?
-
@Anticimex I am still digging.... Now I figured the following:
The moment I disable MY_SIGNING_REQUEST_SIGNATURES on the sensor node while still having it on the gateway enabled sensor data is received and properly processed on gateway.
I am now a bit puzzled. Am I right assuming that if MY_SIGNING_REQUEST_SIGNATURES is enabled on gateway that sensors nodes need to sign messages to the gateway?
-
@Anticimex I am still digging.... Now I figured the following:
The moment I disable MY_SIGNING_REQUEST_SIGNATURES on the sensor node while still having it on the gateway enabled sensor data is received and properly processed on gateway.
I am now a bit puzzled. Am I right assuming that if MY_SIGNING_REQUEST_SIGNATURES is enabled on gateway that sensors nodes need to sign messages to the gateway?
