If you remember my first post about home automation I mentioned a desire to use some sort of presence detection as part of deciding when to turn the heat on. Home Assistant has a wide selection of presence detection modules available, but the easy ones didn’t seem like the right solutions. I don’t want something that has to run on my phone to say where I am, but using the phone as the proxy for presence seemed reasonable. It connects to the wifi when at home, so watching for that involves no overhead on the phone and should be reliable (as long as I haven’t let my phone run down). I run OpenWRT on my main house router and there are a number of solutions which work by scraping the web interface. openwrt_hass_devicetracker is a bit better but it watches the
hostapd logs and my wifi is actually handled by some UniFis.
So how to do it more efficiently? Learn how to watch for ARP requests via Netlink! That way I could have something sitting idle and only doing any work when it sees a new event, that could be small enough to run directly on the router. I could then tie it together with the Mosquitto client libraries and announce presence via MQTT, tying it into Home Assistant with the MQTT Device Tracker.
I’m going to go into a bit more detail about the Netlink side of things, because I found it hard to find simple documentation and ended up reading kernel source code to figure out what I wanted. If you’re not interested in that you can find my
mqtt-arp (I suck at naming simple things) tool locally or on GitHub. It ends up as an 8k binary for my MIPS based OpenWRT box and just needs fed a list of MAC addresses to watch for and details of the MQTT server. When it sees a device it cares about make an ARP request it reports the presence for that device as “home” (configurable), rate limiting it to at most once every 2 minutes. Once it hasn’t seen anything from the device for 10 minutes it declares the location to be unknown. I have found Samsung phones are a little prone to disconnecting from the wifi when not in use so you might need to lengthen the timeout if all you have are Samsung devices.
Home Assistant configuration is easy:
device_tracker: - platform: mqtt devices: noodles: 'location/by-mac/0C:11:22:33:44:55' helen: 'location/by-mac/4C:11:22:33:44:55'
On to the Netlink stuff…
Firstly, you can watch the netlink messages we’re interested in using
iproute2 - just run
ip monitor. Works as an unpriviledged user which is nice. This happens via an
AF_NETLINK routing socket (rtnetlink(7)):
int sock; sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
We then want to indicate we’re listening for neighbour events:
struct sockaddr_nl group_addr; bzero(&group_addr, sizeof(group_addr)); group_addr.nl_family = AF_NETLINK; group_addr.nl_pid = getpid(); group_addr.nl_groups = RTMGRP_NEIGH; bind(sock, (struct sockaddr *) &group_addr, sizeof(group_addr));
At this point we’re good to go and can wait for an event message:
received = recv(sock, buf, sizeof(buf), 0);
This will be a
struct nlmsghdr message and the
nlmsg_type field will provide details of what type. In particular I look for
RTM_NEWNEIGH, indicating a new neighbour has been seen. This is of type
struct ndmsg and immediately follows the
struct nlmsghdr in the received message. That has details of the address family type (IPv6 vs IPv4), the state and various flags (such as whether it’s
NUD_REACHABLE indicating presence). The only slightly tricky bit comes in working out the MAC address, which is one of potentially several
struct nlattr attributes which follow the
struct ndmsg. In particular I’m interested in an
NDA_LLADDR, in which case the attribute data is the MAC address. The
main_loop function in
mqtt-arp.c shows this - it’s fairly simple stuff, and works nicely. It was just figuring out the relationship between it all and the exact messages I cared about that took me a little time to track down.