Closed charraeus closed 2 years ago
Added a log of DNS in the logs section in post #1
edit: removed the DNS-log again because it is not related to the bug.
Not aware of such hostname issues. Do you have access to the OS shell (e.g. via USB keyboard/monitor connected to your Pi running HAOS?) If so, you can check the hostname using hostnamectl
. Maybe the NetworkManager logs contain hints: journalctl -b 0 -u NetworkManager
hostnamectl result:
# hostnamectl
Static hostname: smarthome
Icon name: computer-embedded
Chassis: embedded
Deployment: production
Machine ID: 03026ff02ca84fd08cb80a45f1d0a33d
Boot ID: 828a541bd51a4b40acd4ce2fb4284907
Operating System: Home Assistant OS 7.0
CPE OS Name: cpe:2.3:o:home-assistant:haos:7.0:*:production:*:*:*:rpi3-64:*
Kernel: Linux 5.10.63-v8
Architecture: arm64
The NetworkManager logs do not contain any hints. So I shut down the machine completely and restarted it at 16:00:00. Within the first approx. 5 minutes the hostname changed from "smarthome" to "265a4a7c22df48da84278374023ff59b". I had a look in the complete log and saw in line 1991 that the hostnamed-serivce is finally deactivated after approx. 3 minutes:
Dec 15 16:03:41 smarthome systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Find enclosed the complete log. If you make a search for "hostname" you will see that the "systemd-hostnamed.service" is started and stopped several times and remains finally deactivated.
The hostnamectl
- and nmcli general hostname
nevertheless show "smarthome" as hostname. Very weird...
Dec 15 16:03:41 smarthome systemd[1]: systemd-hostnamed.service: Deactivated successfully.
This is the expected behavior. The systemd service is only really required to change or request the hostname and shuts itself down if not required to safe memory.
Not sure what is going on, I don't think that this is something triggered by HAOS. To be sure, you could sniff traffic using Wireshark and filtering for DHCP packets. It's a bit a hack, but the Home Assistant Core container has full access to the network, so you can do:
docker exec -it homeassistant /bin/bash
bash-5.1# apk add tshark
bash-5.1# tshark -i eth0 dhcp
Unfortunately I have absolutely no experience with Wireshark. I've tried your command and got an error message:
bash-5.1# tshark -i eth0 dhcp
Capturing on 'eth0'
tshark: Invalid capture filter "dhcp" for interface 'eth0'.
That string looks like a valid display filter; however, it isn't a valid
capture filter (can't parse filter expression: syntax error).
Note that display filters and capture filters don't have the same syntax,
so you can't use most display filter expressions as capture filters.
See the User's Guide for a description of the capture filter syntax.
0 packets captured
bash-5.1#
I've tried a fresh install on a fresh sd-card without changing anything but creating the initial admin-user. The problem still occurs. Then I've tried a standard installation of Raspberry Pi OS (32bit, no desktop environment) without any changes. The issue does not occur.
Hm, not sure what went wrong with the filter, but this one should work:
bash-5.1# tshark -i eth0 -f "port 67 or port 68"
The filter worked. But there were no packets caught.
That is weird. That suggests the new hostname is not caused/sent from HAOS, but "generated" for some reason by the router, or maybe by another device (IP address conflict?)
I've tried a standard installation of Raspberry Pi OS (32bit, no desktop environment) with the same static IP (192.168.1.16) and hostname (smarthome). The issue does not occur. In the router only "smarthome" is shown, no weird name.
Another weird behavior with the HAOS: pinging without domain fails, but with ".local" as domain it succeeds, despite the HA-Host is shown as "" in the router. See below. I added the ping result of another host, called "magicmirror1" where the issue does not occur. For me, it is like HAOS does not recognize, the domain is "fritz.box". Maybe an issue in the NetManager configuration?
My network configuration:
~ % ping smarthome
PING smarthome.fritz.box (192.168.1.185): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- smarthome.fritz.box ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
~ % ping smarthome.local
PING smarthome.local (192.168.1.16): 56 data bytes
64 bytes from 192.168.1.16: icmp_seq=0 ttl=64 time=2.778 ms
64 bytes from 192.168.1.16: icmp_seq=1 ttl=64 time=1.403 ms
^C
--- smarthome.local ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.364/1.670/2.778/0.554 ms
~ % ping magicmirror1
PING magicmirror1.fritz.box (192.168.1.15): 56 data bytes
64 bytes from 192.168.1.15: icmp_seq=0 ttl=64 time=0.996 ms
64 bytes from 192.168.1.15: icmp_seq=1 ttl=64 time=1.174 ms
^C
--- magicmirror1.fritz.box ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.996/1.171/1.342/0.141 ms
~ %
There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Describe the issue you are experiencing
From time to time in the network my HA-hostname, defined in the web-gui as "smarthome" is replaced by a weird name like "265a4a7c22df48da84278374023ff59b". In the gui the originally defined hostname "smarthome" is shown. But if you look in the gui of my internet router you find the weird name with the ip of my machine.
See 2 screenshots of my router with the machine information of the home assistant machine in topic "additional information".
What operating system image do you use?
rpi3-64 (Raspberry Pi 3 64-bit OS)
What version of Home Assistant Operating System is installed?
7.0
Did you upgrade the Operating System.
Yes
Steps to reproduce the issue
My network environment:
Anything in the Supervisor logs that might be useful for us?
Anything in the Host logs that might be useful for us?
And Many lines like this:
System Health information
System Health
Home 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 7.0 -- | -- update_channel | stable supervisor_version | supervisor-2021.12.1 docker_version | 20.10.9 disk_total | 27.7 GB disk_used | 3.9 GB healthy | true supported | true board | rpi3-64 supervisor_api | ok version_api | ok installed_addons | File editor (5.3.3), Mosquitto broker (6.0.1), Zigbee2mqtt (1.22.1-1), Samba share (9.5.1), Terminal & SSH (9.2.1), Glances (0.14.0)Lovelace
dashboards | 2 -- | -- resources | 0 views | 1 mode | storageAdditional information