Z-Wave the public standard

Z/IP Gateway - Problem with unsolicited messages


#1

Hello,

I am setting a Raspberry Pi 3 with the ZIP Gateway.
I have followed the guide on the developers page:
http://zwavepublic.com/developer

I successfully have added a binary switch (wall plug) to the gateway.
The assigned nodeID is 6 (IPv6: fd00:bbbb::6).
I can switch on and off the plug using both reference_client and pyzip program.

Now I would like to receive unsolicited messages from the wall plug.
How can I achieve this goal?

I have launched reference_listener, switched ON (or OFF) the plug but I didn’t receive anything.
In console, after a while, I receive this message:

SSL_accept: Resource temporarily unavailable
error:1413C138:SSL routines:dtls1_check_timeout_num:read timeout expired

I have searched in this forum and find some interesting post, but I am still unable to receive unsolicited message.

This is my zipgateway.cfg:

ZipUnsolicitedDestinationIp6 = fd00:aaaa::0010
ZipUnsolicitedDestinationPort = 41230
ZipUnsolicitedDestination2Ip6 = fd00:aaaa::ccd7:3768:c71d:49b6
ZipUnsolicitedDestination2Port = 41231
#SerialLog = /tmp/ziprouter.serlog
ZipCaCert=/usr/local/etc/Portal.ca_x509.pem
ZipCert=/usr/local/etc/ZIPR.x509_1024.pem
ZipPrivKey=/usr/local/etc/ZIPR.key_1024.pem
#Eepromfile=/etc/eeprom.dat
#TunScript=/usr/local/etc/zipgateway.tun
ZipLanGw6 = fd00:aaaa::1234
ZipPortal=10.10.2.95
ZipPortalPort=44123
#ZipTunPrefix = 2000::
#ZipTunIp6PrefixLength = 128
#ZipManufacturerID=0
#ZipHardwareVersion=1
#ZipProductID=1
#ZipProductType=1
#ZipMBPort=41230
#ZipMBDestinationIp6=
#ZipMBMode=1
ZipPSK=123456789012345678901234567890AA
ExtraClasses= 0x8F 0x85 0x59 0x5A 0xF100 0x43 0x75 0x20 0x30 0x31 0x5E 0x70 0x71 0x72 0x73 0x75 0x80 0x84 0x86 0x25
ZipSerialAPIPortName=/dev/ttyACM0
ZipLanIp6=fd00:aaaa::3
ZipPanIp6=fd00:bbbb::1

This is my network configuration:

ifconfig
br-lan    Link encap:Ethernet  HWaddr 96:3b:16:0c:6a:9a
          inet addr:10.10.2.94  Bcast:10.10.255.255  Mask:255.255.0.0
          inet6 addr: fd00:aaaa::fc9:6e4b:f61d:2cce/64 Scope:Global
          inet6 addr: fe80::ba27:ebff:fe46:1ce/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:454483 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1234 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:26723230 (25.4 MiB)  TX bytes:89301 (87.2 KiB)

eth0      Link encap:Ethernet  HWaddr b8:27:eb:46:01:ce
          inet addr:169.254.37.162  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:518195 errors:0 dropped:377 overruns:0 frame:0
          TX packets:33305 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44866064 (42.7 MiB)  TX bytes:2344057 (2.2 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:416 (416.0 B)  TX bytes:416 (416.0 B)

tap0      Link encap:Ethernet  HWaddr 96:3b:16:0c:6a:9a
          inet addr:169.254.248.51  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::19e4:d32d:685e:349c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6949 errors:0 dropped:0 overruns:0 frame:0
          TX packets:456749 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:409430 (399.8 KiB)  TX bytes:33130373 (31.5 MiB)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:13:54:9b
          inet addr:10.10.2.95  Bcast:10.10.255.255  Mask:255.255.0.0
          inet6 addr: fe80::ba27:ebff:fe13:549b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:45745 errors:0 dropped:8 overruns:0 frame:0
          TX packets:250 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4814119 (4.5 MiB)  TX bytes:35461 (34.6 KiB)

I have also send the COMMAND_CLASS_ASSOCIATION ASSOCIATION_SET to the node in order to receive notifications.

In the zipgateway.log, there are some interesting rows related to unsolicited messages:

2031937 Authentication verified
2031937 ApplicationCommandHandler 6->1 class 0x25 cmd 0x03 size 3
2031937 nm_fsm_post_event event: NM_EV_FRAME_RECEIVED state: NM_IDLE
2031937 Unhandled command  0x25:0x03 from fd00:bbbb::06
2031937
2031937 Sending Unsolicited to IP app...
2031938 New client session allocated
2031938 Sending Unsolicited to IP app...
2031938 New client session allocated
2031942 Sending first attempt
2031942 DTLS: DTLS read failed
lipaddr: fd00:bbbb::0006 lport: 41230
ripaddr: fd00:aaaa::ccd7:3768:c71d:49b6 rport: 41231
2031942
2031942 DTLS Classic node session package
2031943 queue_send_done to node 6 queue 1
2031944 Sending first attempt
2031946 DTLS: DTLS read failed
lipaddr: fd00:bbbb::0006 lport: 41230
ripaddr: fd00:aaaa::ccd7:3768:c71d:49b6 rport: 41231
2031946
2031946 DTLS Classic node session package
2031946 queue_send_done to node 6 queue 1
2032954 Sending first attempt
2032954 DTLS: DTLS read failed
lipaddr: fd00:bbbb::0006 lport: 41230
ripaddr: fd00:aaaa::ccd7:3768:c71d:49b6 rport: 41231
2032955
2032955 DTLS Classic node session package
2032955 queue_send_done to node 6 queue 1
2032955 Sending first attempt
2032956 DTLS: DTLS read failed
lipaddr: fd00:bbbb::0006 lport: 41230
ripaddr: fd00:aaaa::ccd7:3768:c71d:49b6 rport: 41231
2032956
2032956 DTLS Classic node session package
2032956 queue_send_done to node 6 queue 1
2034956 DTLS: Session timeout
lipaddr: fd00:bbbb::0006 lport: 41230
ripaddr: fd00:aaaa::0010 rport: 41230
2034956
2034956 DTLS: Closing DTLS connection
lipaddr: fd00:bbbb::0006 lport: 41230
ripaddr: fd00:aaaa::0010 rport: 41230
2034956

I have tried to send unsolicited messages to a reference_listener executed on a external Ubuntu machine (ipv6: fd00:aaaa::ccd7:3768:c71d:49b6) and traced the ethernet traffic with wireshark.
I see some DTLS packets:

  • Client Hello
  • Hello Verify Request
  • Client Hello
  • Server Hello, Server Hello Done
  • Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

After this messages, it seems that the handshake does not go over and continues to repeat the sequence:

  • Server Hello
  • Server Hello Done
  • Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

What am I doing wrong?

Please, help me :slight_smile:

Thanks in advance.

Andrea


#2

+1
Even I am getting the exact same message

It worked once though for 2 minutes with Aeotec Wallmote, but since then its silent

Thanks


#3

Hi Andrea,

Can you try using “fd00:aaaa::ccd7:3768:c71d:49b6” as ZipUnsolicitedDestinationIp6 and not ZipUnsolicitedDestination2Ip6. If possible?

When gateway says “Sending Unsolicited to IP app…” Do you see any DTLS handshake on wireshark


#4

One more to pile on this thread…

We are following the same steps as “csystem” using the Raspberry Pi Success Image. We are seeing exactly the same behavior. When we wireshark the DTLSv1 packets from ZIP Gateway to the reference_listener we see that listener/server does not respond with a “Session Ticket” but repeats the “Server Hello” portion of the handshake. Something is definitely broken. The “Server Hello” messages appear to occur after 1 second, 2 second, 4 seconds (binary exponential backoff?)… OpenSSL version on the success image is reporting as 1.0.1t.

DTLSv1 communication between reference_client and ZIP Gateway works fine and looks good in wireshark.

Strangely, if we connect to the reference_listener using the reference_client then the DTLSv1 handshakes seem fine and communication is as expected. Although, mysteriously, the only ipv6 addresses which seem to work are “::1”.

We also tried to test the reference_listener using OpenSSL s_client over ipv6 (OpenSSL 1.1.0) from a second pi, and, that also exhibits the same handshaking problem.

Any suggestions how to resolve this communication issue for “unsolicited/unhandled” messages to the reference_listener would be greatly appreciated.

Thank you!


#6

Does it work for you if you start reference listener to listen to all ipv4/ipv6 addresses by starting following way?

./reference_listener -l ::

./reference_listener -l 0.0.0.0


#7

Hello.

I have the same.

Is anybody resolved this issue?


#8

We had success by calling the function zwif_gw_unsolicit_set, which takes as parameters a pointer to a zwifd_t, an uint8_t[16] containing an IPv6 address, and an int with the destination port.

The zwifd_t is that of the COMMAND_CLASS_ZIP_GATEWAY. The IPv6 address is that of the zware client, it can be obtained via a call to zwnet_local_addr_get. The destination port is obtained through a call to zwnet_listen_port_get. That way you obtain the IP+port of your zware client.

The zwif_gw_unsolicited_set makes all unsolicited messages on that network to be forwarded to that client.

Hope this helps.