When we are using windows ping , it will show the failed pings. Does Ubuntu have similar function?

The failed ping is quite useful when debugging the network. How you guys solve this? Well, I only want simple solution, I don't want to get a long script.

  • 2
    Can you provide a sample output or a screenshot to supplement the question?
    – green
    Commented Apr 6, 2013 at 8:02
  • 1
    Are you looking or more detailed information than 5 packets transmitted, 0 received, 100% packet loss, time 4032ms (information like that is printed when ping terminates, whether by itself or by Ctrl+C)? Are you looking for separate data about each individual ping? Commented Apr 6, 2013 at 17:34
  • 2
    Linux is awesome and all of us here love it for many reasons but... hey sometimes Windows got it right and Linux got it wrong. Yes, even in basic CLI tools. Yes, even in basic networking CLI tools! If there is no easy way to get a message on screen when things go wrong then we must acknowledge it as "a feature we're missing". We certainly don't want to pretend it's something so complex that we can't figure out what is it exactly that the OP is asking (especially when it's a feature turned on by default in a few million boxes around us).
    – ndemou
    Commented Jan 17, 2015 at 18:41
  • I could have sworn that this feature was present in earlier linux ping. It's present in MacOS as well (which is built on top of unix). It's beyond me why it shouldn't be there. I have a line that works intermittent and to find out the lenght of the blackouts I need to sift through the output looking for jump, instead of having the lines clearly distinct. Commented Feb 9, 2015 at 19:59

6 Answers 6


When Windows' ping says "Request timed out.", it is not an error per se. Microsoft arbitrarily chose a timeout of 4 seconds, after which they assume "failure" and report it. If you were to ping anything from Mars, that's a guaranteed false alarm, but even on Earth RTT (round-trip time) over 4s is perfectly possible. The timeout is configurable with a /w <millisec> switch.

On Linux, ping utility does not assume that timeout is a failure and doesn't wait for reply. Normally, it prints all received replies immediately and as-is, including "late" ones, out-of-order ones, duplicates and and conflicting responses (e.g. a valid reply after "Destination unreachable").

Having said that, there usually are options to see when a reply isn't received for too long. Even on my Android phone, stock ping utility supports these 2 options:

  • -D prints a timestamp before every message, makes gaps easier to spot.
  • -O prints a message when reply is not received before sending next ping, and this is more or less what was asked. The "timeout" is fixed to ping interval (-i), though.

However, these options do not seem to be supported everywhere (e.g. Debian Wheezy lacks them as far as I know, while Jessie has them. busybox ping does not support them yet).

Here is an example output I managed to get (unimportant ping replies skipped):

u0_a93@NX505J:/ $ ping -D -O
PING ( 56(84) bytes of data.
[1440545014.805478] 64 bytes from icmp_seq=1 ttl=244 time=116 ms
[1440545142.995443] 64 bytes from icmp_seq=129 ttl=244 time=110 ms
[1440545144.885601] no answer yet for icmp_seq=130
[1440545145.455485] 64 bytes from icmp_seq=131 ttl=244 time=568 ms
[1440545145.455780] 64 bytes from icmp_seq=130 ttl=244 time=1569 ms
[1440545146.005850] 64 bytes from icmp_seq=132 ttl=244 time=119 ms
[1440545254.055962] 64 bytes from icmp_seq=240 ttl=244 time=115 ms
--- ping statistics ---
240 packets transmitted, 240 received, 0% packet loss, time 239250ms
rtt min/avg/max/mdev = 109.062/138.757/1569.620/101.608 ms, pipe 2

Note how #130 is first reported "missing", then received after #131, and finally packet loss is reported to be zero. Windows' ping would never give such a result: it waits until a reply or a timeout and only then sends next ping, ignoring any late or non-first replies.

  • 5
    +1 for -O option, is present and works well in Ubuntu trusty (& Linux Mint 17.2) from the iputils-ping package version 3:20121221-4ubuntu1.1
    – Xen2050
    Commented Aug 28, 2015 at 21:38
  • Rather than "there's no such thing as a failed/lost ping", wouldn't it be clearer to say "there are many kinds of failed ping"? Also, it seems to me, the "right answer" is the -O option you've given.
    – mwfearnley
    Commented Sep 14, 2021 at 11:38
  • @mwfearnley I still like my wording better. The point I was making is that what Windows repotrs as an error by default is just an arbitrary timeout chosen by M$. On Earth RTT over several seconds is very rare, but if you ping anything from Mars you have to wait for 6 to 44 minutes before even suspecting that something went wrong.
    – EvgEnZh
    Commented Sep 15, 2021 at 12:30
  • I see your perspective now, that makes sense. Maybe it would just be clearer to say that a ping is never “definitively” lost (from the pinger’s perspective). It could still return at any point, and the timeout is just an indicator that it’s “probably” failed - or “effectively” failed, if a particular response time is required.
    – mwfearnley
    Commented Sep 15, 2021 at 14:59
  • In the end: $ ping -O | fgrep 'no answer yet' --line-buffered | ts
    – kolypto
    Commented Oct 13, 2023 at 8:16

Going partially off the answer by EvgEnZh, but with my own version:

ping -O -q

That makes it print a message when a reply takes too long or never comes back (-O) and suppresses messages for when they do come back (-q). The result is that you only get output when packets go missing. This can make finding intermittent problems much easier by making it so you don't have to sift through a pile of "it worked" messages for the few places it broke.

  • Note that -O triggering only means that latency is higher than expected. That often indicates a real problem, but not always. That log I posted in my answer was acquired on a weak GPRS connection, and even though in over 2 minutes I only caught single out-of-order reply, there were many replies that came in "late". The crappy connection got overwhelmed a few times, reported several pings missing in a row, and then they all came in after a few seconds. The connection was still reliable (maybe GPRS handled retransmission internally, I don't know), just an extreme pain to use even for SSH access.
    – EvgEnZh
    Commented Aug 30, 2018 at 13:01

Maybe ping -f is suitable for you. From ping manual:


Flood ping. For every ECHO_REQUEST sent a period ''.'' is printed, while for ever ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. If interval is not given, it sets interval to zero and outputs packets as fast as they come back or one hundred times per second, whichever is more. Only the super-user may use this option with zero interval.

For 1 echo_request every second it would look like ping -i 1 -f

  • Not sure it's a new feature or not, I could see the failed pings.
    – 王子1986
    Commented Apr 11, 2013 at 14:15
  • Which option did you use to get the failed pings reported? What message are you getting for a failed ping? Commented Apr 11, 2013 at 18:46
  • While I just used ping the message is like this $ping PING ( 56(84) bytes of data. From icmp_seq=1 Destination Host Unreachable From icmp_seq=2 Destination Host Unreachable From icmp_seq=3 Destination Host Unreachable
    – 王子1986
    Commented Apr 12, 2013 at 6:50
  • 2
    "Destination Host Unreachable" is not the same as a ping timeout
    – ndemou
    Commented Jan 17, 2015 at 17:31
  • ping -f is not the answer, because it doesn't leave a record. What is needed is one type of line for a successful ping and and a different for failure, so one can immediately tell (in a situation where service is intermittent) how often and how long the blackouts are. Commented Feb 9, 2015 at 20:14

there is no such thing as "failed lost ping". (Failure replies like "Destination unreachable" are always printed, it is different from no reply at all.)

Ping utility prints every received reply, even if it eatlier decided that this specific ping was lost. It is entirely possible to receive replies out of order. "

This is apparently no longer the case. Just a year after you posted this, iputils/ping broke so now it is entirely possible that nothing gets printed.



Even with the -v option, ping don't do that. See this question. But if this is really important (or fun) for you, you can download the source, modify the code to include a suitable printf call. A good place to to that would be at the end of method 'send_probe' (line 619 on 12.10)...

First you get the source

apt-get source iputils
cd iputils*

Make edits

gedit ping.c

Build, and install generated package...

apt-get install libsysfs-dev
  • I would like to do this (and upvote this answer 10 times) but there must be something missing. I'm working under sudo -s. After editing ping.c, if I try "make" I get "fatal error: sys/capability.h: No such file". If I follow the next two lines in the answer (apt-get install and dpkg-...) I get no errors but I have no idea where the executable is placed. The old executable (/bin/ping) is still there -- I know it's old from the timestamp and because it doesn't behave any differently. Commented Feb 9, 2015 at 20:10

Thanks for all the answers. It seems like the latest ubuntu ping can show the ping failed.

Thanks again.

  • 1
    No it doesn't (until 2015-Jan at least) "Destination Host Unreachable" is not the same as a ping timeout
    – ndemou
    Commented Jan 17, 2015 at 17:30
  • 2
    Why is this the accepted answer?ping -O -q is the way to go.
    – kostrykin
    Commented Jul 8, 2019 at 11:54
  • @theV0ID because they self-answered back in 2013. Nothing we can do about it.
    – Thomas Ward
    Commented Jan 28, 2020 at 17:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .