ARP scanning - should I create a new binding or add to the Network binding?

I plan on using ARP searches for Presence detection. The Network Health binding depends on devices already connected to the local network. On the other hand, all approaches with ARP scanning depend on some kind of shell scripts which push their information into OH2 via HTTP.

So, I want to put the ARP scanning in a proper OH2 binding. I think that having a dedicated binding to this would be the best way to go but also want to check the community opinion whether integrating this functionality with the Network Health binding would be a good way to go.

1 Like

Hello Hakan,
to implement ARP scanning is a great idea and I would love to see that to assist in presence detection. Could you elaborate on why you think a dedicated binding would be beneficial? Which use cases would you be interested in?

If presence detection is your goal, wouldn’t it be a better idea to include the arp scanning as an additional/alternative step in the network binding? One interesting use case is the one for combined iPhone detection. The binding already supports pinging on any port and listening for DHCP request messages. This could be extended by listening for ARP broadcast traffic and combined methods would then be able to detect devices by either IP or MAC.

I believe one binding will 1) be able to execute combined routines like the one proposed for iPhone detection and 2) will be more likely to be maintained than two. Example: If you were to extend the Network binding, you could also look into the improvement discussed here.

I did read the wiki page of the “Network Health” binding of OH1. I had the impression that it is only concerned with connections to already paired devices. Meaning, if I have configured a device to be in my WLAN, then I could detect whether that device is still connected or out of range.

Now that you have pointed me to the “Network” binding of OH2, I think that extending that one might be the more logical step to take.

I think pcap4j would be a good library to use, but am not sure whether the MIT license is good for openHAB. Do you have any opinion on this?

Sounds interesting. I’ve got a few questions and comments. By “ARP scanning” do you mean sending ARP requests for all subnet IP addresses (or maybe for ones that aren’t already resolved) and monitoring responses? I wasn’t sure since there was mention of monitoring ARP broadcasts. I think there might be an issue with that approach since only ARP requests are broadcast. The responses are unicast. Also, ARP requests can’t be sent by Java without some type of native library support (I’ve heard that jpcap and pcap4j supports it). Depending on the latency/accuracy requirements, you might also need to flush the ARP cache before the scan for quick detection of a device leaving the network.

[Sorry, Hakan. I hadn’t seen your comments before I posted mine (apparently I needed to refresh my browser).]

Yep, I am thinking about scanning the network periodically. This could then be enhanced with Bluetooth scanning as well.

All those little shell scripts I saw also run “arp -n” and parse the result. My intention is to abstract this OS-specific shell scripting part. And use pcap4j for this. I believe we already have a binding that distributes native libraries.

Yes, there are several. Based on the pcap4j documentation, it appears that external libraries need to be installed on the host machine (libpcap or winpcap). I’m also assuming that elevated privileges (e.g., root on Linux) is required to put the NIC into promiscuous mode.

The Network binding has one feature “dhcplisten” that already needs special permissions. I don’t know how this is implemented and if that’s sufficient for arp scanning.

@hakan again, could you clarify which use cases you see for the arp scan? How would IP ping, DHCP listening and arp scanning cooperate?

I am about to set up an openHAB instance for our FabLab, in which I want to have a “Someone is present” signal which could then be visualized on the Lab web pages. Visualization is a second step for which maybe MQTT could be a good fit.

As I cannot assume that all devices would have a well-known IP address, I would scan for MAC addresses and “detect” all devices which are connected at a given time to the network.

O.k., now that I think more about this, I believe dhcplisten might even be enough for my purposes… I guess I will have to set my system up for dhcplisten and see what happens. The binding documentation mentions broadcasts on leaving the network but I am not sure how orphaned entries would be handled… Maybe with some use of the expire binding?

In any case, I will come back to this thread and report how things turned out.

Maybe I can shed a light on the DHCP request topic:

$ grep ReceiveDHCP /var/log/openhab2/openhab.log

2016-12-13 01:31:13.164 [INFO ] [rvice.dhcp.ReceiveDHCPRequestPackets] - DHCP request for unknown address:
2016-12-13 01:40:02.980 [INFO ] [rvice.dhcp.ReceiveDHCPRequestPackets] - DHCP request for registered address:
2016-12-13 01:40:18.187 [INFO ] [rvice.dhcp.ReceiveDHCPRequestPackets] - DHCP request for unknown address:
2016-12-13 01:46:19.389 [INFO ] [rvice.dhcp.ReceiveDHCPRequestPackets] - DHCP request packet listener online
2016-12-13 01:51:15.510 [INFO ] [rvice.dhcp.ReceiveDHCPRequestPackets] - DHCP request for unknown address:
2016-12-13 08:02:49.792 [INFO ] [rvice.dhcp.ReceiveDHCPRequestPackets] - DHCP request for registered address:

What are the typical use cases for dhcplisten? For manually configured network things, you need to specify the IP address of the device in the thing declaration, right? Since the default DHCP behavior is to assign the address, it seems you’d need to override that behavior with a static
address lease.

Using this feature with dynamic discovery could be interesting, but I’m not sure how useful it would be since there’d be no information about the type of device (without some type of device fingerprinting support).

Assuming all known LAN devices have static DHCP leases and defined things, the “DHCP request for unknown address” event would be interesting from a network security perspective. However, that event appears to only be logged and not propagated from the binding.

One thing I like about ARP scanning approach is that it could detect devices that are trying to hide on the network (they have disabled ping and all UDP/TCP ports, for example). A stealthy device like this could also avoid DHCP requests by assigning itself an IP address that is not likely to be used on the LAN. Again, this is a network security use case rather than the normal device discovery and health monitoring scenarios.

My use case is less the “Someone is trying to hack my network” and more the “I have 300 Lab members for which I really don’t want to set up fixed addresses in my DHCP setup”.

The use cases I can imagine for my FabLab and / or Home setups are:

  • Some fixed infrastructure with “known” MAC and possibly IP gets switched on: Perhaps our Laser printing PC, perhaps one of the Raspberries monitoring the 3D printers -> I know that something is alive in the Lab but perhaps no one human presence
  • Some mobile phone with “known” MAC is visible in the network -> Either someone forgot his/her mobile in the Lab or someone came in. No guarantees, but safe to assume that a human might be in the Lab
  • An “unknown” MAC is present -> Either a guest or a new member is in the Lab. Or new fixed hardware. In any case, put the MAC into some kind of list and see if we have a new member who wants his/her presence to be recognized.

After I have this presence information, all kinds of actors would come to mind, from switching on lights to kicking off actions on the newest IoT hardware we are playing with…

Pushing the above list of detected MACs to an MQTT server would perhaps be interesting too.

The above setup would be simililar in my Home network. The only thing is, I would perhaps be a bit more paranoid if unknown devices manage to get a DHCP lease from my server :smiling_imp:

You should look at the Amazon Dash Button Binding as I think he implemented ARP scanning for MAC addresses that come from Dash buttons. It can show you how he pulled in and implemented the library connectivity. I think it also requires setting a security policy on Java so it can bind to low numbered ports.

I understand. I was describing why I would be interested in the ARP scanning.

If I am reading the documentation and source code correctly for the dhcplisten feature, you’ll need to know the IP address to monitor the device presence. If the thing is not already defined (which requires the IP address) then dhcplisten will either not be listening (if no existing network thing are requesting dhcplisten) or will only log the unknown IP address. AFAICT, dhcplisten is not used for device discovery and is only used for presence detection of known devices.

Ah right ^^ I knew I’ve heard “pcap4j” a few days ago. I’ve actually taken part in improving the document describing the whole process. Pcap4J is used by this project and setcap has to be used for the needed permissions (like with a few other bindings including the Network binding, this is now also explained in the common Linux article.

@hakan I believe this will answer a few of your questions.

The idea defined here sounds really good. @steve1 as you assumed correctly I’ve configured my devices to have a fixed IP assigned by the DHCP. It would be a huge improvement if the binding would be extended to identify a device based on it’s MAC. @hakan I’m not sure how your (unknown) discovered devices would be projected to things, channels and items. That’s something you might still need to think about. Do you still think the Network binding is a good starting point?

Just thinking off the top of my head but if you had a Thing type to represent higher level networking information and on that Thing a channel that gets updated with mac addresses which are not bound to IP addresses for which there are already Things defined. It would take a whole lot of book keeping in the binding but I don’t think it would be difficult.

Another idea would be to add autodiscovery and have it create Things for newly discovered IPs. But then we are faced with the challenge of getting those Inbox Things into Rules to deal with them so maybe this is a bad path to go down.

I can also see the binding doing autodiscovery anyway and then the user can accept those which belong to devices that are known.

It could make sense for the binding to support definition of Things based on MAC rather than IP, particularly if one adds the ability for the binding to discover which IP is assigned to that MAC on its own. We still need the IP though because pretty much all of the existing capabilities of the Network binding operate at the IP layer.

I do think this sort of thing is appropriate for a binding named Network, though it does run the risk of becoming a monster of a binding that does too much.

Actually, the more I think about it, the more I find ideas to go both ways…

I would have to extend the Network Things with an additional MAC attribute, and most of the IP layer functionality would be unavailable for “unknown” devices. So this is a minus.

Also, if and when the Bluetooth PR gets merged into ESH, I would love to extend this presence detection with Bluetooth. Also a minus.

On the other hand, it is the infrastructure for a network-based presence detection. So this is a plus for enhancing the Network binding…

Not sure, I guess I have to sleep on it a bit :smile:

My suggestion is to focus more on what you want this binding to do (i.e. scan ARP packets for unknown and unknown devices) and less about what you want to use it for (presence detection). I believe focusing too much on what you want to use it for might cause decisions that close the binding off to other potential uses.

In my mind, scanning for ARP belongs in a binding. Presence detection belongs in Rules.

The distinction is the binding shouldn’t be opinionated about what its data and capabilities are used for.

1 Like

I agree. Presence detection is a higher level capability that could use a combination of network device detection, GPS, BTLE beacons, RFID, heat/motion sensors or whatever.

Anyone still planing on working on a arp binding?

Not me at the moment. Totally swamped with $WORK.