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)

Most upvoted comments

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.

Logger: getmac
Source: /usr/local/lib/python3.10/site-packages/getmac/getmac.py:1615
First occurred: 15:33:31 (4 occurrences)
Last logged: 15:33:43

Forcing method 'ArpFile' to be used for 'ip4' lookup (arg: '192.168.8.162')
Forcing method 'ArpFile' to be used for 'ip4' lookup (arg: '192.168.8.1')
Forcing method 'ArpFile' to be used for 'ip4' lookup (arg: '192.168.8.121')