Network:pingdevice breaks after 4.3.6 -> 5.0.1(& 5.0.2, incl. snapshots) update (docker)

Scott_Gowans · September 9, 2025, 1:23am

I noticed all my devices that use network:pingdevice suddenly stop showing ON status after updating my docker instance of OH from 4.3.6 to 5.0.1.
I’ve tried a few times (and rolled back when unsuccessful) without luck.
My OH is running on Ubuntu Server 24.04.3 LTS as an LXC on Proxmox. All devices ping fine and show ON, on 4.3.6. No config changes made (all config is done in files, no GUI).

Some odd notes, which is part of the reason I’ve been scratching my head and have come here for help, or to see if anyone else has similar issues.

All devices can be pinged manually from the host, LXC and within the docker exec console.

Items defined as below all show OFF now.

Switch SBridge_01_Ping <network> { channel="network:pingdevice:SBridge_01_Ping:online" }

Items defined as below now show UNDEF

Number:Time SBridge_01_ResponseTime <network> { channel="network:pingdevice:SBridge_01_Ping:latency" }

Items defined using network:servicedevice still work properly for status and response, defined as below:

Switch TVServer_Ping <network> { channel="network:servicedevice:TVServer:online" }
Number:Time TVServer_ResponseTime { channel="network:servicedevice:TVServer:latency" }

RSSI pulled for all devices still works fine from MQTT payload.

Number SBridge_01_RSSI "Sonoff Bridge: RSSI [%d %%]" (gRSSI) {channel="mqtt:topic:MQTTBroker:mything:SBridge_01_RSSI"}

It’s probably me missing something simple, but after a lot of searching, I can’t find the answer as yet. Any guidance would be greatly appreciated!

rlkoshak · September 9, 2025, 1:00pm

Put the binding into debug logging and see if it tells you why it’s timing out or if there is some other reason.

I would expect the latency to by UNDEF for a device not responding to pings so the OFF and UNDEF is expected for those two Items.

Petrows · September 9, 2025, 5:10pm

Hey @rlkoshak , i have unfortunately exactly same issue in my setup.

My things: smarthome-openhab/things/network.things at master · petrows/smarthome-openhab · GitHub

network.cfg (i also tried with different options):

binding.network:allowSystemPings=true
binding.network:allowDHCPlisten=false
binding.network:arpPingToolPath=arping
binding.network:cacheDeviceStateTimeInMS=2000

I have tried the debug log, module configuration shows options:

2025-09-09 18:55:12.135 [DEBUG] [g.network.internal.PresenceDetection] - Sending listener final result: PresenceDetectionValue [hostAddress=10.80.0.22, latency=-1.0ms, reachableDetectionTypes=[], reachableTcpPorts=[]]
2025-09-09 18:55:13.458 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : ConfigurableComponentHolder configuration updated for pid binding.network with change count 16
2025-09-09 18:55:13.459 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : Querying state active
2025-09-09 18:55:13.459 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : Querying state active
2025-09-09 18:55:13.459 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : invoking modified: modified: parameters [org.apache.felix.scr.impl.helper.ReadOnlyDictionary]
2025-09-09 18:55:13.462 [DEBUG] [twork.internal.NetworkHandlerFactory] - Updated binding configuration to NetworkBindingConfiguration{allowSystemPings=true, allowDHCPlisten=false, cacheDeviceStateTimeInMS=2000, arpPingToolPath='arping', arpPingUtilMethod=THOMAS_HABERT_ARPING, preferResponseTimeAsLatency=false}
2025-09-09 18:55:13.462 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : invoked modified: modified
2025-09-09 18:55:13.462 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : No change in target property for dependency osgi.ds.satisfying.condition: currently registered: true
2025-09-09 18:55:13.462 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : Querying state active
2025-09-09 18:55:13.463 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : ImmediateComponentHolder Finished configuring the dependency managers for component for pid binding.network
2025-09-09 18:55:13.463 [DEBUG] [twork.internal.NetworkHandlerFactory] - bundle org.openhab.binding.network:5.0.1 (314)[org.openhab.binding.network.internal.NetworkHandlerFactory(377)] : ImmediateComponentHolder Will not enable component for pid binding.network: holder enabled state: true, metadata enabled: true
2025-09-09 18:55:15.889 [DEBUG] [g.network.internal.PresenceDetection] - All 1 detection futures for 8.8.8.8 have completed
2025-09-09 18:55:15.889 [DEBUG] [g.network.internal.PresenceDetection] - 8.8.8.8 is unreachable, invalidating destination value
2025-09-09 18:55:15.889 [DEBUG] [g.network.internal.PresenceDetection] - Sending listener final result: PresenceDetectionValue [hostAddress=8.8.8.8, latency=-1.0ms, reachableDetectionTypes=[], reachableTcpPorts=[]]

It show settings to be read. Device lookup in logs:

# Example thing: Thing network:pingdevice:backup_ext "Backup ext" [ hostname="8.8.8.8", useArpPing=false, useIcmpPing=true, retry=5, timeout=5000, refreshInterval=5000 ]

2025-09-09 18:57:40.971 [DEBUG] [g.network.internal.PresenceDetection] - Refreshing 8.8.8.8 reachability state
2025-09-09 18:57:40.971 [TRACE] [g.network.internal.PresenceDetection] - Performing 1 presence detection checks for 8.8.8.8
2025-09-09 18:57:40.971 [DEBUG] [g.network.internal.PresenceDetection] - Shutting down waitForResultExecutorService
2025-09-09 18:57:40.971 [TRACE] [g.network.internal.PresenceDetection] - Perform Java ping presence detection for 8.8.8.8
2025-09-09 18:57:40.971 [DEBUG] [g.network.internal.PresenceDetection] - Waiting for 1 detection futures for 8.8.8.8 to complete
2025-09-09 18:57:45.977 [DEBUG] [g.network.internal.PresenceDetection] - All 1 detection futures for 8.8.8.8 have completed
2025-09-09 18:57:45.977 [DEBUG] [g.network.internal.PresenceDetection] - 8.8.8.8 is unreachable, invalidating destination value
2025-09-09 18:57:45.977 [DEBUG] [g.network.internal.PresenceDetection] - Sending listener final result: PresenceDetectionValue [hostAddress=8.8.8.8, latency=-1.0ms, reachableDetectionTypes=[], reachableTcpPorts=[]]

Looks like module does not tried to use system ping and uses Java one. The allowSystemPings actually ignored. I have looked on method selection in source code and it matches against OS Name first. In my case it is not an issue, i have “Linux”:

$ docker exec -it Openhab /bin/bash
root@home:/openhab# java -XshowSettings:properties -version 
Property settings:
    file.encoding = UTF-8
    file.separator = /
    ...
    os.arch = amd64
    os.name = Linux
    os.version = 6.8.12-14-pve
    ...
    user.language = en
    user.name = root

openjdk version "21.0.8" 2025-07-15
OpenJDK Runtime Environment (build 21.0.8+9-Debian-1)
OpenJDK 64-Bit Server VM (build 21.0.8+9-Debian-1, mixed mode, sharing)

So it has expected value. I have no logs messages like “ping 127.0.0.1” failed or similar.

So, it uses Java ping for some reason, but why it failed? I have dumped traffic on machine and i don’t see any ICMP requests, looks like it tries to open TCP connection to port 7:

tcpdump -n -i eth0 -vvv host 8.8.8.8
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:05:40.246908 IP (tos 0x0, ttl 64, id 50271, offset 0, flags [DF], proto TCP (6), length 60)
    10.80.6.2.59074 > 8.8.8.8.7: Flags [S], cksum 0x2090 (incorrect -> 0xf75b), seq 3881175603, win 64240, options [mss 1460,sackOK,TS val 3997331131 ecr 0,nop,wscale 7], length 0
19:05:41.286326 IP (tos 0x0, ttl 64, id 50272, offset 0, flags [DF], proto TCP (6), length 60)
    10.80.6.2.59074 > 8.8.8.8.7: Flags [S], cksum 0x2090 (incorrect -> 0xf34b), seq 3881175603, win 64240, options [mss 1460,sackOK,TS val 3997332171 ecr 0,nop,wscale 7], length 0
19:05:42.310325 IP (tos 0x0, ttl 64, id 50273, offset 0, flags [DF], proto TCP (6), length 60)
    10.80.6.2.59074 > 8.8.8.8.7: Flags [S], cksum 0x2090 (incorrect -> 0xef4b), seq 3881175603, win 64240, options [mss 1460,sackOK,TS val 3997333195 ecr 0,nop,wscale 7], length 0
19:05:43.334361 IP (tos 0x0, ttl 64, id 50274, offset 0, flags [DF], proto TCP (6), length 60)
    10.80.6.2.59074 > 8.8.8.8.7: Flags [S], cksum 0x2090 (incorrect -> 0xeb4b), seq 3881175603, win 64240, options [mss 1460,sackOK,TS val 3997334219 ecr 0,nop,wscale 7], length 0
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

So, i am out of ideas:

Option to select native ping seems to be broken
Java “ping” seems to be tries to open TCP connection instead of ICMP and fails. Looks like this problem is pretty old.

rlkoshak · September 9, 2025, 5:59pm

All I can suggest is to open an issue at this point.

Petrows · September 9, 2025, 8:21pm

Hey @Scott_Gowans and @rlkoshak , i think i have found and fixed that issue.

Some background for @Scott_Gowans : i have exactly same setup as you (Proxmox and LXC and Docker) and same problem. I believe you are also running this as unprivileged container.

I have recompiled this binding and have added some extra logging for test and tested locally. Locally issue is not reproduced, then i have feed my production instance with JAR file.

My test shows that Bundle fails to run ping command with exit code 2.

All devices can be pinged manually from the host, LXC and within the docker exec console.

This test works, because you probably call ping from root. If you will call it from Openhab user, result is different:

root@home:/openhab# id
uid=0(root) gid=0(root) groups=0(root)
root@home:/openhab# su openhab
openhab@home:~$ ping localhost
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?

Problem is that user has no permission for socket for ping, what is used by Openhab in official container. Issue can be fixed in runtime by calling

setcap cap_net_raw+ep /bin/ping

, before running Openhab. Bundle performs test once at startup and then uses result.

I am building my own docker image on base of official to add some extra there, so it was easy to fix, i have committed it here: Fix Openhab ping command usage under Proxmox LXC for network:pingdevi… · petrows/saltstack-config@a0c332e · GitHub

Now it works, hope it will help! I have device with proper online status, for example for Laptop what i am using right now:

Scott_Gowans · September 9, 2025, 11:46pm

Great info @Petrows. Thanks to you and @rlkoshak for suggestions.

Very weird this becomes a permission issue on exactly the same OS (as an LXC of course) after only updating OH.

This is correct.

Interestingly, yes I was pinging from root within docker exec. However, I tested switching to the openhab user and pinging again, which also works!?

Note, the below tests are on my rolled back 4.3.6 LXC (shoutout to Proxmox Backups!), however nothing should change at user/OS level after updating one container in this LXC, but this has given me an idea for another test…I’ll update OH container to 5.0.1 again and rerun the below after posting this.

xxxxxxdmin@lxcha:~$ sudo docker exec -it openhab bash
root@exxxxxxxxx88:/openhab# ping xxx.xxx.xx.1
PING xxx.xxx.xx.1 (xxx.xxx.xx.1) 56(84) bytes of data.
64 bytes from xxx.xxx.xx.1: icmp_seq=1 ttl=63 time=0.823 ms
64 bytes from xxx.xxx.xx.1: icmp_seq=2 ttl=63 time=0.741 ms
64 bytes from xxx.xxx.xx.1: icmp_seq=3 ttl=63 time=0.576 ms
^C
--- xxx.xxx.xx.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2013ms
rtt min/avg/max/mdev = 0.576/0.713/0.823/0.102 ms
root@exxxxxxxxx88:/openhab# ping xxx.xxx.xx.175
PING xxx.xxx.xx.175 (xxx.xxx.xx.175) 56(84) bytes of data.
64 bytes from xxx.xxx.xx.175: icmp_seq=1 ttl=254 time=116 ms
64 bytes from xxx.xxx.xx.175: icmp_seq=2 ttl=254 time=44.0 ms
64 bytes from xxx.xxx.xx.175: icmp_seq=3 ttl=254 time=58.7 ms
^C
--- xxx.xxx.xx.175 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 44.014/73.060/116.491/31.288 ms
root@exxxxxxxxx88:/openhab# su openhab
openhab@exxxxxxxxx88:~$ ping xxx.xxx.xx.1
PING xxx.xxx.xx.1 (xxx.xxx.xx.1) 56(84) bytes of data.
64 bytes from xxx.xxx.xx.1: icmp_seq=1 ttl=63 time=0.834 ms
64 bytes from xxx.xxx.xx.1: icmp_seq=2 ttl=63 time=0.634 ms
64 bytes from xxx.xxx.xx.1: icmp_seq=3 ttl=63 time=0.384 ms
^C
--- xxx.xxx.xx.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.384/0.617/0.834/0.184 ms
openhab@exxxxxxxxx88:~$ ping xxx.xxx.xx.175
PING xxx.xxx.xx.175 (xxx.xxx.xx.175) 56(84) bytes of data.
64 bytes from xxx.xxx.xx.175: icmp_seq=1 ttl=254 time=124 ms
64 bytes from xxx.xxx.xx.175: icmp_seq=2 ttl=254 time=90.8 ms
64 bytes from xxx.xxx.xx.175: icmp_seq=3 ttl=254 time=75.4 ms
^C
--- xxx.xxx.xx.175 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 75.396/96.702/123.891/20.230 ms
openhab@exxxxxxxxx88:~$

The container stack is started with:

      USER_ID: 1000
      GROUP_ID: 1000

which is openhab user:

root@exxxxxxxxx88:/openhab# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
openhab:x:1000:1000::/openhab:/bin/bash

The whole stack is (and always has) run on the same docker bridged network, with only the OH related containers on this LXC. (Grafana, InfluxDB, Mosquitto and Frontail)

No firewall issues or weird logging identified.

This does sound like the avenue of choice, but I’ll run one more test first as stated above.

Cheers people.

Scott_Gowans · September 10, 2025, 12:21am

As suspected, ping from openhab user, after updating the OH container to 5.0.1 now fails:

root@exxxxxxxxx29:/openhab# ping xxx.xxx.xx.1
PING xxx.xxx.xx.1 (xxx.xxx.xx.1) 56(84) bytes of data.
64 bytes from xxx.xxx.xx.1: icmp_seq=1 ttl=63 time=0.801 ms
64 bytes from xxx.xxx.xx.1: icmp_seq=2 ttl=63 time=0.788 ms
^C
--- xxx.xxx.xx.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1048ms
rtt min/avg/max/mdev = 0.788/0.794/0.801/0.006 ms
root@exxxxxxxxx29:/openhab# ping xxx.xxx.xx.175
PING xxx.xxx.xx.175 (xxx.xxx.xx.175) 56(84) bytes of data.
64 bytes from xxx.xxx.xx.175: icmp_seq=1 ttl=254 time=2.91 ms
64 bytes from xxx.xxx.xx.175: icmp_seq=2 ttl=254 time=2.71 ms
^C
--- xxx.xxx.xx.175 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.709/2.809/2.909/0.100 ms
root@exxxxxxxxx29:/openhab# su openhab
openhab@exxxxxxxxx29:~$ ping xxx.xxx.xx.1
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?
openhab@exxxxxxxxx29:~$ ping xxx.xxx.xx.175
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?
openhab@exxxxxxxxx29:~$

Hopefully this is enough data to get a fix happening, if a dev would be so kind. I’ll see if I can remember where to lodge an issue.

Makes me wonder if this has been sorted already in milestones, or even nightlies?

EDIT: FWIW, I updated to 4.3.7 and ping from openhab user in container works, as it does for 4.3.6, so it seems to be an issue with v5

@rlkoshak Should I raise an issue under core, addons, or docker for this one?

rlkoshak · September 10, 2025, 2:05pm

Can’t you pass setcap on the command to docker run?

It’s not clear to me where the issue belongs. If it’s something that needs to change in the add-on that’s where it needs to go. If it’s something to fix in just the container, that’s where it goes. I didn’t think core is involved.

Scott_Gowans · September 11, 2025, 7:48am

Thanks @rlkoshak , issue created under docker (seemed more appropriate).

github.com/openhab/openhab-docker

Docker under LXC unable to ping subnet from openhab user after update to 5.0.1 from 4.3.x

opened 07:47AM - 11 Sep 25 UTC

cods69

bug

## Summary Updating OpenHAB from 4.3.6 to 5.0.1 resulting in broken network:pin…gdevice. On investigation the container privileges seem to change for openhab user after the update. ## Expected Behavior Prior to update you can ping devices successfully from the container as either root or openhab user. network:pingdevices functions correctly and returns ping and latency from addon. Illustrated when pinging from container ``` xxxxxxdmin@lxcha:~$ sudo docker exec -it openhab bash root@exxxxxxxxx88:/openhab# ping xxx.xxx.xx.1 PING xxx.xxx.xx.1 (xxx.xxx.xx.1) 56(84) bytes of data. 64 bytes from xxx.xxx.xx.1: icmp_seq=1 ttl=63 time=0.823 ms 64 bytes from xxx.xxx.xx.1: icmp_seq=2 ttl=63 time=0.741 ms 64 bytes from xxx.xxx.xx.1: icmp_seq=3 ttl=63 time=0.576 ms ^C --- xxx.xxx.xx.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2013ms rtt min/avg/max/mdev = 0.576/0.713/0.823/0.102 ms root@exxxxxxxxx88:/openhab# ping xxx.xxx.xx.175 PING xxx.xxx.xx.175 (xxx.xxx.xx.175) 56(84) bytes of data. 64 bytes from xxx.xxx.xx.175: icmp_seq=1 ttl=254 time=116 ms 64 bytes from xxx.xxx.xx.175: icmp_seq=2 ttl=254 time=44.0 ms 64 bytes from xxx.xxx.xx.175: icmp_seq=3 ttl=254 time=58.7 ms ^C --- xxx.xxx.xx.175 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 44.014/73.060/116.491/31.288 ms root@exxxxxxxxx88:/openhab# su openhab openhab@exxxxxxxxx88:~$ ping xxx.xxx.xx.1 PING xxx.xxx.xx.1 (xxx.xxx.xx.1) 56(84) bytes of data. 64 bytes from xxx.xxx.xx.1: icmp_seq=1 ttl=63 time=0.834 ms 64 bytes from xxx.xxx.xx.1: icmp_seq=2 ttl=63 time=0.634 ms 64 bytes from xxx.xxx.xx.1: icmp_seq=3 ttl=63 time=0.384 ms ^C --- xxx.xxx.xx.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2040ms rtt min/avg/max/mdev = 0.384/0.617/0.834/0.184 ms openhab@exxxxxxxxx88:~$ ping xxx.xxx.xx.175 PING xxx.xxx.xx.175 (xxx.xxx.xx.175) 56(84) bytes of data. 64 bytes from xxx.xxx.xx.175: icmp_seq=1 ttl=254 time=124 ms 64 bytes from xxx.xxx.xx.175: icmp_seq=2 ttl=254 time=90.8 ms 64 bytes from xxx.xxx.xx.175: icmp_seq=3 ttl=254 time=75.4 ms ^C --- xxx.xxx.xx.175 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 75.396/96.702/123.891/20.230 ms openhab@exxxxxxxxx88:~$ ``` ## Current Behavior Initial forum thread I created on this issue. Confirmed by another user. https://community.openhab.org/t/network-pingdevice-breaks-after-4-3-6-5-0-1-update-docker/166175 network:pingdevice subsequently fails when running on 5.0.1 due to the user openhab no longer having privilege to ping out. Root user can still ping from the container exec. ``` root@exxxxxxxxx29:/openhab# ping xxx.xxx.xx.1 PING xxx.xxx.xx.1 (xxx.xxx.xx.1) 56(84) bytes of data. 64 bytes from xxx.xxx.xx.1: icmp_seq=1 ttl=63 time=0.801 ms 64 bytes from xxx.xxx.xx.1: icmp_seq=2 ttl=63 time=0.788 ms ^C --- xxx.xxx.xx.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1048ms rtt min/avg/max/mdev = 0.788/0.794/0.801/0.006 ms root@exxxxxxxxx29:/openhab# ping xxx.xxx.xx.175 PING xxx.xxx.xx.175 (xxx.xxx.xx.175) 56(84) bytes of data. 64 bytes from xxx.xxx.xx.175: icmp_seq=1 ttl=254 time=2.91 ms 64 bytes from xxx.xxx.xx.175: icmp_seq=2 ttl=254 time=2.71 ms ^C --- xxx.xxx.xx.175 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 2.709/2.809/2.909/0.100 ms root@exxxxxxxxx29:/openhab# su openhab openhab@exxxxxxxxx29:~$ ping xxx.xxx.xx.1 ping: socktype: SOCK_RAW ping: socket: Operation not permitted ping: => missing cap_net_raw+p capability or setuid? openhab@exxxxxxxxx29:~$ ping xxx.xxx.xx.175 ping: socktype: SOCK_RAW ping: socket: Operation not permitted ping: => missing cap_net_raw+p capability or setuid? openhab@exxxxxxxxx29:~$ ``` ## Possible Solution Petrows posted his own OH build solution on the forum link above. I'm unsure if that's viable for a bugfix. I'll leave that to the devs. ## Steps to Reproduce 1.Using OpenHAB on container, running on Ubuntu LTS LXC under Proxmox. 2.Simple use of network:pingdevice Thing and Items after update from OH 4.3.6 to 5.0.1 fails, with latency showing UNDEF, ping showing OFF. 3.network:servicedevice still works after update for online and latency ## Context This was an existing function which is now broken, with status and stats of all devices connectivity no longer visible via network:pingdevice:x:online or network:pingdevice:x:latency ## Your Environment Proxmox 8.4.12 Ubuntu 24.04.3 LTS (running as LXC) Docker 28.3.3 Docker Compose v2.39.1 Portainer CE 2.33.1 LTS ### Image * openHAB version: 4.3.6, 4.3.7, 5.0.1 * Image tag used: latest ### Docker Host * Operating System: Ubuntu 24.04.3 LTS (running as LXC) * Docker Version: 28.3.3 * Kernel Version: (GNU/Linux 6.8.12-13-pve x86_64) * Architecture: x86_64 ### Configuration ``` services: openhab: image: openhab/openhab:4.3.7 container_name: openhab depends_on: grafana: condition: service_healthy restart: true influxdb2: condition: service_healthy restart: true mosquitto: condition: service_healthy restart: unless-stopped labels: - "com.centurylinklabs.watchtower.enable=false" networks: - backend ports: - "xxxx:xxxx" - "xxxx:xxxx/udp" stdin_open: true # docker run -i tty: true # docker run -t volumes: - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro - addons:/openhab/addons - conf:/openhab/conf - userdata:/openhab/userdata environment: CRYPTO_POLICY: unlimited EXTRA_JAVA_OPTS: -Duser.timezone=Australia/Melbourne OPENHAB_HTTP_PORT: xxxx OPENHAB_HTTPS_PORT: xxxx USER_ID: 1000 GROUP_ID: 1000 ... volumes: addons: driver: local driver_opts: type: none device: /home/xxxxdmin/docker/openhab/addons o: bind conf: driver: local driver_opts: type: none device: /home/xxxxdmin/docker/openhab/conf o: bind userdata: driver: local driver_opts: type: none device: /home/xxxxdmin/docker/openhab/userdata o: bind ... networks: backend: external: true ```

Scott_Gowans · October 16, 2025, 11:55pm

For visibility, apparently this is fixed in a snapshot according to this thread.

I won’t mark as a solution yet as I have not tested, but will when I have thoroughly tested as per the bug report I linked above.

Scott_Gowans · October 21, 2025, 11:18pm

FYI to those with the same problem, the issue still exists after 5.0.2 Release update in docker-compose, via standard pull new image.

Perhaps the snapshot build with the fix didn’t make it in to 502, as I’m not really clear on the tracking of this problem.

EDIT: Just checked Snapshot 5.1.0 Build #4854 straight update, same issue there too.

Hopefully it’s not necessary for the final fix to have to do what @fals3illusion had to do in this thread.

jdfr28 · October 26, 2025, 4:06pm

Hi,
Same issue here using going from OH4.0.4 to OH5.0.1 on docker running on a synology NAS.

This is really a pain as this is a central element for my set-up when it comes to presence detection.

Maybe some additions:

One old phone (Huaiwai P-Smart) works flawlessly
One newer phone (Google Pixel 8) won’t be recognized expect, when the phone is active (like if I look at a video on Youtube).

If you need more details, please reach out as I’m not sure on where to start.

I’ve looked at the post from @fals3illusion but I’m not sure to be able to do it. Is there another workaround?

Thanks!

Petrows · October 27, 2025, 7:31pm

Hey all, i can confirm that latest docker images still have this issue.

I have opened PR with fix: Fix missing sticky-bit for /bin/ping tool by petrows · Pull Request #482 · openhab/openhab-docker · GitHub

jdfr28 · October 28, 2025, 9:21pm

Hi all,

@Petrows, thanks for the pull request. I’ve followed it and tried to execute the chmod command

chmod u+s /bin/ping

in the docker bash but this did not help.

In doubt, I’ve run the command coming from your post from Sept 9

setcap cap_net_raw+ep /bin/ping

, restarted the docker container and it worked straight away.

I have no idea if either @Petrows or @Scott_Gowans would need to to update their post on Github to give an hint to the team . (I’m clueless on how to use Github)

In any case, thanks for the help!

Petrows · October 29, 2025, 4:58pm

Hey @jdfr28 , i just tested on my Proxmox instance, reproducing mine and @Scott_Gowans problem :

I have logged into running underprivileged LXC container and called the following:

root@lxc-container$ docker run -it --rm --name openhab-test openhab/openhab:latest-debian /bin/bash
Unable to find image 'openhab/openhab:latest-debian' locally
latest-debian: Pulling from openhab/openhab
8c7716127147: Pull complete
72544fe02a93: Pull complete
598a30014607: Pull complete
c91d0e75f730: Pull complete
b8c07b01cbc8: Pull complete
c5e232e6afbf: Pull complete
4f4fb700ef54: Pull complete
d67dea44a8f9: Pull complete
Digest: sha256:64bca930e3d319f7ef546b2ed1b6aa041db546aa611b79609a2669dc4ae5ce9e
Status: Downloaded newer image for openhab/openhab:latest-debian
...
+ sync
+ '[' true == false ']'
+ exec /bin/bash

# Test the problem is yet exists:
root@e085bf186ec5:/openhab# su openhab
openhab@e085bf186ec5:~$ ping 8.8.8.8
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?

# Return to root and apply proposed fix from PR in runtime:
openhab@e085bf186ec5:~$
exit
root@e085bf186ec5:/openhab# chmod u+s /bin/ping

# Return to user again and now ping works:
root@e085bf186ec5:/openhab# su openhab
openhab@e085bf186ec5:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=16.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=13.2 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 13.169/15.024/16.879/1.855 ms

and it is exactly the same for openhab/openhab:latest-alpine container.

Probably you have another problem or some different environment.

Petrows · October 29, 2025, 5:01pm

You probably doing something wrong, such changes will be not preserved during restart. Fix must be applied:

a) In the Dockerfile, to have fix present in container rootfs, this will allow to use container as usual

b) In runtime in container, before plugin initializes (see my comments above), or during some test session. This changes are applied in runtime and will be not kept among restarts

Petrows · November 4, 2025, 8:35am

FYI Guys: fix merged to upstream, should be included in next OpenHab release

Scott_Gowans · November 5, 2025, 11:56pm

Awesome stuff @Petrows . Just tested 5.1.0-SNAPSHOT - Build #4891 and the fix seems to have made it in to the latest snapshot.

It works very well, just as it did before.

Unfortunately I won’t be testing it any longer than 30 mins as the update has brought up various other OH issues (unrelated) I don’t have time to look at for the minute, but I’m happy that it’s fixed for when I do move to a newer release in the near future.

Again, well done sir, on getting the PR in and through.