Z/IP and client connection


I’ve a question about IP address of ZIP gateway.
These are his logs (a piece of):

15588950 This node is Secure
15589046 NM Init
15589101 DHCP Timeout
15589104 Sending DISCOVER
15589106 All nodes have an IPv4 address
15589110 got OFFER
15589111 send REQUEST
15589114 got ACK
15589116 Node 1 has ipv4 address
15589118 Checking for new sessions
15589120 We should send a request for node 1
15589123 New IPv4 assigned for node 1
15589125 send REQUEST
15589128 got ACK
15589130 Node 1 has ipv4 address
15589132 Checking for new sessions
15589135 We should send a discover
15589137 New IPv4 assigned for node 1
15589139 Sending DISCOVER
15589142 got OFFER
15589144 send REQUEST
15589146 got ACK
15589148 Node 19 has ipv4 address
15589151 Checking for new sessions
15589153 New IPv4 assigned for node 19
15589156 All nodes have an IPv4 address

15591753 All nodes have been probed

As you can see I’ve a Bridge Controller and a node that I’ve added.
When i run pyzip…from GUI i see two Gatewy addresses…one with fd00:aaa::3 and another with
Is i connect to fd00:aaa::3 i’m not able to send (and receive) command from/to the other node, while if i connect using address all work fine…why?
How can i do for work only with ZipLanIp6 = fd00:aaaa::3?



Might be related with this issue: https://github.com/Z-WavePublic/libzwaveip/issues/8 I had some troubles with ipv6 addresses in the past, I changed the code and now it seems to work ok.


If relying on IPv6, you might need to let your host know that the Z-wave nodes is reachable through the Gateway.

On a Linux system it looks like this:
sudo ip -6 route add fd00:bbbb::/64 via fd00:aaaa::3

  • if using default settings on Z/IP Gateway.


It work perfect now. Tanks a lot



i have beaglebone zip gateway with bridge controller and pyzip client
when i starting pyzip i am getting 1. fd00:aaa::3 2. ip_address
what does this 2 things mean…?
wheather should i connect to 1 or 2…?



Hi guys,

Been tearing my hair out all afternoon with this one. As I’ve mentioed in a previous thread I’m running the zipgateway for Raspberry Pi. If I run the reference_client locally (ie. on the Raspberry Pi) then I can ‘list’ and use the ‘send’ commands with no problems at all.

I’m now trying to run the reference_client from my Mac. I can now not only connect to the listener on the Raspberry Pi but I can also successfully ‘list’ the devices…

zwDBAD073A09.local.: "Switch Binary [dbad073a0900]"
zwDBAD073A07.local.: "Sensor Notification [dbad073a0700]"
zwDBAD073A06.local.: "Static Controller [dbad073a0600]"
zwDBAD073A01.local.: "Static Controller [dbad073a0100]"

However if I try and issues a ‘send’ command to the switch it times out with this error…

SSL_do_handshake: Resource temporarily unavailable
Error connecting
Failed to connect to PAN node
(ZIP) Terminated: 15

This is connecting over IPv6. So I used the admin web interface to change the zipgateway address to the IPv4 address of the Raspberry Pi.

I connect again with the reference_client on my Mac. Again… everything is okay so far. I can see the list of Z-Wave nodes.

However, when I try a ‘send’ command I get the same error as above. Tailing the log on the Raspberry Pi I can see that each node is getting an IPv4 address from DHCP, so it seems odd my Mac can’t ‘connect’ to them.

Having performed a TCPDUMP on my Mac it looks like even when I connect to the zipgateway over IPv4 the ‘send’ command is still trying to connect to the IPv6 addresses.

As far as I can see I have two options…

I can try and fix the IPv6 routing issue (I’ve tried the above ip -6 route add command to no avail) or I can try and figure out why the reference_client is still trying to connect over IPv6 even when I connect to the gateway over IPv4.

Any advice much appreciated.

FWIW this is the version info from the About page of the Z-Ware web interface:

Z-Ware Lib - 7.38
Z-Ware Web - 0.50
Z-Ware Web API - 1.19
Z-Ware App UI Engineering - 2.36
Z-Ware App UI PC/Tablet - 18.34
Z-Ware App UI Phone - 18.34


The reference_client sample application that you’re using doesn’t fall back to IPv4 addresses when it has valid IPv6 addresses that aren’t reachable. I made a pull request that should fix this, which hasn’t been reviewed by the developers yet, that you can try out in the feat/addr-sel branch of the git repo. Please try it out and let me know if that allows you to connect over IPv4 - there will be some connection errors printed out to the console (these are from the IPv6 attempt that failed) but after that it should make an IPv4 attempt that should succeed.

This command will ensure that messages to fd00:bbbb::/64 are routed through fd00:aaaa::3. It won’t solve your problem unless your networking stack already knows how to reach fd00:aaaa::3 - I’m guessing it doesn’t. If your network is setup correctly, your network interface (on a Mac, typically en1 for the wireless or en0 for the wired) should have an IPv6 address that starts with fd00::aaaa that was assigned to it by zipgateway. If you don’t see it, your IPv6 network is probably not setup right. Usually the fix is not on your machine at all, but on your home router.


Thanks for the help, I’ll try rebuilding the reference client using the branch you mentioned and report back.

WRT my networking, my Mac has an IPv6 address assigned by the router… In theory I should be able to manually assign an fd00::aaaa/64 address and be able to reach fd00:aaaa::3, right?


Happy to report that your branch works fine for me over IPv4. You’re right, I still get the SSL handshake warnings but the Z/IP commands fire just fine against my light switch. Thanks Hans.