A TBR may or may not provide a NAT64 and DNS64 function that allows a Matter over Thread device to communicate with IPv4 devices both in your local LAN and over the Internet. And since one of the TBR’s primary functions is to provide bidirectional IP connectivity between Thread and Wi-Fi/Ethernet networks, there is really no hard requirement to translate between IPv6 and IPv4 since IPv6 communication is possible over all those transports. And indeed, I see that in my IPv6 home network, I find both of the unique local IPv6 ranges used by the ST Family Hub thread network and my Echo Show thread network when looking at the routing table of my laptop:
Now, as to whether a ST hub provides a translation service, I’d be surprised. Two design philosophies make me think that; 1) all communication with devices are through the ST hub and through the cloud, even when using the ST app locally on your local network, so there would not be an inherent need to provide NAT64 to communicate with Thread devices; 2) the only direct external Internet-based communications allowed from the hub are to the ST cloud/APIs. For example, Edge drivers are only allowed to communicate to private IP addresses so the idea that they would facilitate public IPv4 communications between the Internet, hub, and devices seems unlikely.
Now, I don’t know if this would be a potential solution, but you could try running an Open Thread Border Router which supports NAT64 and DNS64 and see if you can join it to the ST Thread network. Assuming you can, what’s not clear to me is how you would influence the lock to use that TBR vs the ST hub TBR.
Cloud connectivity. Thread 1.4-enabled Border Routers will gain a defined, standard path to the Internet. This gives manufacturers the ability to add more appealing, dynamic features, like window blinds that can self-adjust to weather changes, while end-users will have more reliable control, at home or off-site. Devices can also receive software updates and report diagnostics, which provides better technical support and lowers costs for installers.
For that to be a valid test, your phone or computer would need to have only an IPv6 address, IPv6 supported on your local network, and only public IPv4 routing from your home router to the Internet to reach the site (or any IPv4 site really).
Not a test if the NATing works, but if an IPv6 device can reach the Internet. Thread devices are IPv6 and that’s the only test he can do for now. We don’t know how the routing tables look like on an ST hub.
(Just realized that my Linux machine is IPv6 only and everything I said is from the perspective of an IPv6 user.)
The Thread and Wi-fi/Ethernet networks used by the TBR are IPv6 unique local addresses that are not routed on the Internet. So you would have to have some form of ULA to Global address NAT’ing being performed on either the router or the ST hub to reach the IPv6 address of the Google site. And to reach the IPv4 address, there would have to be NAT64/DNS64.
It’s certainly feasible that the ST Hub could perform the translation from ULA to GLA since it does have multiple Global IPv6 addresses. But, I’d be surprised…
In my router I can see a few devices (eg: my Synology NAS) with an IPv6 address as well as a “Link Local” IPv6 address. The ST hub also has a “Link Local” IPv6 address but NOT an IPv6 address.
The router is supplied by the ISP, there’s no available NAT’ing. In fact, besides port forwarding there are not much more available configurations.
In the ST hub (Samsung account) I can’t find anything related, either.
I was looking at the Nuki instructions to enable remote access via Thread on Home Assistant and they require the installation of OTBR add-on and enabling NAT64. So, I guess ST would have to provide NAT64, which apparently doesn’t. Right?
Those tests don’t indicate whether your source address is IPv4 or IPv6. Try this site instead https://test-ipv6.com/ and look at the Summary page to see your IPv4 and/or IPv6 addresses.
It would be strange that some of your devices have Global addresses and some wouldn’t. What is the prefix of those that do?
Hi,
sorry for the delay. I’ve been trying a bunch of things. Still no result.
In summary, the site https://test-ipv6.com reports success for IPv4 and IPv6.
I rebooted my ST hub and now I can see its IPv6 address in my router. The IPv6 address prefix is “2001:”. The “Link Local IPv6” remains with prefix “fe80:”.
So, I’ve removed the Nuki lock from ST, rebooted the lock, paired again with ST (via matter). Even deleted the device from Nuki Web and signed it again in Nuki Web.
Still no success. Can’t access remotely.
When I enable the “remote access” option in the matter screen of the Nuki app it seems to be enabled at first but after a while complains about a possible network error.
Any other idea?
Thanks a lot for your effort.
Send me a private message with the full IPv6 address of your ST hub. Also, is the IPv6 address in your browser at the test web page the same prefix of the hub you see in your router?
Occasionally I look a bit helplessly at the last message in this thread and hope in vain for some progress. On December 17th there was a driver update which didn’t lead to any changes.
Those are the stock drivers that are automatically installed in the hub so you don’t need to do anything.
Unfortunately, they didn’t add Nuki locks to the “new-matter-lock” subdriver, which is where the unbolt feature is implemented, so Nuki users are out of luck until they whitelist the Nuki to use the new features.
Did you install the matter-lock driver from the ST Beta channel?
Beta drivers receive changes prior to those changes being released into Production. The only issue with using a Beta driver is you might get a change that ultimately does not make it to production and could potentially break something.
When I installed the Nuki lock in December 2023 and integrated it into Smartthings for the first time, the driver from the ST beta channel was automatically selected.
Since then I reinstalled the lock twice after internal firmware update to see if that would change the displayed firmware version in ST, but it doesn’t. The ST driver was again from the beta-channel.
Ok, I rearranged everything again and got rid of the beta driver state. Visible nothing has changed except the drivers release date is older now. That was to be expected.
