You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that discovery of client names from UnifiOs/Ubios fails on the first run of ctrld after my UDM is restarted. This has been happening since at least v1.3.10 of ctrld and v4.0.20 of UnifiOS; although it may have been occurring for longer and I just didn't notice it. Unfortunately I can't confirm the exact start date/versions.
When ctrld starts after a device restart (either a true power off/power on or just a software reboot), I do see an error logged about Ubios discovery failing to initialize: {"level":"error","error":"exit status 1","time":"2025-01-06T13:45:20-05:00.759","message":"could not init Ubios discover"}
If I restart the ctrld daemon, UnifiOS discovery will work properly. I'm positing that this is just a case of the discovery init occurring too early in the boot process although I can't be certain. Perhaps a fix is to just have the init re-attempt every x minutes until successful, etc.
This doesn't cause any resolution issues, but does mean that I get some duplicate clients for that endpoint as the clients get reported using another discovered name (usually via PTR or mDNS) until I restart ctrld, at which point they report using their UbiOS names again.
A full debug log after a recent restart is below; I don't see a lot that says why the discovery init is failing but I am happy to do additional testing and debugging if it helps.
Full log
{"level":"info","time":"2025-01-06T13:45:16-05:00.141","message":"starting ctrld v1.3.11"} {"level":"info","time":"2025-01-06T13:45:16-05:00.261","message":"os: linux Debian GNU/Linux 11 (bullseye) (4.19.152-ui-alpine)"} {"level":"debug","time":"2025-01-06T13:45:20-05:00.433","message":"control server started: /var/run/ctrld_control.sock"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.435","message":"resolving \"dns.controld.com\" using bootstrap DNS [\"76.76.2.22:53\" \"[fe80::201:5cff:fe6b:2a46]:53\"]"} {"level":"error","error":"dial udp 76.76.2.22:53: connect: network is unreachable\ndial udp [fe80::201:5cff:fe6b:2a46]:53: connect: invalid argument","time":"2025-01-06T13:45:20-05:00.436","message":"could not lookup \"AAAA\" record for domain \"dns.controld.com\""} {"level":"error","error":"dial udp [fe80::201:5cff:fe6b:2a46]:53: connect: invalid argument\ndial udp 76.76.2.22:53: connect: network is unreachable","time":"2025-01-06T13:45:20-05:00.436","message":"could not lookup \"A\" record for domain \"dns.controld.com\""} {"level":"warn","time":"2025-01-06T13:45:20-05:00.436","message":"could not resolve bootstrap IPs, retrying..."} {"level":"debug","time":"2025-01-06T13:45:20-05:00.446","message":"resolving \"dns.controld.com\" using bootstrap DNS [\"76.76.2.22:53\" \"[fe80::201:5cff:fe6b:2a46]:53\"]"} {"level":"error","error":"dial udp 76.76.2.22:53: connect: network is unreachable\ndial udp [fe80::201:5cff:fe6b:2a46]:53: connect: invalid argument","time":"2025-01-06T13:45:20-05:00.446","message":"could not lookup \"AAAA\" record for domain \"dns.controld.com\""}
{"level":"error","error":"dial udp 76.76.2.22:53: connect: network is unreachable\ndial udp [fe80::201:5cff:fe6b:2a46]:53: connect: invalid argument","time":"2025-01-06T13:45:20-05:00.446","message":"could not lookup \"A\" record for domain \"dns.controld.com\""}
{"level":"warn","time":"2025-01-06T13:45:20-05:00.447","message":"could not resolve bootstrap IPs, retrying..."} {"level":"debug","time":"2025-01-06T13:45:20-05:00.481","message":"resolving \"dns.controld.com\" using bootstrap DNS [\"76.76.2.22:53\" \"[fe80::201:5cff:fe6b:2a46]:53\"]"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.521","message":"got answer from nameserver: 76.76.2.22"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.545","message":"got answer from nameserver: 76.76.2.22"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.545","message":"bootstrap IPs: [2606:1a40::22 76.76.2.22]"}
{"level":"info","time":"2025-01-06T13:45:20-05:00.545","message":"bootstrap IPs for upstream.0: [\"2606:1a40::22\" \"76.76.2.22\"]"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.547","message":"resolving \"dns.controld.com\" using bootstrap DNS [\"76.76.2.22:53\" \"[fe80::201:5cff:fe6b:2a46]:53\"]"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.574","message":"got answer from nameserver: 76.76.2.22"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.594","message":"got answer from nameserver: 76.76.2.22"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.594","message":"bootstrap IPs: [2606:1a40::22 76.76.2.22]"}
{"level":"info","time":"2025-01-06T13:45:20-05:00.594","message":"bootstrap IPs for upstream.1: [\"2606:1a40::22\" \"76.76.2.22\"]"}
{"level":"info","bootstrap_ip":"8.8.8.8","time":"2025-01-06T13:45:20-05:00.594","message":"using bootstrap IP for upstream.2"}
{"level":"info","time":"2025-01-06T13:45:20-05:00.594","message":"starting DNS server on listener.0: 0.0.0.0:5354"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.595","message":"router setup on start"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.595","message":"start checking DNS loop"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.595","message":"skipping external: upstream.0"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.595","message":"skipping external: upstream.1"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.595","message":"skipping external: upstream.2"}
{"level":"debug","time":"2025-01-06T13:45:20-05:00.595","message":"end checking DNS loop"}
{"level":"debug","iface":"lo","time":"2025-01-06T13:45:20-05:00.604","message":"Restoring DNS for interface"}
{"level":"error","error":"exit status 1","time":"2025-01-06T13:45:20-05:00.759","message":"could not init Ubios discover"}
The text was updated successfully, but these errors were encountered:
I've noticed that discovery of client names from UnifiOs/Ubios fails on the first run of
ctrld
after my UDM is restarted. This has been happening since at least v1.3.10 of ctrld and v4.0.20 of UnifiOS; although it may have been occurring for longer and I just didn't notice it. Unfortunately I can't confirm the exact start date/versions.When ctrld starts after a device restart (either a true power off/power on or just a software reboot), I do see an error logged about Ubios discovery failing to initialize:
{"level":"error","error":"exit status 1","time":"2025-01-06T13:45:20-05:00.759","message":"could not init Ubios discover"}
If I restart the ctrld daemon, UnifiOS discovery will work properly. I'm positing that this is just a case of the discovery init occurring too early in the boot process although I can't be certain. Perhaps a fix is to just have the init re-attempt every x minutes until successful, etc.
This doesn't cause any resolution issues, but does mean that I get some duplicate clients for that endpoint as the clients get reported using another discovered name (usually via PTR or mDNS) until I restart ctrld, at which point they report using their UbiOS names again.
A full debug log after a recent restart is below; I don't see a lot that says why the discovery init is failing but I am happy to do additional testing and debugging if it helps.
Full log
The text was updated successfully, but these errors were encountered: