I use, ping -c 1 -w 2 192.168.0.2

If host is not connected, it fails correctly. BUT summary says.

PING 192.168.0.2 from 192.168.0.1 : 56(84) bytes of data

--------192.168.0.2 ping statastics --------
2 packets transmitted, 0 received, 100% loss, time 999ms

Why 2 packets are sent instead of 1 (specified) and why it only waits
for 999 ms instead of 2 seconds.

Even if I use: ping -c 5 -w 2 192.168.0.2, it has the same result. Here
I wanted to send 5 packets but, again 2 packets were sent?

What is wrong here? Please help me.
Thanks a lot

I use, ping -c 1 -w 2 192.168.0.2

If host is not connected, it fails correctly. BUT summary says.

PING 192.168.0.2 from 192.168.0.1 : 56(84) bytes of data

--------192.168.0.2 ping statastics --------
2 packets transmitted, 0 received, 100% loss, time 999ms

Why 2 packets are sent instead of 1 (specified) and why it only waits
for 999 ms instead of 2 seconds.

Even if I use: ping -c 5 -w 2 192.168.0.2, it has the same result. Here
I wanted to send 5 packets but, again 2 packets were sent?

What is wrong here? Please help me.
Thanks a lot

Specify a timeout, in seconds, before ping exits regardless of how  many
packets have  been  sent  or received. In this case ping does not stop
after count packet are sent, it waits either for deadline expire or until
count probes are  answered or for some error notification from network.

I think you want to use:

-t ttl

Set the IP Time to Live.

--
  Living on Earth may be expensive,
  but it includes an annual free trip around the sun.

but -t doesn't work. I just want to wait for 2 seconds to get my reply
packets back. If not, I want to exit out.

Let me know please

The two vs one may simply be an OBO bug (off by one) - send one right
away, send one after the first timeout. (Double check that the manpage
for your ping's -c option matches your expectation of course :) The
999ms could be that the ping command got some other indication that
the response wasn't going to arrive - sometimes I've seen messages
elsewhere that imply that ARP sent something up the stack that said it
couldn't map the IP to a MAC - perhaps that makes it all the way to
ping which then "knows" that waiting for the full timeout is
pointless.  

Might be worthwhile doing a system call trace of the ping command.

Might check the ARP tables and the ARP timeouts.  If the system is not
up, and is "local" then the gating factor might be ARP not ping.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

There are several versions of ping, so results vary depending on
which set of bugs you encounter!

In your case, the -w option invalidates the -c option.  If you
have a -w option, the -c option is ignored.  That will not
likely cause you any real problems though.

The other bug is an off-by-one in the reported number of packets
sent.  Again, probably not really a problem.

Offhand I would guess that both of those bugs are easy to fix,
hence if you can find out who did that version of ping it might
be possible to get something changed.

--
Floyd L. Davidson            <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         fl...@apaflo.com