operating-system: Hostname conflict, changing published hostname from 'homeassistantxxx' to 'homeassistantxxy'

Is it perhaps possible to reopen this issue? Seems like quite a few setups are affected. Many users probably don’t even notice.

@agners This issues happens when there is multiple network interfaces (for example for different VLANs), and router (for example UniFi) proxies/reflects multicast traffic between networks.

Solution is here

I had simillar symptoms:

1. Constant spam about hostname conflict.
2. High CPU usage by systemd-resolved and mdnsd:
3. resolvectl mdns returned on mode for all active interfaces. Turning them off by resolvectl mdns 2 resolve/off was fruitless, because NetworkManager turns mdns on immediately.

I’ve got it solved following way:

1. Set all connections to resolve-only mode (you might leave one of connections active, to keep homeassistant.local working)

> nmcli connection modify <connection> connection.mdns resolve

1. Restart Network Manager

> systemctl restart NetworkManager.service

1. Confirm it working

> resolvectl mdns
Global: yes
Link 2 (eth0): resolve
Link 3 (wlan0): no
Link 4 (usr0): resolve
Link 5 (iot0): resolve
Link 8 (docker_gwbridge): no
Link 9 (hassio): no

After that a constant stream of conflicts got resolved, and no more CPU hogging by systemd-resolved and mdnsd.

In my experience, after enabling mDNS repeater you run into more problems: How do you deal with names/services announced using IPv6 link local addresses?

Easy, I don’t have IPv6 in the local network. Having two WANs, I figured there would be no gain of NATing IPv6 to the LAN. 😄

IMHO, nicer would be to have all the devices in one LAN, and filter traffic per device (based on port/MAC, e.g. using OpenFlow). These type of filtering and device specific routing is definitely done in data center SDNs, but not sure if one ever attempted to implement such networking architectures in home networks. 😅

Have you implemented that approach? It sounds like a lot of configuration work (which would be manual for me because tplink omada isn’t easily automateable). How do you deal with additions to the guest WLAN? Having to add the IPs/MACs of every new guest to the configuration when someone asks for the wifi password sounds a bit impractical 😛

It should be possible to influence mDNS settings per interface. it could be part of the Supervisor networking. Patch welcome 😉

Great, I will see if I can find the right places to make it configurable. If/when it makes it to the UI will would be a checkbox in this area?

mDNS is built on link-local multicast. Link-local multicast is meant to be, surprise, link local. Any mDNS reflector or other “link-local multicast extension to another subnet” is a hack at the end of the day. Since nowadays many IoT protocols embrace protocols built on link-local multicast (like mDNS/DNS-SD), VLAN is kinda a bad option. IMHO, instead of spending time making VLAN work, rather embrace zero trust networking: Just make sure all your devices are secured by default (no anonymous logins, safe passwords, encrypted communication etc.). Consider your network Internet. It’s quite freeing 😄 If you have legacy stuff or stuff you can’t secure that way, you can still use a VLAN to move that particular device off of your main LAN.

The problem with that is that there are no IoT devices that are secure. The biggest security risk on a network are the IoT devices that you have no control of. Especially the ones that contact anything in the cloud. Look at Eufy, Ring, etc.

The only reason my iot devices can communicate with anything on my network is so that I can cast to them or otherwise control them like for instance the TV or sound bar etc. And in that case, I would prefer that they are not allowed to talk to anything else other than the specific hosts/ports that I want them to talk to. I also block them from calling home except for the hosts that absolutely stop them from working. The number one blocked DNS queries on my network are all tracking hosts at Microsoft, Amazon, Samsung etc.

In a perfect world, they wouldn’t talk to the cloud at all and have absolutely no internet access and only be allowed to speak to the specific hosts and ports that I want them to.

Unfortunately, that would require the manufacturers to give up all that add tracking money which they will never do. Or it would end up doubling, tripling or more the price of the devices.

Until then, I’ll use whatever means I need to to completely segregate them from anything and everything else on my network that I don’t need them to be able to talk to. And right now that’s usually either vlans or a whole lot of manual firewall rules. Any of my IoT devices that do not absolutely need internet are not even given a gateway when DHCP assigns them their address which is static. If there’s an update that’s needed and no way for me to push it to the device locally I allow an exception to the specific host that they need to talk to for the update and only for the amount of time it takes for them to update.

Just putting a device on your network and allowing it to do whatever it wants is almost as bad as just posting your configs and passwords on the internet.

+1 Totally agree. Zero trust requires proper endpoint management and security, but in the IOT space endpoints are the problem for all the reasons just mentioned. We don’t have the option of using only secure IOT devices because they don’t seem to make those.

And this is only going to get worse with Matter. At least with zigbee the cheap chinese etc… devices don’t have IP access to anything, and if I trust the zigbee coordinator code (I use the open source zigbee2mqtt), you have limited security exposure. But with matter everything is IP connected, and that’s a real problem because I don’t trust any of those devices.

VLAN’s are going to be even more important with Matter and will require even more sophisticated network management to safely integrate them in our homes.

mDNS is built on link-local multicast. Link-local multicast is meant to be, surprise, link local. Any mDNS reflector or other “link-local multicast extension to another subnet” is a hack at the end of the day.

Since nowadays many IoT protocols embrace protocols built on link-local multicast (like mDNS/DNS-SD), VLAN is kinda a bad option.

IMHO, instead of spending time making VLAN work, rather embrace zero trust networking: Just make sure all your devices are secured by default (no anonymous logins, safe passwords, encrypted communication etc.). Consider your network Internet. It’s quite freeing 😄

If you have legacy stuff or stuff you can’t secure that way, you can still use a VLAN to move that particular device off of your main LAN.

The problem with that is that there are no IoT devices that are secure. The biggest security risk on a network are the IoT devices that you have no control of. Especially the ones that contact anything in the cloud. Look at Eufy, Ring, etc.

The only reason my iot devices can communicate with anything on my network is so that I can cast to them or otherwise control them like for instance the TV or sound bar etc. And in that case, I would prefer that they are not allowed to talk to anything else other than the specific hosts/ports that I want them to talk to. I also block them from calling home except for the hosts that absolutely stop them from working. The number one blocked DNS queries on my network are all tracking hosts at Microsoft, Amazon, Samsung etc.

In a perfect world, they wouldn’t talk to the cloud at all and have absolutely no internet access and only be allowed to speak to the specific hosts and ports that I want them to.

Unfortunately, that would require the manufacturers to give up all that add tracking money which they will never do. Or it would end up doubling, tripling or more the price of the devices.

Until then, I’ll use whatever means I need to to completely segregate them from anything and everything else on my network that I don’t need them to be able to talk to. And right now that’s usually either vlans or a whole lot of manual firewall rules. Any of my IoT devices that do not absolutely need internet are not even given a gateway when DHCP assigns them their address which is static. If there’s an update that’s needed and no way for me to push it to the device locally I allow an exception to the specific host that they need to talk to for the update and only for the amount of time it takes for them to update.

I also segment all mobile devices like cell phones and tablets etc to their own VLAN that cannot communicate to any of the other devices or vlans unless specifically allowed via rules. I don’t need one of the kids phones able to see all of the devices or possibly control them. That includes casting to them without my knowledge and subsequently rules to allow it.

Any five-year-old can download a script off the internet and totally own 90% of people’s networks because they just put stuff on them and have no idea about it and rely on the manufacturer to actually secure them, update them, patch vulnerabilities etc. When the majority of hardware released is lucky if it’s supported for a few years when people end up using it for much longer. There comes a point when it’s completely called for to sacrifice ease of use for security. Especially for those people that have no idea. Which is the majority of the world unfortunately. I’m sure everybody knows friends or family that are still running Windows 7 and postponing updates because they don’t want to be bothered with reboots etc. That’s all it takes to have all of your personal information, finance information etc stolen. And when that happens it’s the fault of the administrator or person in charge of the network who just relied on the manufacturer and trusted that they would do what they needed to do.

Just putting a device on your network and allowing it to do whatever it wants is almost as bad as just posting your configs and passwords on the internet.

Had the same issue with a pfsense router. I initially suspected a problem with my second LAN interface, but simply disabling “Enable reflection - Repeat mdns packets across subnets” in the avahi-package solved the problem.

Thanks!

OK, I have disabled multicast DNS on my UDM pro and that error has stopped right away. I am actually using https://hub.docker.com/r/scyto/multicast-relay so I should have disabled multicast DNS before. That does not explain why it was working with HassOS 5.11 though. I will reopen if that error comes back again. Thank you