| Summary: | ping -w doesn't respect timeout if -c is specified | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | Gilles Schintgen <gschintgen> |
| Component: | Networking | Assignee: | unassigned |
| Status: | NEW --- | ||
| Severity: | minor | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.35.x | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
On Alpine 3.17 with busybox 1.35 I noticed the following: nodered:~# time ping -w 1 192.168.12.34 PING 192.168.12.34 (192.168.12.34): 56 data bytes --- 192.168.12.34 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss Command exited with non-zero status 1 real 0m 1.00s user 0m 0.00s sys 0m 0.00s nodered:~# time ping -w 1 -c 1 192.168.12.34 PING 192.168.12.34 (192.168.12.34): 56 data bytes --- 192.168.12.34 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss Command exited with non-zero status 1 real 0m 10.00s user 0m 0.00s sys 0m 0.00s In other words, if a count is specified, ping no longer follows its documented behaviour which only mentions *earlier* exiting. -w SEC Seconds until ping exits (default:infinite) (can exit earlier with -c CNT) For comparison, here is the output for ping from iputils 20211215 (Ubuntu 22.04): $ time ping -w 1 192.168.12.34 PING 192.168.12.34 (192.168.12.34) 56(84) bytes of data. --- 192.168.12.34 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms real 0m1.007s user 0m0.006s sys 0m0.001s $ time ping -w 1 -c 1 192.168.12.34 PING 192.168.12.34 (192.168.12.34) 56(84) bytes of data. --- 192.168.12.34 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms real 0m1.006s user 0m0.001s sys 0m0.006s I can't say with certainty which behaviour is correct or incorrect (e.g. when compared to POSIX or some other reference Unix specification), so please indulge me if this is not an actual bug on busybox's side. (My use case is using a nodered ping node with configurable timeout. It didn't work quite right on my nodered instance and I tracked it down to this difference.)