Thanks, but as told before, ping command does not give any output when the destination is unreachable. And nping does not display timestamp. Fixing any of these 2 issues would be a perfect solution whether the command is run from rc.local or screen -RR.
Full iputils ping (from ubuntu 20.X) has the
user@linux-host:~$ ping -D -O -c 10 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. [1606919597.364248] From 192.168.42.1 icmp_seq=1 Destination Net Unreachable [1606919598.365394] no answer yet for icmp_seq=1 [1606919598.365930] From 192.168.42.1 icmp_seq=2 Destination Net Unreachable [1606919599.389407] no answer yet for icmp_seq=2 [1606919599.389881] From 192.168.42.1 icmp_seq=3 Destination Net Unreachable [1606919600.413429] no answer yet for icmp_seq=3 [1606919600.413880] From 192.168.42.1 icmp_seq=4 Destination Net Unreachable [1606919601.441372] no answer yet for icmp_seq=4 [1606919601.441739] From 192.168.42.1 icmp_seq=5 Destination Net Unreachable [1606919602.461406] no answer yet for icmp_seq=5 [1606919602.461846] From 192.168.42.1 icmp_seq=6 Destination Net Unreachable [1606919603.485396] no answer yet for icmp_seq=6 [1606919603.485864] From 192.168.42.1 icmp_seq=7 Destination Net Unreachable [1606919604.509393] no answer yet for icmp_seq=7 [1606919604.509845] From 192.168.42.1 icmp_seq=8 Destination Net Unreachable [1606919605.533412] no answer yet for icmp_seq=8 [1606919605.533862] From 192.168.42.1 icmp_seq=9 Destination Net Unreachable [1606919606.557390] no answer yet for icmp_seq=9 [1606919606.557766] From 192.168.42.1 icmp_seq=10 Destination Net Unreachable --- 10.1.1.1 ping statistics --- 10 packets transmitted, 0 received, +10 errors, 100% packet loss, time 9194ms
opkg update ; opkg install iputils-ping' under OpenWrt 19.07.4 does not seem to support the -O` option, sorry.
I can see fping solves my problem, but I cannot find out how to decrease the delay of the "ICMP Host Unreachable" messages. Please see below, there are 5 attempts missing between the 6th and the 12th, but there are only 3 "ICMP Host Unreachable" messages. Due to this delay sometimes "ICMP Host Unreachable" messages are not even appearing while the connection is being interrupted for a shorter time. Could you please advice how to decrease this delay?
root@OpenWrt:~# fping -l -D -i 5000 -t 4000 192.168.1.125 [1607132467.001743] 192.168.1.125 : , 84 bytes, 213 ms (213 avg, 75% loss) [1607132471.918317] 192.168.1.125 : , 84 bytes, 130 ms (171 avg, 60% loss) [1607132476.891848] 192.168.1.125 : , 84 bytes, 103 ms (149 avg, 50% loss) [1607132481.953011] 192.168.1.125 : , 84 bytes, 164 ms (152 avg, 42% loss) ICMP Host Unreachable from 192.168.1.1 for ICMP Echo sent to 192.168.1.125 ICMP Host Unreachable from 192.168.1.1 for ICMP Echo sent to 192.168.1.125 ICMP Host Unreachable from 192.168.1.1 for ICMP Echo sent to 192.168.1.125 [1607132511.792334] 192.168.1.125 : , 84 bytes, 2.53 ms (122 avg, 61% loss) [1607132516.793914] 192.168.1.125 : , 84 bytes, 3.58 ms (102 avg, 57% loss) [1607132521.793857] 192.168.1.125 : , 84 bytes, 3.37 ms (88.6 avg, 53% loss) ^C 192.168.1.125 : xmt/rcv/%loss = 15/7/53%, min/avg/max = 2.53/88.6/213 root@OpenWrt:~#
Not that I am an expert in fping (what made you think that?), here is from man fping:
" -t, --timeout=MSEC
Initial target timeout in milliseconds. In the default, non-loop mode, the default timeout is 500ms, and
it represents the amount of time that fping waits for a response to its first request. Successive timeouts
are multiplied by the backoff factor specified with -B.
In loop/count mode, the default timeout is automatically adjusted to match the "period" value (but not more than 2000ms). You can still adjust the timeout value with this option, if you wish to, but note that setting a value larger than "period" produces inconsistent results, because the timeout value can be respected only for the last ping. Also note that any received replies that are larger than the timeout value, will be discarded."
Could it be that your ICMP Host Unreachable messages might occasionally take longer than 4 seconds?
Alternatively, run a script that issues a single (
-c 1) ping command and look at its output and loop that, instead of instructing ping to loop?
Under certain conditions, there may be no messages if there's no one to send them, or destination firewall filters them, or ICMP request/reply is lost during transmission, etc.
Yes, I understand, but I had assumed, that ping would notice and give some output that a probe was "lost in a blackhole" or something....
Actually, fping is supposed to display timeouts:
> fping -l duckduckgo.com duckduckgo.com : , timed out (NaN avg, 100% loss) duckduckgo.com : , timed out (NaN avg, 100% loss) duckduckgo.com : , timed out (NaN avg, 100% loss) ^C duckduckgo.com : xmt/rcv/%loss = 3/0/100%
This is how it works on Fedora.
Probably there're some OpenWrt-specific build flags preventing it.
Or something Glibc-specific that fping relies on.
Is I experienced it takes ~50 sec for the first "ICMP Host Unreachable" to appear after the connection interrupts. Actually it doesn't matter for me whether it is a "host unreachable" or "time out", I would just need something in the log to indicate much sooner (5 - 10 sec) when there's no connection.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.