core: nmap fails to obtain mac address in 2023.2.x
The problem
The nmap
integration is failing to detect devices in Home Assistant 2023.2.x
. I have tested all versions beyond 2023.1.7
and the issue is present.
I am running Home Assistant in a container with rootless podman. My compose file looks like this:
homeassistant:
image: homeassistant/home-assistant:2023.1.7 #stable
container_name: homeassistant
network_mode: host
privileged: true
restart: always
group_add:
- dialout
volumes:
- "/etc/localtime:/etc/localtime:ro"
- "./data/homeassistant:/config:z"
- "/run/user/1000/podman/podman.sock:/var/run/docker.sock:z"
And my nmap
configuration is as follows:
-F -T4 --min-rate 10 --host-timeout 5s --unprivileged
With a scan interval of 20
and 450
second wait until a device is home.
What version of Home Assistant Core has the issue?
2023.2.2
What was the last working version of Home Assistant Core?
2023.1.7
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Nmap Tracker
Link to integration documentation on our website
https://www.home-assistant.io/integrations/nmap_tracker/
Diagnostics information
The only nmap failure in the logs is:
2023-02-07 11:30:46.166 INFO (MainThread) [homeassistant.components.nmap_tracker] No MAC address found for 192.168.1.200
Example YAML snippet
No response
Anything in the logs that might be useful for us?
2023-02-07 10:58:52.975 INFO (MainThread) [homeassistant.components.nmap_tracker] No MAC address found for 192.168.1.200
New versions complain that the MAC address cannot be found.
On older versions, getting inside the container and running:
nmap 192.168.1.200 -F -T4 --min-rate 10 --host-timeout 5s --unprivileged --exclude 192.168.1.4 --reason -v
Gives me:
Starting Nmap 7.92 ( https://nmap.org ) at 2023-02-07 11:24 CET
Initiating Ping Scan at 11:24
Scanning 192.168.1.200 [2 ports]
Completed Ping Scan at 11:24, 0.23s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:24
Completed Parallel DNS resolution of 1 host. at 11:24, 0.00s elapsed
Initiating Connect Scan at 11:24
Scanning 192.168.1.200 [100 ports]
Completed Connect Scan at 11:24, 0.03s elapsed (100 total ports)
Nmap scan report for 192.168.1.200
Host is up, received conn-refused (0.0096s latency).
All 100 scanned ports on 192.168.1.200 are in ignored states.
Not shown: 100 closed tcp ports (conn-refused)
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds
On the newer version the result is:
Starting Nmap 7.92 ( https://nmap.org ) at 2023-02-07 11:29 CET
Initiating Ping Scan at 11:29
Scanning 192.168.1.200 [2 ports]
Completed Ping Scan at 11:29, 0.17s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:29
Completed Parallel DNS resolution of 1 host. at 11:29, 0.00s elapsed
Initiating Connect Scan at 11:29
Scanning 192.168.1.200 [100 ports]
Completed Connect Scan at 11:29, 0.03s elapsed (100 total ports)
Nmap scan report for 192.168.1.200
Host is up, received conn-refused (0.011s latency).
All 100 scanned ports on 192.168.1.200 are in ignored states.
Not shown: 100 closed tcp ports (conn-refused)
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
I don’t see any immediate difference here and given its the same version of nmap, it seems strange that something breaks.
Additional information
The only thing I can think of at this stage is that home assistant cannot be run rootless any longer, but I cannot see anything in recent change logs that may have impacted this.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 25 (6 by maintainers)
Confirming this is working again in
2023.6
- hopefully you all see the same results. If not, probably best to open a new issue anyway. Thanks to everyone who pitched in 🙇Thanks @scottsweb I have added your workaround/fix into a pull request for the kef integration which is also affected. It does work, however it generates warnings in the HA logs like below, and not just for one integration, for all integrations using getmac.
I’m thinking now should this fix go at HA level, possibly silencing this warning. It seems fixing this at a single integration, affects other integrations also.