OZW Control Panel does not open probably due to frame decryption issue
woddou opened this issue · 5 comments
Hi guys,
First time for me on GitHub (to old to have used it during my developper life time) but quite experienced with domoticz and Zwave networks as heavy user.
I'm using Domoticz 2020.2 (Build 13119) on a RPi 4 and getting connected with ZW using a Z-Stick Gen5+ (new generation) from Aotec as most of the people using ZW.
Here is the description of the issue I've discovered and tried to analyse using OZW code and debugging capabilties from Chrome.
It is very simple. Since few days OZW Control is not populated anymore (empty web page beside the frame itself) but Domotics (and therefore OZW) works perfectly.
So it is not a blocker but CP is quite usefull for some functions not available in Domoticz UI.
Following my investigation about the issue i doscovered that we might have an issue in ZW Encrypted frame mangement.
The reason why the CP is not populate is simple, XML files is trying to open are corrupted ( ozwcp.poll.XXXXXX & ozcache_0xXXXXXX & poll).
These file are somewhere created by OZW based on Z-Stick and network info provided by devices if I'm right.
The corruption was limited to one specific device information (Aoetec Doorbell 6 - zw162) especially in SoundSwitch Tone information (text with lenght up to 40 chars). So I decided to correct the file (ozwcp.poll.XXXXXX) deleted and delete the cache one, then at the next restart it worked (CP was populating itself)... until OZW asked SoundSwitch information to zw162 with the same result on XML files (corruption) and CP (not loading anymore).
Next step of investigation was to look at OZW logs (attached) and I discovered that the text which is send by zw162 was misinterpreted by ozw after decryption (zw&62 in S2 mode, e.g. in line 24533 of log: 03 Traditional Apartƒßã¾qùØÚu[z - 10 sec instead of 03 Traditional Apartment Buzz - 10 sec) and the same for all info data lenght higher than 20 chars, below that (and there are several SoundSwithc text below that lenght, everything is OK.
I have tried to understand in ozw code where this issue might come and as far as today I suspect an issue when preparing the data to be decrypted (extracting data from frame, padding with 0.... ?) but without any capabilities to compile and make it in debug version no way for me to track more than that.
So if one of you guys more equipped an knowledgable than me can have a look at this, that will probably help a lot all user of same config with Aeotec zw162 and I'm afraid that if what I suspect is true any dataload higher than 20 chars in S2 mode will have the same issue.
If you need any additional information or details feel free to ask.
Many thanks.
By the way beside that issue you will see another issue on my log file (DNS Error Occured), not sure about consequences and the root cause of this one but if somebody can help !
OZW_Log.txt
Hi,
After looking at the ZWSecurity.cpp code I guess it comes from a buffer management issue, so it will be good to have it in DEBUG mode, that will allow to check between the "Raw" info and "Decrypted" one in the log against the below Debug info:
#ifdef DEBUG
Log::Write(LogLevel_Debug, _sendingNode, "Encrypted Packet Sizes: %u (Total) %u (Payload)", e_length, encryptedpacketsize);
Internal::PrintHex("IV", iv, 16);
Internal::PrintHex("Encrypted", encyptedpacket, 32);
/* Mac Starts after Encrypted Packet. */
Internal::PrintHex("Auth", &e_buffer[11+encryptedpacketsize], 8);
#endif
I have described the steps I used to build and debug domoticz together with openzwave from one Visual Studio 2019 solution over at the domoticz forum. This should allow you to see what the exact values are in your buffer without having to change the code.
The DNS error is because gizmocuz overruled the download location for the openzwave configuration files to point to localhost. He is under the impression that the public location for open zwave's (xml) device configuration files is no longer available. If someone could make a peer-to-peer mechanism for sharing these config files that would be awesome!
The DNS error is because gizmocuz overruled the download location for the openzwave configuration files to point to localhost. He is under the impression that the public location for open zwave's (xml) device configuration files is no longer available. If someone could make a peer-to-peer mechanism for sharing these config files that would be awesome!
Alright and understood but is there anything to do to correct it or basically does it have an negative impact or not ?
I have described the steps I used to build and debug domoticz together with openzwave from one Visual Studio 2019 solution over at the domoticz forum. This should allow you to see what the exact values are in your buffer without having to change the code.
Thank you rrozema, yes the only way is to build openzwave in debug mode but the last time I built anything (software I mean) was 25 years ago, I'm a bit rusted ! Anyway I will look at you tuto and see what I can do in the coming weeks. In the meantime I have added the device in none secure mode and it works very well, OZWCP is back on track...