Update / Root Cause Analysis
I was able to resolve the initial connectivity issue.
The problem turned out to be incorrect IPv6 routing configuration on the OS, which prevented proper Thread ↔ LAN communication.
Required IPv6 RA/RIO state on the host
For Thread Border Router route announcements to be accepted, the following settings are required on the relevant interface:
- accept_ra = 2
- forwarding = 0 (or 1, both are fine as long as accept_ra = 2)
- accept_ra_rt_info_max_plen = 64 (must be ≥ the Thread prefix length)
Once this was set, the Thread ULA route appeared correctly as a proto ra route and IPv6 connectivity started working as expected.
↓
Remaining Issue: MQTT Authentication
The next problem appears to be MQTT username/password authentication with the Nuki Lock.
Observed behavior:
- Mosquitto is configured with allow_anonymous false
- A valid username/password is configured in the Nuki Lock
- Despite this, the broker denies the connection with not authorised
- Debug logs show that the client is treated as anonymous
- If allow_anonymous true is set, the connection succeeds — but still as anonymous, not as the configured user
This suggests that the Nuki Lock does not correctly send MQTT username/password in the CONNECT packet, even though the UI allows configuring them.
↓
Concern
If this interpretation is correct, this represents a security concern, especially for a door lock:
- The device appears unable to authenticate using MQTT credentials
- Broker-side authentication cannot be enforced
- Access control is effectively limited to topic-based ACLs or network trust
I’d be interested to hear whether others can reproduce this behavior. While the official API documentation states that TLS is not supported, basic user/pass authentication should probably be implementable.
For transparency, much of this debugging was done with AI assistance. I don’t have any formal education on networking or MQTT internals, so feedback or corrections are very welcome.
EDIT: still had inconsistent behaviour. With empty pass it started autheticating as the supplied with mosquitto. So I tried it with user + pass again, failing. Changing the password to only [a-zA-Z0-9] worked. Former password had special characters (but was only 24 chars long).
I could not find any information on character restraints in mqtt passwords in the lock though. Would have saved me quite some time…
Apparently, the 32char limit was discussed here (MQTT only accepts passwords up to 32 chars) , but it would be useful to mention password restrictions in places more accessible to the user (preferably the UI).
Thanks for reading, if you have made it this far. And happy holidays.