mDNS name changed with 4.13 OS update

[MikeSherman (Michael E Sherman)]

I updated the OS 4.13 on my Pi 4 about 6 hours ago.

Since then all of the sensor devices that were reporting data via MQTT can not connect to the mosquitto server. Those I checked are reporting rc=2 (Connection Refused: Identifier rejected)
The connection and all the devices were working properly before the update.

I can still send commands to devices that listen to MQTT and respond.
I restored backups from before the upgrade, but it does not restore the older OS version.
Please advise what to check or do.

EDIT:
I just checked the assesscontrollist is unchanged. The user still has permissions.

EDIT2:
The Supervisor → Host System → Hostname is still “hassio”.
But my devices trying to connecting to “hassio.local” no longer connect.

What has to change to put this back like it was?

EDIT3:
semi solved:
Conclusion from above: mDNS is not working correctly…
run

avahi-browse -alr

and find that on mDNS the system is now “hassio-2”

How do I set it back to “hassio”???

EDIT4:
Since I have seen nothing here about how to repair this, I decided to blow the system away ad restore it from a backup.
When I mounted the SD on my laptop to re-write it, the volumes on the card were opened in file browser windows. As usual, there were partitions for hassos-data and hassos-overlay.
There was mounts for hassos-kernel and hassos-kernel1… I guess a new kernel with the 4.13 upgrade.

But instead of a single “disk” being mounted, there were two. disk and disk1.

Is it possible this is way my hassio.local has become hassio-2.local?

EDIT5:
I didn’t hear anything better from the community, so I reloaded my system.
I re-flashed the SD card with the latest .iso (3.14) and restored from the backup I made just before the 3.14 upgrade.
My system is back and running.

Thanks,
-Mike

[FloatingBoater (James Derrick)]

Hi,

Apologies if replying to your post a month later doesn’t help you directly, but in case others search for the same issue…

Summary

If you find a desktop PC browser link to http://hassio.local:8123/ stops working, but http://hassio-2.local:8123/ works, login and browse to the Supervisor setting and change the Hostname from hassio to hassio ignoring that the desired value is displayed:
HASS -> Supervisor -> Host System -> Hostname

Detail

I recently noticed that after an update HASS was not available using the mDNS URL http://hassio.local:8123/ . Multicast DNS works by servers broadcasting ‘I offer a service’ out to the local network - hence the *.local domain.

Using Fedora Linux (with avahi and and avahi-tools installed - see here for more help), it was easy to see that HASS was broadcasting mDNS as hassio-2 rather than hassio.
Testing from a desktop PC showed that http://hassio-2.local:8123/ now worked, however http://hassio.local:8123/ did not.

Note - Android doesn’t support mDNS despite many Nest / Google services relying on it - use a desktop PC to test mDNS

After searching for hassio-2, I found this post. Like you, I found the Supervisor hostname displayed as ‘hassio’ - HOWEVER after changing it to something else and back to ‘hassio’ the mDNS name changed back and http://hassio.local:8123/ started working again.

If you have a Linux machine with Avahi installed:

$ avahi-browse -al
+   eno1 IPv6 hassio                                        _ssh._tcp            local
+   eno1 IPv4 hassio                                        _ssh._tcp            local
+   eno1 IPv6 hassio                                        _sftp-ssh._tcp       local
+   eno1 IPv4 hassio                                        _sftp-ssh._tcp       local

[MikeSherman (Michael E Sherman)]

Thanks for your reply.
My system became “hassio-2” again with the last update and your post reminded me how to fix it!
-Mike

[FloatingBoater (James Derrick)]

Hi,

Again to help the community search for the fix, I had to re-install HASS on a RPi4 and found the default hostname had changed from http://hassio.local:8123/ to http://homeassistant.local:8123/.

Sadly, this bug still exists - after an update, mDNS couldn’t find my install, however avahi-browse -ar quickly found http://homeassistant-2.local:8123/.

The fix is the same - change the hostname to something else, then immediately change it back to remove the -2 unwanted suffix.

James

[oxyd]

I’ve had that problem for quite a while myself - I often have occurrences of “-2”, “-3” and even “-6” being added at the end of the hostname.

My workaround is to SSH to the host and run sudo service avahi-daemon restart

I sometimes run service avahi-daemon status before and after that previous command to see what hostname it was set to, and then visually check it’s been fixed.

[MikeSherman (Michael E Sherman)]

Thanks, that makes sense. I’ll try it next time.

[oxyd]

The hostname’s extension is still incrementing for me… I’ve seen it go up to “-26” using the command journalctl -u avahi-daemon
It’s getting really annoying to constantly restart the service. And out of principle I don’t want to set a cron to work around a bug.

I did some digging and the problem is quite widespread, as per this GitHub issue: Spurious name conflicts #117

Based on this, I will try some other workarounds like disabling ipv6 (use-ipv6=no) or force the interface (allow-interfaces=eth0) in the file /etc/avahi/avahi-daemon.conf

The last comments from the maintainer are from just over a month ago so I’m hopeful a fix might hit us soon…

[oxyd]

Not sure if my attempts for a workaround are going to fix it.

Using the command journalctl -u avahi-daemon -f to follow the logs, I notice that I consistently get the following warning when I restart the service:

*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***

I do not think any of the Docker containers running on my host have Avahi running though, and I definitely don’t have Plex installed. So it’s probably part of that reported issue.

[oxyd]

Here’s a positive update:

After having added these 2 lines to /etc/avahi/avahi-daemon.conf

use-ipv6=no
allow-interfaces=eth0

I can report that the .local hostname has been stable for multiple days!
This should take care of it until a new version of avahi, with a bug fix, is released.

I hope this helps.

[proggaras]

Actually I still have this Issue with my Supervised Home Assistent OS 6.1.
Changing the hostname to something else and back solves the problem temporary but after a restart I am ending up with this: 13h3d86d568s66l395a73add687eg3r.fritz.box

@oxyd In which Docker container did you find the file: /etc/avahi/avahi-daemon.conf ?

[oxyd]

@proggaras I run Home Assistant on top of Raspbian on a Pi 4.
All the commands I have documented were typed in a SSH session straight into the physical host.