I have an nmap device tracker set-up to monitor the state of a TV. The TV is on a different vlan from hassio and nmap doesn’t find it, here’s the log:
2021-08-19 20:33:24 DEBUG (SyncWorker_9) [homeassistant.components.nmap_tracker.device_tracker] Scanner initialized
2021-08-19 20:33:24 DEBUG (SyncWorker_8) [homeassistant.components.nmap_tracker.device_tracker] Scanning
2021-08-19 20:33:29 INFO (SyncWorker_8) [homeassistant.components.nmap_tracker.device_tracker] No MAC address found for 192.168.20.57
As soon as I move hassio on the same vlan nmap works again.
I have a pfSense instance running my network. The LAN network of hassio has full access to the vlan of the TV and nmap finds the TV from other devices on this same LAN.
I don’t think nmap will be of much use, either, then, especially cross-vlan.
If you known of an open port on the TV, you might try a command_line binary sensor, with nc (netcat)
It does work on the same vlan and according to the documentation here
it should work across vlans / subnets too.
So the question is whether anyone else is using it across vlans / subnets on the latest version of HassIO and if it does work, whether I am missing something…
I have not explicitly defined routes, but there are allow rules on the LAN in pfSense and as I said, a MacBook in the same LAN can scan the TV successfully.
I also see successful active MQTT connections from hassio to the TV in pfSense so it’s definitely some issue with Nmap
So in the meantime I have more evidence that the current nmap implementation is not working as described in the official documentation and cannot scan across vlans.
If I login with SSH and install nmap, I can scan the target host:
~ $ apk add nmap
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/aarch64/APKINDEX.tar.gz
(1/3) Installing libpcap (1.10.0-r0)
(2/3) Installing libssh2 (1.9.0-r1)
(3/3) Installing nmap (7.91-r0)
Executing busybox-1.32.1-r6.trigger
OK: 105 MiB in 101 packages
~ $ nmap 192.168.20.57
Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-23 20:32 CEST
Nmap scan report for 192.168.20.57
Host is up (0.0045s latency).
All 1000 scanned ports on 192.168.20.57 are closed
Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds
I still cannot do so from within Home Assistant however, as I continue to get the same error:
2021-08-23 20:31:26 DEBUG (SyncWorker_8) [homeassistant.components.nmap_tracker.device_tracker] Scanning
2021-08-23 20:31:29 INFO (SyncWorker_8) [homeassistant.components.nmap_tracker.device_tracker] No MAC address found for 192.168.20.57
I found a few other posts on the subject, some dating from all the way back in 2017… Is this something that can and will be fixed? At least the documentation should be updated…
Interestingly i’ve got the same issue, got pfsense-unifi setup. HA is able to reach/ping IP’s on other vlans but nmap is unable to scan anything on the other subnets
If you Google around you’ll see a very similar but was reported already in 2019 or 2020 but the thread was closed due to inactivity. It seems there’s little interest in solving this issue
Maybe too few people have this use case? I’d expect quite a few HA users to have VLANS but apparently that’s not the case…
The root cause is that the nmap integration is a device_tracker, and a device_tracker uses the mac address as its key.
The mac address is normally obtained from the ARP cache, which is only available for the devices on the same subnet(s) as your HA, in this instance.
I see 2 options:
Tweak the nmap options so that it can return the mac address from a different vlan, somehow (no clue if possible)
As you’re only concerned with the up/down state, really, rather than using the integration, use a shell_command binary sensor that runs nmap and grep, e.g., Host is up
OK, that makes sense. I’ll try the shell_command workaround.
The documentation for the nmap device tracker has to be updated though - it’s misleading and frustrating this way. It does not work across subnets and VLANs…
Best course of action would likely be to first open an issue on the nmap integration to get confirmation it cannot be done.
If confirmed, then update the doc.
I know it doesn’t help, but “Me too!”. Would be good if the NMAP integration would allow you to specify IPs and MAC address (or combinations) in the configuration. Mine was working fine when specified in the YAML, but broke once the integration became native…
I took a look at the code, implementation is flawed as it is requiring a MAC address for the destination. MAC addresses are only used when talking to a device on the same LAN, otherwise the packets are sent to the MAC address of the gateway. ARP will not resolve an ip on a different WAN.
