iPhone Presence Detection with hping3 and ARP


Hi David, i still seem struggling to understand what changes i need to make in order to get the presence detection up and running again with the latest changes of the binding in the same way as it was before. With the “old” binding this worked perfectly well with my iphones. When they were entering the network, the status changed to ONLINE. Only when they left the network, the status went to OFFLINE. Now it seems that once the iphone gets into sleep mode, the status changes to OFFLINE with the last seen timestamp, even though the iphone is still within the network. This happens frequently over day of course and at night. This causes problems as i have based a couple of rules fired with the request if iphones are ONLINE or OFFLINE. I am wondering if this still is a bug, if this is the purpose or if i do need to change anything on the configuration to make it work again that only when the iphone is not in the Network, the status is OFFLINE.

Thing Status IIThing Status

Thanks. Jan


Hi David, i’m trying to use the new binding without the script file but it seams i’m missing something essential.

in paperui this is how my binding looks like:

thing looks like this:

arping can be used without sudo from terminal with the mentioned bath in the binding config.
from my understanding what i can see in paperUI of the Thing its not using arping at all.

regards, Matt


See my properties. Also for me it seems that arping is not used

@Matt77 You are using serviceDevice. Please read the description within the screenshot: …with running service… AND …which reachable state is detected by connecting to a TCP port."

arping will never be used for a serviceDevice. Use a pingDevice instead.

Oh, that “uses_arpping” property is not existing anymore actually. Ignore what it says. The other propery says that the thomas arping was recognised and will be used.


OK, so how could I know that the arping from the binding is working (as currently it seems not to work). Are there any logs I can enable that will help to debug it?

Do you suggest to move to iputils arping?

Can you get into the situation where nothing else then arping would work? Like a deep sleeping iphone/android?

It would be helpful if you could use the command line to try:

  • a normal ping (should fail)
  • an arp ping

The binding can only be as good as the tools it uses. There is unfortunately no further debug than what you see in the properties, but if it is listed there, you can be sure it is used, in parallel to everything else.

As stated already, I have only tested it with the iputils arping. iputils needs a network interface to work and I add this parameter to thomas arping as well. Might be that the program is confused because of that.

Cheers, David


See below results from command line to Alexa:

  [14:09:57] openhabian@openHABianPi:~$ ping
PING ( 56(84) bytes of data.
--- ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6247ms

[14:12:34] openhabian@openHABianPi:~$ arping
60 bytes from f0:xx:2d:xx:xx:01 ( index=0 time=136.525 msec
60 bytes from f0:xx:2d:xx:xx:01 ( index=1 time=55.504 msec
--- statistics ---
4 packets transmitted, 4 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 55.504/89.947/136.525/30.036 ms

Maybe I will switch to iputils apring and see if it behaves differently.

Process proc;
// IPutilsArping uses "-w", ThomasHabertArping "-W" for the timeout
String timeoutFlag = arpingTool == ArpPingUtilEnum.IPUTILS_ARPING ? "-w" : "-W";
proc = new ProcessBuilder(arpUtilPath, timeoutFlag, String.valueOf(timeoutInMS / 1000), "-c", "1", "-I", interfaceName, ipV4address).start();

is the code, the command line would be: arping -W 1000 -c 1 -I eth0 with eth0 being your network interface name. Can you try this as well?

[14:23:50] openhabian@openHABianPi:~$ arping -W 1000 -c 1 -I eth0
60 bytes from f0:27:2d:95:33:01 ( index=0 time=76.472 msec
60 bytes from f0:27:2d:95:33:01 ( index=1 time=15.526 sec
60 bytes from f0:27:2d:95:33:01 ( index=2 time=80.776 sec
60 bytes from f0:27:2d:95:33:01 ( index=3 time=145.786 sec

It should respond with 1 result actually (c=count=1). Can you change the “-W 1000” which means timeout after 1000 to 5000 and see if the program halts the command line for 5 seconds? Because that would be the problem then.

Maybe "-W"s unit is seconds instead of milliseconds.

According to http://www.manpagez.com/man/8/arping/
and this http://manpages.ubuntu.com/manpages/trusty/man8/arping.8.html

Thomas’ arping uses “-w” as well but uses seconds.
Older versions (ubuntu) do not support “-w” at all. Sigh.

with -W 1000 the command seems to halt. It takes time between two responses. But I don’t know why as -c i 1 ???

With -W 5000 seems to behave the same …

-c count
Stop after sending count ARP REQUEST packets. With deadline option, arping waits for count ARP REPLY packets, until the timeout expires.

-w deadline
Specify a timeout, in seconds, before arping exits regardless of how many packets have been sent or received. In this case arping does not stop after count packet are sent, it waits either for deadline expire or until count probes are answered.

You have one more other version of thomas arping. The other manuals say:


 -v     Verbose output. Use twice for more messages.
 -w     Time to wait between pings, in microseconds.

And found the reason:

It was fixed end of 2016. And some distros still have old packages I guess.

Fixed in

[14:47:28] openhabian@openHABianPi:~$ arping --version
arping: invalid option -- '-'
ARPing 2.14, by Thomas Habets <thomas@habets.se>
usage: arping [ -0aAbdDeFpPqrRuUv ] [ -w <us> ] [ -W <sec> ] [ -S <host/ip> ]
              [ -T <host/ip ] [ -s <MAC> ] [ -t <MAC> ] [ -c <count> ]
              [ -C <count> ] [ -i <interface> ] <host/ip/MAC | -B>
For complete usage info, use --help or check the manpage.
[14:47:32] openhabian@openHABianPi:~$

Yup, confirmed, you are a proud owner of an ancient, rotten, very old arping :smiley:
Check with “man arping”.

But your version will soon be supported as well with the PR.

Cheers, David


This is what I get from apt-get. Even after upgrade …

[14:52:46] openhabian@openHABianPi:~$ apt-get install --only-upgrade arping
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
[14:53:18] openhabian@openHABianPi:~$ sudo apt-get install --only-upgrade arping
Reading package lists... Done
Building dependency tree        
Reading state information... Done
arping is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
[14:53:25] openhabian@openHABianPi:~$ arping
ARPing 2.14, by Thomas Habets <thomas@habets.se>
usage: arping [ -0aAbdDeFpPqrRuUv ] [ -w <us> ] [ -W <sec> ] [ -S <host/ip> ]
              [ -T <host/ip ] [ -s <MAC> ] [ -t <MAC> ] [ -c <count> ]
              [ -C <count> ] [ -i <interface> ] <host/ip/MAC | -B>
For complete usage info, use --help or check the manpage.
[14:53:31] openhabian@openHABianPi:~$

You are using a debian distribution. It is normal that some packages are up to 3 years old. The supported version is 2.19, you are on 2.14.

not sure if this is relevant here, but with a Raspi PI and arping these are the uage options you get, no capital -W option which is rejected if you execute with it.

pi@raspberrypi:~ $ arping
Usage: arping [-fqbDUAV] [-c count] [-w timeout] [-I device] [-s source] destination
-f : quit on first reply
-q : be quiet
-b : keep broadcasting, don’t go unicast
-D : duplicate address detection mode
-U : Unsolicited ARP mode, update your neighbours
-A : ARP answer mode, update your neighbours
-V : print version and exit
-c count : how many packets to send
-w timeout : how long to wait for a reply
-I device : which ethernet device to use
-s source : source ip address
destination : ask for what ip address