ping RETURN codes

[Bill McNAMARA_1]

Hi all,

a return code from ping is annoying one of my scripts..

Have a look:

pereal - /home/trsh # ping 1.2.3.4 -n 3
PING 1.2.3.4: 64 byte packets

----1.2.3.4 PING Statistics----
3 packets transmitted, 0 packets received, 100% packet loss
pereal - /home/trsh # echo $?
0


pereal - /home/trsh # what /etc/ping
/etc/ping:
PHNE_16158 ping.c $Revision: 1.8.119.5 $ $Date: 98/07/23 14:27:01 $
NET: Version: B.11.00 $Date: 97/10/15 10:44:23 $

[Stefan Farrelly · Accepted solution]

ping has always been non-existant in returing any error codes apart from 0. Instead scripts I use to see if something is pingable all grep for "100% packet loss" to see if it worked or not.

[Steven Sim Kok Leong]

Hi,

I agree with Stefan. Have a conditional statement to set the return code, like this:

# if ping 1.2.3.4 -n 3 | grep '100%' >/dev/null 2>&1 ; then exit 1; else exit 0 ; fi
# echo $?
1

Hope this helps. Regards.

Steven Sim Kok Leong

[Bill McNAMARA_1]

ping returns 1 though if I do it this way:

pereal - /home/trsh # /etc/ping bobby -n 1
/etc/ping: unknown host bobby
pereal - /home/trsh # echo $?
1


Anyway, thanks for the info!
I'll incorporate that!

Later,
Bill

[Frank Slootweg]

Moral:

If for a particular command, i.e. ping(1M) in this case, "RETURN VALUE" is not *documented*, then don't assume it is set (to some meaningful, reliable, etc. value). I.e. the right approach is somthingike Steven has suggested.

If you want to blame someone, then blame the AUTHOR! :-)

[Bill Hassell]

ping is like many network commands such as ftp. The return code will be 0 if there is something valid to perform. The fact that one (or more) ping attempts failed is very different than a failure to get an IP address. In other words, ping will return a failure if the hostname is non-existant because ping can't even get started. And in that case, the error is not ping but DNS or /etc/hosts, or it may be an unreachable network address, none of which are ping's responsibility. But once there is a valid IP address, ping considers itself successful.

The fact that the remote end failed to respond correctly is problematic in terms of a single return code. The IP address may truly be unresponsive (the main reason we use ping) but it might work a few times and fail a few times, or (due to a duplicate IP) get a multiple returns for the same ping attempt, or there might be an excessive delay in getting the ping back.

So as mentioned, ping must be parsed in order to determine exactly what is happening.

[A. Clay Stephenson]

Hi Bill:

Here's one method that will give you a reliable
exit status (0 = good; non-zero bad like a good little program): This one pings and time outs in 5 seconds if no response.

ping.pl -t 5 remote_host
STAT=$?
if [ ${STAT} -eq 0 ]
then
echo "Good"
fi

Invoke it as ping.pl -u for full usage. Note, if you are using this script on a Windows box, you should comment out the alarm() function. It's not supported on Windows.

Regards, Clay

[Anu Mathew]

Hello Bill,

How about this way?

for system in `cat $WORK_DIR/criping.source`
do
if /etc/ping $system 64 1 > /dev/null
then
RET2="`echo $system` `/etc/ping $system 64 1 | grep bytes | awk {'print $6'}`"
echo $RET2 | grep -v time >> $WORK_DIR/criping.result
fi
done

Then proceed by [ -s $WORK_DIR/criping.result ].

You may want to run a loop for two runs, as ping may not sometimes succeed the first time.

Hope this helps,

Thanks

Anu Mathew

[Stefan Marquardt_1]

We have a open bug report to HP for that.
Use ping from 10.20 - that works fine (we got this info from HP)
We got the binary from them because we only have 11.0

We wait since 1 year for the patch for 11.0