Arping Related Network Binding Issue

I feel like I need to apologize at the beginning of all my posts…

I seem to have caused a bit of an issue in my setup. I was attempting to setup phone based presence on my system and performed the following steps to use arping per other threads and documentation:

  1. Ran: sudo apt-get install iputils-arping

I tried running without the sudo, as most instructions said, but I received an unable to lock file and unable to lock admin dir error. This appeared to install the package successfully, and removed libc-ares2 automatically..

  1. Changed arping path to /usr/sbin/arping

I also just tried living it ‘arping’
_
3. Attempted to run chmod u+s /usr/sbin/arping , but received no file or dir found error

Now, the Network binding is not finding any things when I search, so it would appear that I messed something up.

Here’s what I get when I check version

[14:23:23] openhabian@openHABianPi:~$ arping -Vn
arping utility, iputils-s20121221

Here is a ping attempt:

[14:25:01] openhabian@openHABianPi:~$ arping -I eth0 -c 2 192.168.0.10
ARPING 192.168.0.10 from 192.168.0.4 eth0
Unicast reply from 192.168.0.10 [D0:13:FD:45:E3:83]  62.620ms
Sent 2 probes (2 broadcast(s))
Received 1 response(s)

Here is the properties of an added thing:

|ses_dhcp_listen|no|
|dhcp_state|No access right for port 67. Bound to port 6767 instead. Port forwarding necessary!|
|presence_detection_type|ICMP_PING|
|arp_state|Disabled|
|uses_ios_wakeup|On|
|icmp_state|IPUTILS_LINUX_PING|
|uses_arp_pings|no|

I haven’t manually added the config file, as I read somewhere the binding will use configurations made through PaperUI. This was all for not, because my android device still does not respond to arping after being locked for a few minutes, so that’s disappointing… It seems related, but now when I do a Thing search for the Network Binding, it does show results, but then won’t again unless the unit is restarted. coincidence?

If someone could offer some guidance as of how to what I did wrong to perform these arpings, I would be most appreciative. Thanks!

I wouldn’t use the network binding for anything, its too unreliable and its not updated by anyone as far as I can tell :frowning: I raised an issue on it ages ago with no reply so I can only assume the developers have moved on

1 Like

I have posted other ways for phone detection:

  1. tasker and sending ON/OFF to myopenhab (tasker and openhab cloud connector are required)
  2. using SNMP and querying your network equipment (requires network equipment that runs SNMP server and has supported MIBs).

Thank you so much for the guidance. I saw the chatter about the ‘Tasker’ option, so I suppose I’ll look into it further. We also use Life360, and I see that someone has put together a solution based on that too. I hoped this would be simple enough, but guess not.

That’s just untrue. I’m happily using it and a number of others do as well.
Please don’t turn your personal experience into a general judgement that makes others refrain from trying to use it. It’s clearly preferred to use bindings instead of external tools such as tasker or IFTTT.
The OP’s problem also isn’t lack of reliability - it just doesn’t work for him at all, likely because of a setup error.

So arping isn’t located where it should be which is probably the reason of your problems.

Find out where it is and use that full path in your OH binding config:

[12:00:14] openhabian@openhabianpi:~$ which arping
/usr/sbin/arping
[12:06:24] openhabian@openhabianpi:~$

In that case the $PATH variable of the environment of the UNIX user that OH runs as will be used to find arping’s location.
BUT OH usually runs as user openhab, so those command outputs you show are irrelevant as they’re run as openhabian which is a different user, to have a different environment.

[I may be wrong in gussing here but you failed to explain the type of system and OS you’re running on]

2 Likes

Same here, network binding is working without any issues.

Same here also, without problems. The only issue that I have found is if you use a node name instead hard coded IP address and the name can’t be resolved by dns, the bind will not work and you will get an error message.

Did you solve your problem?

Today, for the first time, I setup the network-binding by textual configuration and it is working so far.
I followed the instructions of the documentation, installed iputils-arping and didn’t have to change path or chmod.
It runs without sudo.

My setup is:

Platform: Raspberry Pi 3 Model B Rev 1.2
    openHABian configuration [master]v1.4.1-411(ecf59c4)
    OS: Raspbian GNU/Linux 9 (stretch)
    [08:15:23] openhabian@openHABianPi:~$ java -version
    openjdk version “1.8.0_152”
    OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
    OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
    openHAB 2.3.0-1 (Release Build)

Yes, Thank you all! The “which arping” command helped me find the path. it was installed in /usr/bin/arping, so it was missing the ‘s’ before bin…

But, even when getting it working, my phone I had several weeks ago (LGV20) would still not respond to ARPing in its ‘deep sleep’. I’ve since bought the Pixel3, and it, along with my wife’s Pixel2, both respond to regular ping and ARPing very reliably at all times. This presence configuration has been working very well for me these past couple of weeks. Thanks all!

1 Like

Thank you very much, This has helped me to make my first Thing and Items.

Waking up this thread…

Arping fails to return a response to the binding when a device is offline. The result is that a device that is offline is reported as online.

The underlying issue can be duplicated by adding a Thing (network pingable device) that is currently offline. Then, SSH into the openhab server (I am running openhabian) and run arping for that ip address.

/usr/bin/arping 192.168.1.6
ARPING 192.168.1.6 from 192.168.1.13 eth0

In the above example, the arping command generates an initial response showing the ip address polled (6) ran from the ip location of the openhab server (13) but does not complete the command. It freezes. When you kill the process, it then reports the number of probe attempts made (up to the time the process was killed):

Sent 26 probes (26 broadcast(s))
Received 0 response(s)

How can you force arping to limit the number of probe attempts, so it can return the result (device is offline) to the binding and Thing? By running the same command, but adding the -w flag and a small number. Now it will not freeze at the command line. From the arping man page:

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

So, how do you configure the binding so it processes the equivalent of:

usr/bin/arping -w 3 192.168.1.6
ARPING 192.168.1.6 from 192.168.1.13 eth0
Sent 4 probes (4 broadcast(s))
Received 0 response(s)

1 Like

This closed issue describes how the binding manages ARPING

1 Like

Thanks rossko57. Here is a link with step by step that fixed the arping issue for me, all within paper ui.

I think arping was not working because I created the items directly in the items section of Paper UI. This was not creating a functional channel. Instead, delete any existing items, then recreate them, this time from “inside the Thing”. This article has the specific steps and is explained very clearly. Highly recommended if you are a beginner like me and are having any presence issues with the network binding.

How to Implement Presence Detection With OpenHab

I also get “Disabled” in arp_state of the thing property.
I noticed that I have to issue “-I” option to the arping when running from command line.
Without it arping fails.
I suspect that the problem with arp_state disabled is with this interface specification option ("-I " flag).
Can it be the problem?

Can I also specify arping flags in arpPingToolPath config property? e.g. “/usr/bin/arping -I eth0”.

I have also the arp_state DISABLED, TRACE log however shows it’s working.

Hello all,

I ran into a similar situation. I’m running the whole story in a docker environment.

The system says: arp_state Disabled
How / Where can I see if the arping is done or not? (Which logfile)?

Binding is set to:

ARP Ping Tool Path   arping

I’Ve also tried

ARP Ping Tool Path   /usr/sbin/arping

Here is my configuration.

UID: network:pingdevice:d4c8dfdb46
label: Iphone FJS Pingable Network Device
thingTypeUID: network:pingdevice
configuration:
  hostname: FJSiPhone
  macAddress: 82:9D:07:XX:XX:XX
  refreshInterval: 60000
  retry: 2
  timeout: 5000

And the environment looks like this

pi@raspi:~ $ sudo docker exec -it openhab3_openhab_1 bash
root@raspi:/openhab# which arping
/usr/sbin/arping
root@raspi:/openhab# arping
ARPing 2.19, by Thomas Habets <thomas@habets.se>
usage: arping [ -0aAbdDeFpPqrRuUv ] [ -w <sec> ] [ -W <sec> ] [ -S <host/ip> ]
              [ -T <host/ip ] [ -s <MAC> ] [ -t <MAC> ] [ -c <count> ]
              [ -C <count> ] [ -i <interface> ] [ -m <type> ] [ -g <group> ]
              [ -V <vlan> ] [ -Q <priority> ] <host/ip/MAC | -B>
For complete usage info, use --help or check the manpage.
root@raspi:/openhab# arping -i eth0 -t 82:9D:07:XX:XX.XX FJSiPhone
ARPING 192.168.3.26
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=0 time=446.565 msec
Timeout
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=1 time=390.437 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=2 time=390.620 msec
Timeout
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=3 time=335.061 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=4 time=335.194 msec
Timeout
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=5 time=280.959 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=6 time=281.219 msec
Timeout
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=7 time=226.176 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=8 time=226.262 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=9 time=904.361 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=10 time=5.991 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=11 time=90.103 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=12 time=59.309 msec
60 bytes from 82:9d:07:XX:XX.XX (192.168.3.26): index=13 time=46.578 msec
^C
--- 192.168.3.26 statistics ---
14 packets transmitted, 14 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 5.991/287.060/904.361/218.355 ms

And finally here the log, did i misunderstood something here?
It looks like he’s doing ARP pings for every network and then doing a Java Ping?
Is this really necessary?

2021-11-03 11:31:02.594 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth128711e
2021-11-03 11:31:02.596 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth132adc8
2021-11-03 11:31:02.596 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth42e8be9
2021-11-03 11:31:02.598 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: vethf152500
2021-11-03 11:31:02.599 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth62ef3cf
2021-11-03 11:31:02.599 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: eth0
2021-11-03 11:31:02.602 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: be-openhab3
2021-11-03 11:31:02.601 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: app-openhab3
2021-11-03 11:31:02.605 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: vethf44c59c
2021-11-03 11:31:02.609 [TRACE] [g.network.internal.PresenceDetection] - Perform java ping presence detection for 192.168.3.26
2021-11-03 11:31:02.608 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: docker0
2021-11-03 11:31:02.844 [DEBUG] [g.network.internal.PresenceDetection] - Getting latency from ping result PingResult{success=true, responseTimeInMS=null, executionTimeInMS=234.0} using latency mode false
2021-11-03 11:31:04.102 [DEBUG] [g.network.internal.PresenceDetection] - Getting latency from ping result PingResult{success=true, responseTimeInMS=null, executionTimeInMS=1448.0} using latency mode false

I would suggest to open an Issue in Github for the case that arp is executed but not shown.
Any Inputs welcome

/Franz

Hi all,

I’ve opened an issue for this:

I’ve got the same issue.

If there would be a change it would also suggest to allow the network card to be selected.

This is not sooo sufficient

nobody    6937  4415  0 08:59 ?        00:00:00 arping -w 5 -C 1 -i eth0 192.168.3.50
nobody    6938  4415  0 08:59 ?        00:00:00 arping -w 5 -C 1 -i vetha84c316 192.168.3.50
nobody    6939  4415  0 08:59 ?        00:00:00 arping -w 5 -C 1 -i vethc9f2443 192.168.3.50
nobody    6940  4415  0 08:59 ?        00:00:00 arping -w 5 -C 1 -i docker0 192.168.3.50
nobody    6941  4415  0 08:59 ?        00:00:00 arping -w 5 -C 1 -i veth9656efe 192.168.3.50

I thought the idea of ping was to try all available paths.