[Network] ping causes udp port 5353 unreachable

[radoslavv]

Expected Behavior

Fix Network Binding - ping requests to not to cause udp port 5353 unreachable

Current Behavior

1. OpenHab2 ping generates unwanted udp port 5353 unreachable traffic (mDNS ping?) from pinged host (IoT):

12:09:11.409551 IP 192.168.1.222 > 192.168.1.234: ICMP echo request, id 9357, seq 1, length 64
                E..T..@.@...............$...W.._.?...	
                ..................... !"#$%&'()*+,-./01234567
12:09:11.439807 IP 192.168.1.234 > 192.168.1.222: ICMP 192.168.1.234 udp port 5353 unreachable, length 88
                E..l.U@.@..#................E...?[@.@.v].........`.....{..................&Fw..	f.....g`....2.....E..T..@.@.....
12:09:11.451843 IP 192.168.1.234 > 192.168.1.222: ICMP echo reply, id 9357, seq 1, length 64
                E..T.U@.@..;.......... .$...W.._.?...	
                ..................... !"#$%&'()*+,-./01234567

2. Linux ping is not causing this (IoT):

12:09:39.480623 IP 192.168.1.222 > 192.168.1.234: ICMP echo request, id 9677, seq 1, length 64
                E..T..@.@.............Qk%...s.._0U...	
                ..................... !"#$%&'()*+,-./01234567
12:09:39.518841 IP 192.168.1.234 > 192.168.1.222: ICMP echo reply, id 9677, seq 1, length 64
                E..T.U@.@..;..........Yk%...s.._0U...	
                ..................... !"#$%&'()*+,-./01234567
12:09:40.479605 IP 192.168.1.222 > 192.168.1.234: ICMP echo request, id 9677, seq 2, length 64
                E..T..@.@.............In%...t.._7Q...	
                ..................... !"#$%&'()*+,-./01234567
12:09:40.521104 IP 192.168.1.234 > 192.168.1.222: ICMP echo reply, id 9677, seq 2, length 64
                E..T.U@.@..;..........Qn%...t.._7Q...	
                ..................... !"#$%&'()*+,-./01234567
12:09:41.480075 IP 192.168.1.222 > 192.168.1.234: ICMP echo request, id 9677, seq 3, length 64
                E..T..@.@.............tk%...u.._.S...	
                ..................... !"#$%&'()*+,-./01234567
12:09:41.539050 IP 192.168.1.234 > 192.168.1.222: ICMP echo reply, id 9677, seq 3, length 64
                E..T.U@.@..;..........|k%...u.._.S...	
                ..................... !"#$%&'()*+,-./01234567 

Similar behavuiour for Linux Router with dd-wrt:

1. OpenHab2 ping generates unwanted udp port 5353 unreachable traffic (mDNS ping?) from pinged host (router):

13:25:04.883888 IP 192.168.1.1 > 192.168.1.222: ICMP 192.168.1.1 udp port 5353 unreachable, length 36
                E..8....@..............F....E....8@.@..h................
13:25:04.898432 IP 192.168.1.222 > 192.168.1.1: ICMP echo request, id 22962, seq 1, length 64
                E..T{C@.@.;6..........V.Y...  ._D....	
                ..................... !"#$%&'()*+,-./01234567
13:25:04.898704 IP 192.168.1.1 > 192.168.1.222: ICMP echo reply, id 22962, seq 1, length 64
                E..T....@.............^.Y...  ._D....	
                ..................... !"#$%&'()*+,-./01234567 

2. Linux ping is not causing this (router):

13:25:28.525977 IP 192.168.1.222 > 192.168.1.1: ICMP echo request, id 23203, seq 1, length 64
                E..T~.@.@.7........... .Z...8 ._f....	
                ..................... !"#$%&'()*+,-./01234567
13:25:28.526322 IP 192.168.1.1 > 192.168.1.222: ICMP echo reply, id 23203, seq 1, length 64
                E..T....@.............(.Z...8 ._f....	
                ..................... !"#$%&'()*+,-./01234567
13:25:29.527312 IP 192.168.1.222 > 192.168.1.1: ICMP echo request, id 23203, seq 2, length 64
                E..T.%@.@.7T............Z...9 ._.....	
                ..................... !"#$%&'()*+,-./01234567
13:25:29.548024 IP 192.168.1.1 > 192.168.1.222: ICMP echo reply, id 23203, seq 2, length 64
                E..T.5..@..D............Z...9 ._.....	
                ..................... !"#$%&'()*+,-./01234567
13:25:30.528424 IP 192.168.1.222 > 192.168.1.1: ICMP echo request, id 23203, seq 3, length 64
                E..T.z@.@.6.............Z...: ._.....	
                ..................... !"#$%&'()*+,-./01234567
13:25:30.529004 IP 192.168.1.1 > 192.168.1.222: ICMP echo reply, id 23203, seq 3, length 64
                E..T.q..@...............Z...: ._.....	
                ..................... !"#$%&'()*+,-./01234567 

Possible Solution

Set same ping request like Linux does.

Steps to Reproduce (for Bugs)

1. Configure parameters for the thing.
   Hostname or IP: 192.168.1.234 (use IP of other available network device)
   MAC Address:
   Refresh Interval: 10000 (ms)
   Retry: 1
   Timeout: 5000 (ms)
2. Capture data with command
   tcpdump --immediate-mode -ni eth0 icmp and host 192.168.1.222 and host 192.168.1.234 -A |tee /tmp/tshark2.log

Context

• generates unneccessary network traffic / mess (unnecessary udp port 5353 unreachable answers from pinged host)
• small IoT devices (like PIC18F67j60 microcontrollers) with low CPU resources are "spammed" with meaningless requests

Your Environment

• Version used: OpenHab 2.5.11-1, AddOns 2.5.11-1
• Environment name and version (e.g. Chrome 76, Java 8, Node.js 12.9, ...): java-common v.0.71
• Operating System and version (desktop or mobile, Windows 10, Raspbian Buster, ...): RPi4, 4GB RAM, IP 192.168.1.222

[ptrooms]

FWIW, this is defaulted into the bundle as it assumes that all devices are IOS which uses a different approach for detecting their (deep)sleeping state.
The bundle states:

        // It does not harm to send an additional UDP packet to a device,
        // therefore we assume all ping devices are iOS devices. If this
        // does not work for all users for some obscure reason, we can make
        // this a thing configuration variable.

Well it DOES harm as my IoT device went nuts by this frequent UDP/ICMP/MDNS flooding op port 5353.

Making it a configuration variable has not been done in R2xx.
In my case, as I do not use any IOS. I simply default the IOS scan to false: presenceDetection.setIOSDevice(false);

[lsiepel]

FWIW, this is defaulted into the bundle as it assumes that all devices are IOS which uses a different approach for detecting their (deep)sleeping state. The bundle states:

        // It does not harm to send an additional UDP packet to a device,
        // therefore we assume all ping devices are iOS devices. If this
        // does not work for all users for some obscure reason, we can make
        // this a thing configuration variable.

Well it DOES harm as my IoT device went nuts by this frequent UDP/ICMP/MDNS flooding op port 5353.

Making it a configuration variable has not been done in R2xx. In my case, as I do not use any IOS. I simply default the IOS scan to false: presenceDetection.setIOSDevice(false);

So you fixed the issue ? Or what do you expect to change. The bug was reported long ago with 2.x, as we allready have openHAB 4.0.x for a while, do you have the same results with that version?

[radoslavv]

Looking back to issue and comments here I would say, that correct expectation is not to expect all devices are iOS:

• pragmatically, in regular household there is less than 50% of iOS devices in network,
• pragmatically, worldwide there is less than 50% of market share of iOS devices (beside tons of various non-iOS devices),
• technically, there should be no any meaningless "pollution"/traffic, just because maybe the device is iOS.

I would say correct implemenration should be to define per Thing whether it is iOS device or not (and needs this "workaround" to ping iOS device). Default value have to be FALSE, as reasoned above.
Global ping parameter is not a bad temporary "dirty solution", but it is not a systematic/correct approach.

I do not see any option like this in openHAB 3.4.3 for Things:

however in existing pingable devices there is visible parameter uses_ios_wakeup that I can not change via GUI for concrete thing:

[radoslavv]

Adding parameter uses_ios_wakeup manually to Thing configuration:

did not help - still picture of configuration in my comment above is same uses_ios_wakeup = Yes.

[lsiepel]

The uses_ios_wakeup is a property, and not a configurable option. The binding defaults to all devices being a ios device. the readme states that it does some auto detection, this seems wrong. I'll create a PR, would be great if you could test. The linekd PR has a jar that can be tested. it has an advanced configuration option, check docs.

[radoslavv]

I will try to upgrade OH3 to OH4 this weekend and test.

[wborn]

Another issue with the current iOS wake up implementation is that it is part of performArpPing which is executed for every network interface. So it is executed many times if you don't restrict the number of network interfaces (#16145).