Network presence detect and arping

Hmm…spoke too soon.

arping on the laptop does fail to receive a response occasionally if the arping timeout is set to 5 seconds. Doesn’t appear to fail if set to 10 seconds.

On the OH commandline, arping immediately reports timeout, doesn’t wait the specified time before timeout.

please check the firewall on the PI. I ping working?


I can ping anything on my net from the PI, including the phone (even in sleep, with really long lag times, 1 second)

You can use ping instead of arping. Maybe this will help.

Switching from ping to arping was (I thought) supposed to be the fix for presence of a sleeping phone because ping wouldn’t work to a sleeping device.

I’m really confused now since ping does appear to work, albeit with large response lags, to a sleeping device. :roll_eyes:

So, I noodled around the arping man page and see that the wait time when specified with the -w is in microseonds (I did a cut and past from an article, so…caveat emptor :wink: )

When I specified it with the -W (in seconds) the sleeping phone responds about 30% of the time.

I adjusted the wait, etc. in paperui but, see no change in the presence of the phone when sleeping. :frowning_face:

Ok, best I can tell OH has arping disabled. (The arp_state in the properties is Disabled. And uses_ios_wakeup is Yes. But, the device in question is an Android phone…guessing it knows nothing about ios wakeups. :roll_eyes: )

How can I enable it?

I adjusted the wait, etc. in paperui but, see no change in the presence of the phone when sleeping.

The network binding does not apply binding configurations without a service reload. The easiest way is an OH restart.

The next version will handle that differently.

The binding tries it’s best to use the installed arping. On windows there is one arping version that apparently does not work yet. But in general if you can call it from the command line, it should work from within openHAB as well (if you have given OH/java the correct permissions).

I’m on Openhabian.

As far as I can tell (watching my net with Wireshark) there is never an arp to the phone.

If I do an arping from the command line on the pi, it is seen in wireshark.

So, is it a permissions issue n the pi? What does OH need? (From the command line I use sudo, does OH need to have sudoer? Not sure that’s a great idea… :roll_eyes: )

Also, the properties on the thing are as shown here:

I don’t know how to change these properties.

Also, wireshark never sees any pings either as far as I can tell.

If you need sudo on the command line then of course openHAB needs elevated permissions. You have read the readme/doc have you?

After finding another thread:

That mentioned elevated permissions, as per the readme. I did the chmod and it appears to be working now.

Never had to change permissions in for other bindings in openhabian (that I can remember…but, I have a very bad memory :roll_eyes:), so was lazy. :relaxed:

Thanks for the help!

in my case it is not working either.
but from the host i can ping all device - but can’t find out how to use arping on the cli to scan the network.
arp-scan would fit better?

assuming arping is installed onthe command line type:

arping -W 10 -c 10 -I <your device> <ip of phone>

this will wait 10 seconds between arping’s and try 10 times.

If, this doesn’t work without sudo, then see the referenced thread for the appropriate chmod command and what it does.

assuming linux, find your device and ip from:


This works smart the w have just to be a small on

arping -w 10 -c 10 -I ens18
ARPING from ens18
Unicast reply from [E0:28:6D:84:05:31]  0.953ms
Unicast reply from [E0:28:6D:84:05:31]  0.882ms
Unicast reply from [E0:28:6D:84:05:31]  0.861ms
Unicast reply from [E0:28:6D:84:05:31]  0.884ms
Unicast reply from [E0:28:6D:84:05:31]  0.911ms
Unicast reply from [E0:28:6D:84:05:31]  0.911ms
Unicast reply from [E0:28:6D:84:05:31]  0.879ms
Unicast reply from [E0:28:6D:84:05:31]  0.848ms
Unicast reply from [E0:28:6D:84:05:31]  0.905ms
Unicast reply from [E0:28:6D:84:05:31]  0.869ms
Sent 10 probes (1 broadcast(s))
Received 10 response(s)

From the man pages on openhabian:

man arping
      To check the address of MAC-A, use knowledge of MAC-B and IP-B.

      $ arping -S <IP-B> -s <MAC-B> -p <MAC-A>

       other options...

       -w usec
              Time to wait between pings, in microseconds.

       -W sec Same as -w, but in floating point seconds.

Ubuntu man pages on the other hand don’t list a -W. Nor do the Linux man pages on the web.

So, -w is the standard and -W is maybe something added to the rasbian/debian/openhabian. :thinking:

on my Debian 9 VM - arping is running!
but why not out of openhab2 (v2.4)?

As @David_Graeff said, it should be in the documentation. So just make sure to read the docs next time to find out how to set things up for a binding :slight_smile:

The problem here (I guess) is that there are different versions of arping around with different capabilities. They come from different packages and thus it depends what your arping is capable of and that also changes the behaviour of the wait time parameter which can either just be a small w or case sensitive w and W. If I am not mistaken the meaning of the small w parameter also changes unfortunately. But that should not be important since the binding takes care of that normally.

As I noted, the elevated permissions seems to have fixed my issue. Maybe I’m referring to the documentation as the readme? :thinking:

I certainly agree about the RTFM comment. Even after a 45 year career as a software/hardware engineer, who’s made the same comment many times, I need to be reminded occasionally. :blush:

In this particular case trhough, I had read the documentation, but, I was focused on the bad behavior being the same as before the upgrade to version 2 of the binding and expected that some setting in the binding had not taken effect when the upgrade happened (and arping did work from the command line)…I brushed over the elevated privilege note.

Yes, this is apparently the case. especially between utilities that are available on windows and linux. Different or lacking arguments between OS’s are more prevalent with linux utilities implemented on windows (sometimes, windows just can’t do the same thing, or in some cases vice-versa). Not sure why this is the case between two debian derived distros…but, c’est la vie. :neutral_face:

Alright then. I also know that it can cause problems when suspecting some specific problem and that leading to focus on the wrong things.

You can even install different arping versions on the same system. It comes with different packages, so I guess one distro has the one as default and one distro uses the other.