Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

network issue talking to lights (after discovery) #2

Open
vvuk opened this issue Aug 5, 2020 · 12 comments · Fixed by #3
Open

network issue talking to lights (after discovery) #2

vvuk opened this issue Aug 5, 2020 · 12 comments · Fixed by #3

Comments

@vvuk
Copy link

vvuk commented Aug 5, 2020

I can discover my light via discovery, but I'm not quite sure what's going on when actually trying to manipulate:

vladimir@clownshoes:~/Downloads$ keylightctl discover
  Starting discovery
  - Elgato\ Key\ Light\ Air\ 9240
  Found 1 light(s) during discovery

vladimir@clownshoes:~/Downloads$ keylightctl describe --all
==> Failed to fetch light options (Elgato\ Key\ Light\ Air\ 9240), err: Get "http://elgato-key-light-air-9240.local.:9123/elgato/lights": dial tcp: lookup elgato-key-light-air-9240.local. on 127.0.0.53:53: no such host

vladimir@clownshoes:~/Downloads$ keylightctl switch -light 9240 on
==> Failed to fetch light options (Elgato\ Key\ Light\ Air\ 9240), err: Get "http://elgato-key-light-air-9240.local.:9123/elgato/lights": dial tcp: lookup elgato-key-light-air-9240.local. on 127.0.0.53:53: no such host

Note that I can ping elgato-key-light-air-9240.local. without problems from the machine (with IP 192.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!)

@vvuk
Copy link
Author

vvuk commented Aug 5, 2020

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.

@endocrimes
Copy link
Owner

@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.

@endocrimes
Copy link
Owner

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.

@vvuk
Copy link
Author

vvuk commented Aug 6, 2020

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?

@endocrimes
Copy link
Owner

Yeah that would be a pretty ok workaround - and would be a nice performance benefit to avoid multiple discovery steps if automating stuff

@endocrimes
Copy link
Owner

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.

@endocrimes
Copy link
Owner

@vvuk 0.0.2 is out which is mostly just built as a dynamic binary. Working on IP fallbacks in a mo

@Talkredius
Copy link

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,

@endocrimes
Copy link
Owner

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.

@cvoltz
Copy link

cvoltz commented May 28, 2021

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

@jasonyavorsky
Copy link

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 ~]$ 

@rombert
Copy link

rombert commented Feb 5, 2023

@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.

https://unix.stackexchange.com/questions/459991/how-to-configure-systemd-resolved-for-mdns-multicast-dns-on-local-network

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants