I finally got a Zniffer setup and I figure out the process to get it what it needs to decrypt traffic. So S0 traffic, no problem just need the key. I saved the keys to a text file from PC Controller and imported to Zniffer.
For S2 you need to capture the Nonce in the zniffer log is what I am reading. In PC Controller you can delete the SPAN then send ON/OFF commands to force it to refresh which sends the Nonce. So that seems to work, but ONLY for traffic to/from the USB Stick and not the hub. So for the HUB I did a 'refresh' in the Zwave details, which also seems to send the Nonce. So then it seems to work for traffic to/from Node 1.
Now the problem is traffic going from the "virtual nodes" (typically 2-5). Those do not seem to get decrypted at all, and I cannot figure out how to either force the traffic to route to Node 1, or how to get the Nonce for those virtual nodes...
Any else got this to work?
You have the right steps here.. Unfortunately for S2 you just have to wait for a new nonce to be sent, most likely if you power cycle the device, it will get a new one..
This is actually why I just leave zniffer running all the time
For some reason a bunch of my devices like to talk only to the virtual nodes that the updated SDK created, number 72 especially. That's the node I cannot get the nonce for. I will have to try a power cycle and see if that will grab it for the virtual node. Thanks for the tip.
@bcopeland I tried looking at the z wave specs but could not find anything specific on this. So if the supervision class is listed in the "Command Classes" (as opposed to Secure Command Classes) doesn't that mean something like a supervision report would expected to NOT use security? Otherwise question is, does it even matter because it doesn't seem to hurt anything.
On this device when I do an on/off the device replies back with the supervision report security encapsulated. It also sends back a multilevel report (security and supervision get encapsulated). The driver then replies back with a supervision report, with no security. The driver code is passing the command through the "zwaveSecureEncap" function. I can only assume the hub detects it does not need security for that command and just returns the raw command back?
21 = device, 72 = virtual node on hub
Initially it was expected to reply securely to supervision gets.. Later they decided it would be better to send supervision report non-securely to ensure receipt.. So on devices that list it as non secure CC.. They will send and accept supervision get securely, but want supervision report non-securely..
That is correct.. This method checks if the CC sent is expected securely or non-securely. And has extra logic for supervision CC.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.