KeviNH Posted January 16, 2018 Posted January 16, 2018 Anybody have experience with a Z-Wave Sniffer, either the software that comes with the $1,000 Sigma Dev Kit, or the $85 Suphammer product? I'm familiar with using RF sniffers and SDR, but figure it might be easier to start with a device already designed to receive Z-Wave messages than starting with raw analog GFSK samples. Sadly, yepher's RaZBerry open zniffer project was made obsolete by the launch of OpenZWave back in 2016. Yepher was using the $65 RaZBerry daughterboard (a simple ZM3102/ZM5202 chip on an expansion board for the Pi) with a serial sniffer in software to attempt to "black box" reverse engineer the Sigma Serial API. Now most of the API is public, (on exception is the promiscuous listener calls used by Zniffer).
MWareman Posted January 17, 2018 Posted January 17, 2018 No experience in either of these, but I had not come across the Suphammer product before. I think I’m going to order one...
io_guy Posted January 18, 2018 Posted January 18, 2018 Not sure the usefulnes since more devices are creeping up secure and this just sniffs. Might be better grabbing a standard controller stick, adding as a secondary controller and writing a program with the openzwave library.
KeviNH Posted January 18, 2018 Author Posted January 18, 2018 Not sure the usefulnes since more devices are creeping up secure and this just sniffs. Might be better grabbing a standard controller stick, adding as a secondary controller and writing a program with the openzwave library. I ordered a Sigma UZB stick, my first foray into a secondary controller.
MWareman Posted January 20, 2018 Posted January 20, 2018 Not sure the usefulnes since more devices are creeping up secure and this just sniffs. Might be better grabbing a standard controller stick, adding as a secondary controller and writing a program with the openzwave library. True. But the prevalence of SSL has not rendered Wireshark useless. A controller bound to your network will only show packets on your network. A sniffer will show all detected packets.
KeviNH Posted January 20, 2018 Author Posted January 20, 2018 True. But the prevalence of SSL has not rendered Wireshark useless. A controller bound to your network will only show packets on your network. A sniffer will show all detected packets. And in fact there's a plug-in for Wireshark so if you control the server, you can load the key and decode encrypted traffic. A sniffer would be interesting for travel. For example, Wynn Hotel & Casino deployed Z-Wave for in-room controls, claim to have 65,000 devices in one building.
vjk Posted January 25, 2018 Posted January 25, 2018 And in fact there's a plug-in for Wireshark so if you control the server, you can load the key and decode encrypted traffic. A sniffer would be interesting for travel. For example, Wynn Hotel & Casino deployed Z-Wave for in-room controls, claim to have 65,000 devices in one building. About two years ago, I made my own zwave sniffer based on the SmartRF CC1110 development kit. I had to write a simple piece of firmware which programs the receiver properly and sends received packets to the USART port. The kit cost was approximately the same as the Suphammer product's. The sniffer proved to be extremely helpful in understanding and diagnosing zwave issues, especially because you can see not only the packets but also the signal strength (RSSI) which is provided by the CC1110 radio. I did not see RSSI on the Suphammer screenshots, though. If it does provide RSSI, I'd buy it without hesitation. Re. encryption. I'd speculate that currently in 99% of zwave deployments only locks are encrypted, the rest (switches, etc) transmit in clear text.
KeviNH Posted January 27, 2018 Author Posted January 27, 2018 ... The sniffer proved to be extremely helpful in understanding and diagnosing zwave issues, especially because you can see not only the packets but also the signal strength (RSSI) which is provided by the CC1110 radio. I did not see RSSI on the Suphammer screenshots, though. If it does provide RSSI, I'd buy it without hesitation. I've got a Suphammer coming in the mail, will let you know. He does mention per-packet RSSI values as a feature enhancement for a future firmware release.
vjk Posted January 27, 2018 Posted January 27, 2018 I've got a Suphammer coming in the mail, will let you know. He does mention per-packet RSSI values as a feature enhancement for a future firmware release. Please, do.
KeviNH Posted January 31, 2018 Author Posted January 31, 2018 Received my Suphammer sniffer, I can confirm that it has an option to display RSSI: [FABB42DF] 01 -> 12 : [FABB42DF] 13 -> 01 : NOP [FABB42DF] 01 -> 13 : AssignId [100C] Press 'c' for cmd mode. Z-Wave Sniffer v1.0.0 - (C) Jon Suphammer Commands: h[homeid] n[nodeid] c[class] r<reg><ch> q<0|1> - raw i<0|1> - invalid crc o<0|1> - rssi x - exit o1 Press 'c' for cmd mode. [FABB42DF] 01 -> 13 : AssignId [100C] (LQI: 4, RSSI: -26) [FABB42DF] 01 -> 13 : NOP (LQI: 12, RSSI: -26) [FABB42DF] 01 -> 12 : (LQI: 7, RSSI: -27) [FABB42DF] 01 -> 13 : AssignId [100C] (LQI: 4, RSSI: -28) [FABB42DF] 01 -> 13 : NOP (LQI: 3, RSSI: -27)
vjk Posted February 1, 2018 Posted February 1, 2018 Received my Suphammer sniffer, I can confirm that it has an option to display RSSI: [FABB42DF] 01 -> 12 : [FABB42DF] 13 -> 01 : NOP [FABB42DF] 01 -> 13 : AssignId [100C] Press 'c' for cmd mode. Z-Wave Sniffer v1.0.0 - (C) Jon Suphammer Commands: h[homeid] n[nodeid] c[class] r<reg><ch> q<0|1> - raw i<0|1> - invalid crc o<0|1> - rssi x - exit o1 Press 'c' for cmd mode. [FABB42DF] 01 -> 13 : AssignId [100C] (LQI: 4, RSSI: -26) [FABB42DF] 01 -> 13 : NOP (LQI: 12, RSSI: -26) [FABB42DF] 01 -> 12 : (LQI: 7, RSSI: -27) [FABB42DF] 01 -> 13 : AssignId [100C] (LQI: 4, RSSI: -28) [FABB42DF] 01 -> 13 : NOP (LQI: 3, RSSI: -27) Your probe must be pretty close to the controller with as good RSSI as above. I do not see acknowledgement packets in your trace. Are they skipped in the non-raw mode ? With my probe, a trace looks like this (turn on a light): 2018-02-01T08:59:27.744755 01037408 13 7 (13) 410e 2001ff17 -44 8 -- Turn on light 2018-02-01T08:59:27.750747 01037408 7 13 (10) 030e 8c -72 4 -- Ack from the light (so the round trip is about 6ms) I dump just raw data. Interpreting manually: 01037408 Home ID 13 Source (controller) 7 Dest (13) Length 410e Flags 2001ff Payload: 0x20 Basic Command Class, 0x01 Set, 0xff Value (it's a dimmer) 17 CRC -44 RSSI 8 LQI The ack has no payload, just CRC. The turn-off command looks very similar: 2018-02-01T08:59:35.259072 01037408 13 7 (13) 4101 200100e7 -44 10 2018-02-01T08:59:35.264899 01037408 7 13 (10) 0301 83 -71 9 Is it possible to receive raw data on the serial port and attach timestamps to the packets with your probe ?
KeviNH Posted February 1, 2018 Author Posted February 1, 2018 Your probe must be pretty close to the controller with as good RSSI as above. I do not see acknowledgement packets in your trace. Are they skipped in the non-raw mode ? With my probe, a trace looks like this (turn on a light): ... Is it possible to receive raw data on the serial port and attach timestamps to the packets with your probe ? The ISY is one floor below, pretty much directly underneath the sniffer. I'll try moving around, and post a snippet with "raw" mode turned on.
vjk Posted February 1, 2018 Posted February 1, 2018 The ISY is one floor below, pretty much directly underneath the sniffer. I'll try moving around, and post a snippet with "raw" mode turned on. Still, it's a pretty strong signal. My probe is sitting a shelf above the controller, about 2' away. Perhaps, your probe receiver sensitivity is higher. In my example above, the controller RSSI is -44 and the switch RSSI is -71. The switch is located about 15' away and is separated by at least one wall (depending on the angle the signal propagates at) from the controller.
KeviNH Posted February 2, 2018 Author Posted February 2, 2018 Here's a capture showing raw packets with ISY changing brightness on a lamp contoller: Press 'c' for cmd mode. Z-Wave Sniffer v1.0.0 - (C) Jon Suphammer Commands: h[homeid] n[nodeid] c[class] r<reg><ch> q<0|1> - raw i<0|1> - invalid crc o<0|1> - rssi x - exit q1 o1 Press 'c' for cmd mode. r,,,,1,WakeUp Beam,,0,, r,,,,1,WakeUp Beam,,0,, r,,,,9,WakeUp Beam,,0,, r,,,,1,WakeUp Beam,,0,, r,,,,1,WakeUp Beam,,0,, r,FABB42DFC0103020A0430,FABB42DFC,01,04,,,0,25,-29 r,,,,1,WakeUp Beam,,0,, r,FABB42DFC07450E1901140400310D050000010F220D05000053,FABB42DFC,07,01,Unknown,0700310D050000010F220D050000,0,12,-17 r,FABB42DFC07450E1901140400310D050200010F130D05020062,FABB42DFC,07,01,Unknown,0700310D050200010F130D050200,0,12,-19 r,FABB42DFC0214020B0A49,FABB42DFC,01,13,,,0,10,-29 r,FABB42DFC0214020B0A49,FABB42DFC,01,13,,,0,12,-29 The USB sniffer device itself doesn't timestamp messages, probably doesn't have a clock onboard. It'd be easy enough to prepend timestamps in an app or serial-to-LAN service.
vjk Posted February 2, 2018 Posted February 2, 2018 Here's a capture showing raw packets with ISY changing brightness on a lamp contoller: Press 'c' for cmd mode. Z-Wave Sniffer v1.0.0 - (C) Jon Suphammer Commands: h[homeid] n[nodeid] c[class] r<reg><ch> q<0|1> - raw i<0|1> - invalid crc o<0|1> - rssi x - exit q1 o1 Press 'c' for cmd mode. r,,,,1,WakeUp Beam,,0,, r,,,,1,WakeUp Beam,,0,, r,,,,9,WakeUp Beam,,0,, r,,,,1,WakeUp Beam,,0,, r,,,,1,WakeUp Beam,,0,, r,FABB42DFC0103020A0430,FABB42DFC,01,04,,,0,25,-29 r,,,,1,WakeUp Beam,,0,, r,FABB42DFC07450E1901140400310D050000010F220D05000053,FABB42DFC,07,01,Unknown,0700310D050000010F220D050000,0,12,-17 r,FABB42DFC07450E1901140400310D050200010F130D05020062,FABB42DFC,07,01,Unknown,0700310D050200010F130D050200,0,12,-19 r,FABB42DFC0214020B0A49,FABB42DFC,01,13,,,0,10,-29 r,FABB42DFC0214020B0A49,FABB42DFC,01,13,,,0,12,-29 The USB sniffer device itself doesn't timestamp messages, probably doesn't have a clock onboard. It'd be easy enough to prepend timestamps in an app or serial-to-LAN service. Hmm, does not look right to me ... 1. Wake up frames have only destination address (to wake up), see page 47 in the doc below, but in your example the node id is "1" which must be your primary controller. It does not beam to itself. Node id "9" is perhaps correct: 2. Assuming FABB42DFC0103020A0430 is a raw packet, the number of hex digits is odd (should be even, of course). If we skip the first "F", then: http://www.itu.int/rec/T-REC-G.9959-201501-I, page 42: ABB42DFC - your home id 01 - source (your controller) 0302 - frame flags (an ack frame, seq number 3) 0A - frame length 04 - dest node 30 - CRC An almost legitimate ack frame from Node 4 to the controller, but CRC is not right, should be 3f instead of 30 3. In F ABB42DFC 07 450E 19 01 140400310D050000010F220D050000 53 (Node 7 to Node 1) According to the doc above, the header type (5) is incorrect, the length seems ok (25 bytes/hex 0x19), the CRC is incorrect : should be 0x68 instead of 0x53. The payload may be legit, but with incorrect CRC who knows. 4. The last two: Looks like an ack frame from node 10 (0A) to node 2. F ABB42DFC 02 14020B 0A 49 But the header type (4) is incorrect and the CRC is incorrect, the length is correct. 5. None of the captured frames controls a light. I'd contact the seller and find out what the deal is. Re. timestamps, you are right, they can be added when reading from the serial port, that what I do.
KeviNH Posted February 2, 2018 Author Posted February 2, 2018 I obfuscated the home id, didn't want to paste it to a public forum I agree that the WakeUp Beam frames look weird. The sniffer is on a PC that's close to the ISY and to one repeater, but not near the lamp or anything else. What's the best way to get the Z-Wave UID for a given ISY node ID?
KeviNH Posted January 26, 2019 Author Posted January 26, 2019 So the good news is, I've arranged for a ISY at my Makerspace. Now we can start doing Z-wave for environmental control (thermostats, sensors, maybe a coke machine) at the space, and I can post un-obfuscated sniffer captures and test some stuff beyond what I do at home.
lion Posted March 10, 2019 Posted March 10, 2019 While suphammer et al look interesting, Z-Wave's spectrum in within the range of the base RTL-SDR ...
KeviNH Posted March 11, 2019 Author Posted March 11, 2019 6 hours ago, lion said: While suphammer et al look interesting, Z-Wave's spectrum in within the range of the base RTL-SDR ... There's some Z-Wave receiver source code on github for HackRF and one for rtl_sdr, but with the latter you're only going to be guessing at RSSI at best, as the dongles are inherently uncalibrated. See also:
Recommended Posts
Archived
This topic is now archived and is closed to further replies.