Open sle118 opened 3 days ago
Following up on this: as expected, the change does not persist so before I looked at the logs this morning, the system-resolved service had a chance to try 55K times. Next I'm going to see if I can execute the command on boot somehow.
If this doesn't work, then... maybe it's time to roll out my own supervisor.
I ended up creating a custom add-on for this. It monitors the primary interface at regular (configurable interval) and if mdns is not "resolve" on the primary (configurable too) interface, then it changes mdns automatically. If anyone is interested, I'm willing to share but at least for now this will do the trick.
Describe the issue you are experiencing
The default NetworkManager configuration sets mDNS to
yes
which, in network having multiple vlans and a reflector (e.g. on a Unifi network), result in a flood of mDNS requests originating from the supervisor's systemd-resolved. I believe the network configuration originates from this line: https://github.com/home-assistant/supervisor/blame/4e0de93096dc69c257056b36eff0c19b47006850/supervisor/dbus/network/setting/generate.py#L167Typical flooding would look like this
The issue was also reported under the operating system project, but got closed. Nevertheless, a long discussion continued after the issue got closed, with some hints on how to fix the issue. https://github.com/home-assistant/operating-system/issues/1163#issuecomment-1817014802
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
Steps to reproduce the issue
Anything in the Supervisor logs that might be useful for us?
System Health information
System Information
Home Assistant Community Store
GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok HACS Data | ok GitHub API Calls Remaining | 5000 Installed Version | 2.0.1 Stage | running Available Repositories | 1536 Downloaded Repositories | 9Home Assistant Cloud
logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 13.2 -- | -- update_channel | stable supervisor_version | supervisor-2024.11.2 agent_version | 1.6.0 docker_version | 27.2.0 disk_total | 205.1 GB disk_used | 52.1 GB healthy | true supported | true host_connectivity | true supervisor_connectivity | true ntp_synchronized | true virtualization | oracle board | ova supervisor_api | ok version_api | ok installed_addons | File editor (5.8.0), Terminal & SSH (9.15.0), Mosquitto broker (6.4.1), AppDaemon (0.16.7), SQLite Web (4.2.2), Z-Wave JS (0.9.0), ESPHome (2024.10.3), phpMyAdmin (0.10.0), rtl_433 MQTT Auto Discovery (0.8.2), Samba share (12.3.2), Z-Wave JS UI (3.17.0), MariaDB (2.7.1), Zigbee2MQTT (1.41.0-1), MQTT Explorer (browser-1.0.3), Node-RED (18.1.1), Studio Code Server (5.17.3), Frigate Proxy (1.5)Dashboards
dashboards | 3 -- | -- resources | 1 error | /config/ui-lovelace.yaml not found views | 20 mode | yamlRecorder
oldest_recorder_run | October 24, 2024 at 5:20 PM -- | -- current_recorder_run | November 19, 2024 at 9:47 AM estimated_db_size | 3032.83 MiB database_engine | mysql database_version | 10.11.6Spotify
api_endpoint_reachable | ok -- | --Supervisor diagnostics
config_entry-hassio-5dae251bf6ea118d92a240060ae3caf8.json
Additional information
In the meantime, I am trying the solution proposed in the following comment https://github.com/home-assistant/operating-system/issues/1163#issuecomment-1817014802
Which for me was as follow, while connected through ssh.
1- List all connections
2- Set mdns mode to resolve on the Supervisor connection
> nmcli connection modify "Supervisor enp0s3" connection.mdns resolve
3- Restart Network Manager
> systemctl restart NetworkManager.service
4- Confirm it works
I am wondering if this is something that could be exposed to the UI, or if someone has a better solution?