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

.local named devices (i.e. ESPHOME devices) only resolve for a few minutes after booting HA #54

Closed
jjvandenberg opened this issue Aug 25, 2021 · 13 comments

Comments

@jjvandenberg
Copy link

ESPhome devices show up being "Online" only a few minutes after booting the system. After that, they turn to "Offline", although they are still online. mDNS resolving seems to breakdown within a few minutes after rebooting the OS.
Running Home Assistant Operating System, which is, according to the site, the recommended installation method.

@jjvandenberg jjvandenberg changed the title .local named devices (i.e. ESPHOME devices) only resolve a few minutes after booting GA .local named devices (i.e. ESPHOME devices) only resolve a few minutes after booting HA Aug 25, 2021
@jjvandenberg jjvandenberg changed the title .local named devices (i.e. ESPHOME devices) only resolve a few minutes after booting HA .local named devices (i.e. ESPHOME devices) only resolve for a few minutes after booting HA Aug 25, 2021
@jjvandenberg
Copy link
Author

Here is a recent log file:
_hassio_dns_logs (1).txt

@stale
Copy link

stale bot commented Jan 9, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 9, 2022
@jjvandenberg
Copy link
Author

Hi , why is development not picking this up ?

@stale stale bot removed the stale label Jan 9, 2022
@Strohhutpat
Copy link

this works for me #64 (comment)

@Strohhutpat
Copy link

the issue still exists 👎

@deviantintegral
Copy link

I seem to be unable to resolve mDNS hosts even immediately after startup. I was sure this worked at some point in the past, but now I'm not sure. For testing, I downloaded HAOS 6.6 and spun it up in a VM. The host is able to resolve mDNS names, but containers (including hassio_dns) can not.

I verified with tcpdump that mDNS packets are making it to the hassio_dns container network interface.

It looks like there's been work around this at #73, but I'm unclear on how to upgrade to the latest release or properly test it.

@deviantintegral
Copy link

I also downloaded a fresh HAOS 7.5 RC VM, and it has the problem out of the box. It's running the 2021.06.0 version of the dns container. I was able to update it manually with ha dns update --version 2022.03.0 and unfortunately mDNS does not resolve with that either.

Since I can easily replicate this outside of my actual HA install, I'm glad to help debug.

@mdegat01
Copy link
Contributor

mdegat01 commented Mar 13, 2022

@deviantintegral if you're doing this testing on a dev system I would recommend changing to the beta channel by doing ha supervisor options --channel beta or channel dev. Beta is currently set to use 2022.03.0and dev is bleeding edge. If you manually update a plugin like that I'm not sure that change will persist.

Anyway more importantly though, the issue at hand. If you have shell access on the host can you try the following:

resolvectl query <mdns address>

Does that work? If not can you share the output?

If it does work then when you try to use that URL within HA is there an error in the DNS plugin's log? supervisor logs -> DNS or just docker logs hassio_dns from the host.

Starting in 2022.03.0 of the DNS plugin those two should be identical unless the DNS plugin is unable to talk to the host over DBus (in which case there should be an error in the DNS plugin's logs). Any time the DNS plugin sees a .local name it hands it off to systemd-resolved on the host, exactly what resolvectl query is doing.

@deviantintegral
Copy link

I updated my VM into the beta channel, and it's now fully working for mDNS resolution. I'm guessing that there's other updates needed that prevented it from working when trying on my live host. If I get a chance, I will reset my VM back to the stable channel to prove flipping back and forth fixes things.

@deviantintegral
Copy link

I had a chance to fully test this, and the 2022.03.0 version of plugin-dns is working for me 🎉, even without going to the beta channel.

For reference, on the host:

# resolvectl query zigbee2mqtt.local
zigbee2mqtt.local: 2607:f2c0:f00e:7a00:216:3eff:fe85:6a39 -- link: enp0s3
                   2607:f2c0:f00e:7a00::1d0c   -- link: enp0s3

-- Information acquired via protocol mDNS/IPv6 in 126.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Info and behaviour before updating:

# ha os info
board: ova
boot: A
data_disk: /dev/sda8
update_available: false
version: "7.4"
version_latest: "7.4"
# ha dns info
host: 172.30.32.3
locals:
- dns://192.168.20.1
servers: []
update_available: false
version: 2021.06.0
version_latest: 2021.06.0
# docker exec -it homeassistant bash
bash-5.1# ping zigbee2mqtt.localping: bad address 'zigbee2mqtt.local'

After updating to 2022.03.0:

# ha dns update --version 2022.03.0
Command completed successfully.
# docker exec -it homeassistant bash
bash-5.1# ping zigbee2mqtt.local
PING zigbee2mqtt.local (2607:f2c0:f00e:7a00::1d0c): 56 data bytes
64 bytes from 2607:f2c0:f00e:7a00::1d0c: seq=0 ttl=64 time=0.570 ms
64 bytes from 2607:f2c0:f00e:7a00::1d0c: seq=1 ttl=64 time=0.561 ms
64 bytes from 2607:f2c0:f00e:7a00::1d0c: seq=2 ttl=64 time=0.185 ms
^C
--- zigbee2mqtt.local ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.185/0.438/0.570 ms

Assuming the plugin is going to be updated in the stable channel in the next few weeks, I think this issue can probably be closed. Nice work!

@joshuaspence
Copy link

2022.03.0 fixes the problem for me.

[core-ssh config]$ ping homeassistant.local
ping: bad address 'homeassistant.local'
[core-ssh config]$ ha dns update --version 2022.03.0
Processing... Done.

Command completed successfully.
[core-ssh config]$ ping homeassistant.local
PING homeassistant.local (172.30.32.1): 56 data bytes
64 bytes from 172.30.32.1: seq=0 ttl=64 time=0.258 ms
64 bytes from 172.30.32.1: seq=1 ttl=64 time=0.207 ms
64 bytes from 172.30.32.1: seq=2 ttl=64 time=0.309 ms

@mdegat01
Copy link
Contributor

Fixed by #82

@mdegat01
Copy link
Contributor

Also note that there is a new option to disable the fallback dns added here: home-assistant/supervisor#3586 as I would guess a number of users on here would be interested in that.

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

No branches or pull requests

5 participants