Open vvuk opened 4 years ago
Oh. My resolv.conf actually does have nameserver 127.0.0.53
which is.. very surprising, equally surprising that anything else works. This seems to be a systemd-resolved thing, in Ubuntu 20.04. Indeed the local nameserver on 127.0.0.53
cannot resolve the .local
address, even if getaddrinfo
or gethostbyname
work. I'm guessing some underlying network stack is bypassing getaddrinfo
and such and is making direct DNS requests.
@vvuk huh that's ✨ weird ✨ - I'm tempted to spin up an Ubuntu VM to test this (because I haven't ran into issues on NixOS or macOS), and I'm wondering if it's potentially a Go issue.
If you're using the pre-compiled binary, I'm wondering if the problem might be with CGO being disabled and something related to network configuration being ignored.
Could be -- if Go is ignoring libc (like it might) and going straight to DNS, because the port 53 DNS proxy server seems to behave differently.
Would it be possible as a workaround to add a command line flag to let you explicitly specify the IP address of the light to communicate with?
Yeah that would be a pretty ok workaround - and would be a nice performance benefit to avoid multiple discovery steps if automating stuff
Going to cut a release with #3 and some support for providing an IP as a fallback hopefully today - Sorry for the delay I was swamped at work.
@vvuk 0.0.2
is out which is mostly just built as a dynamic binary. Working on IP fallbacks in a mo
same problem as vvuk has with version 0.0.3 works on my Laptop linux _amd64 (OpenSuse Leap 15.2) but not on Raspi jessie (debian) (Copied the arm binary from the Laptop to the Raspi) As a work around I added in /etc/hosts on the Raspi the line : 192.168.1.100 elgato-key-light-69d4.local
192.168.1.100 is the fixed IP address of the light 69d4 is my light ID This works for me fine. Now I can integrate this light in to my home automation :) @endocrimes thx for the code,
FWIW I ran into something similar to this on PopOS! the other day, bc .local resolution is somewhat broken on my network (my ISP provided fritzbox maps everything to *.fritz.box). My nixos machine has functional .local by other means though.
You might consider looking at how your /etc/nsswitch.conf
is setup. With systemd-resolved, on my system, I got things working by using:
hosts: mymachines resolve mdns4_minimal files myhostname dns
I have this same issue, not sure what ended up fixing this for other users? Manjaro default install.
[jason@wintermute ~]$ keylightctl discover
Starting discovery
- Elgato\ Key\ Light\ 3342
Found 1 light(s) during discovery
[jason@wintermute ~]$ keylightctl describe --all
==> Failed to fetch light options (Elgato\ Key\ Light\ 3342), err: Get "http://elgato-key-light-3342.local.:9123/elgato/lights": dial tcp: lookup elgato-key-light-3342.local.: no such host
[jason@wintermute ~]$
@jyavorska - what does host elgato-key-light-3342.local.
return for you? Your local DNS resolver may not support mDNS by default. For example, systemd-resolve
does not, and you need to enable it manually.
I can discover my light via discovery, but I'm not quite sure what's going on when actually trying to manipulate:
Note that I can ping
elgato-key-light-air-9240.local.
without problems from the machine (with IP192.168.50.52
); I can also open the URL given by the error and get a json doc in my browser.(Thanks for building this!)