PING(8)                                                   PING(8)


NAME
       ping - send ICMP ECHO_REQUEST packets to network hosts

SYNOPSIS
       /etc/ping  [ -dfnqrvR ][ -c count][ -i wait][ -l preload][
       -p pattern][ -s packetsize] [-h] host

DESCRIPTION
       The DARPA Internet is a large and complex  aggregation  of
       network  hardware, connected together by gateways.  Track-
       ing a single-point hardware or software failure can  often
       be  difficult.   Ping  uses  the ICMP protocol's mandatory
       ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from
       a  host  or  gateway.   ECHO_REQUEST datagrams (``pings'')
       have an IP and ICMP header, followed by a struct  timeval,
       and then an arbitrary number of ``pad'' bytes used to fill
       out the packet.  Default datagram length is 64 bytes,  but
       this  may  be  changed using the -s option.  Other options
       are:

       -?     Display verbose usage information.

       -d     Set the SO_DEBUG option on the socket being used.

       -f     Flood ping.  Outputs packets as fast as  they  come
              back  or one hundred times per second, whichever is
              more.  For every ECHO_REQUEST sent a period '.'  is
              printed,  while  for  ever  ECHO_REPLY  received  a
              backspace is printed.  This provides a  rapid  dis-
              play  of  how many packets are being dropped.  This
              can be very hard on a network and  should  be  used
              with caution.

       -h     You may use this flag to specify the host, or leave
              it off if the host is the last token on the command
              line.

       -n     Numeric  output  only.   No attempt will be made to
              lookup symbolic names for host addresses.

       -q     Quiet output.  Nothing is displayed except the sum-
              mary lines at the beginning and at the end.

       -r     Bypass  the normal routing tables and send directly
              to a host on an attached network.  If the  host  is
              not  on  a  directly-attached  network, an error is
              returned.  This option can be used to ping a  local
              host through an interface that has no route through
              it  (e.g.,  after  the  interface  was  dropped  by
              routed(8C) ).

       -v     Verbose    output.    ICMP   packets   other   than
              ECHO_RESPONSE that are received are listed.

       -R     Record Route.  Includes the RECORD_ROUTE option  in
              the  ECHO_REQUEST  packet  and  displays  the route
              buffer on  returned  packets.   Note  that  the  IP
              header  is  only large enough for nine such routes.
              Many hosts ignore or discard this option.

       -c count
              Stop after receiving count ECHO_RESPONSE packets.

       -i wait
              Wait wait seconds between sending each packet.  The
              default  is  to  wait  for  one second between each
              packet.  This option is incompatible  with  the  -f
              option.

       -l preload
              If  preload  is given, ping sends that many packets
              as fast as possible before falling into its  normal
              mode of behavior.

       -p pattern
              You  may  specify  up to 16 "pad" bytes to fill out
              the packet you send.  This is useful for diagnosing
              data-dependent problems in a network.  For example,
              "-p ff" will cause the sent  packet  to  be  filled
              with all ones.

       -s packetsize
              Specifies the number of data bytes to be sent.  The
              default is 56, which translates into 64  ICMP  data
              bytes when combined with the 8 bytes of ICMP header
              data.

       -w seconds
              Specifies  the  number  of  seconds  to  wait for a
              response, default is 10.

       When using ping for fault isolation, it  should  first  be
       run  on  the  local host, to verify that the local network
       interface is up and running.   Then,  hosts  and  gateways
       further and further away should be ``pinged''.  Ping sends
       one datagram per second (or per wait seconds), and  prints
       one  line  of output for every ECHO_RESPONSE returned.  If
       an optional count is given, only that number  of  requests
       is  sent.  Round-trip times and packet loss statistics are
       computed.  If duplicate packets are received, they are not
       included  in  the  packet  loss  calculation, although the
       round trip time of these packets is  used  in  calculating
       the minimun/average/maximum round-trip time numbers.  When
       all responses have been received or the program times  out
       (with  a count specified), or if the program is terminated
       with a SIGINT, a brief summary is displayed.

       This program is intended for use in network testing,  mea-
       surement  and management.  It should be used primarily for
       manual fault isolation.  Because  of  the  load  it  could
       impose  on  the  network,  it is unwise to use ping during
       normal operations or from automated scripts.


ICMP Packet Details
       An IP  header  without  options  is  20  bytes.   An  ICMP
       ECHO_REQUEST  packet  contains an additional 8 bytes worth
       of ICMP header followed by an arbitrary  amount  of  data.
       When  a  packetsize  is  given, this indicated the size of
       this extra blob of data (the default  is  56).   Thus  the
       amount  of  data  received  inside of an IP packet of type
       ICMP ECHO_REPLY will always  be  8  bytes  more  than  the
       requested data space (the ICMP header).

       If the data space is at least eight bytes large, ping uses
       the first eight bytes of this space to include a timestamp
       which  it  uses  in  the  computation of round trip times.
       This explains why if less than  eight  bytes  of  pad  are
       requested, no round trip times are given.

Duplicate and Damaged packets
       Ping will report duplicate and damaged packets.  Duplicate
       packets should never occur, and seem to be caused by inap-
       propriate link-level retransmissions.  The author has seen
       duplicates in many situations and has never known them  to
       be  a  good  thing, although the presence of low levels of
       duplicates may not always be  cause  for  alarm.   Network
       maintainers  ignore  them  at  their own risk as they have
       been known to be harbingers of severe network problems.

       Damaged packets are obviously serious cause for alarm  and
       most likely indicate broken hardware somewhere in the ping
       packet's path (in the network or in the hosts).

Trying Different Data Patterns
       It should go without saying that the (inter)network  layer
       should  never  treat  packets differently depending on the
       data contained in the data portion.  Unfortunately,  data-
       dependent  problems have been known to sneak into networks
       and remain undetected for long periods of time.   In  many
       cases  the  particular  pattern that will have problems is
       something that doesn't have "enough" transitions, such  as
       all  ones  or  all  zeros, or a pattern right at the edge,
       such as almost all zeros.  It isn't necessarily enough  to
       specify  a  data pattern of all zeros (for example) on the
       command line (as in -p 00), because the pattern that is of
       interest  is  at the data link level, and the relationship
       between what you type and what  the  controllers  transmit
       can be complicated.

       This  means  that if you have a data-dependent problem you
       will have to be prepared to do a lot of  testing  to  find
       it.   If you are lucky, you may manage to find a file that
       either can't be sent across your  network  or  that  takes
       much  longer  to transfer than other similar length files.
       You can then examine this file for repeated patterns  that
       you can test using the -p option of ping.


TTL Details
       The  TTL value of an IP packet represents the maximum num-
       ber of IP routers that the packet can  go  through  before
       being  thrown  away.   In  current practice you can expect
       each router in the Internet to decrement the TTL field  by
       exactly one.

       The  TCP/IP  specification says that the TTL field for TCP
       packets should be set to 60, but many systems use  smaller
       values (4.3 BSD uses 30, 4.2 used 15).

       The  maximum possible value of this field is 255, and most
       Unix systems set the TTL field of ICMP ECHO_REQUEST  pack-
       ets to 255.  This is why you will find you can "ping" some
       hosts, but not reach them with telnet or ftp.

       In normal operation ping prints the  ttl  value  from  the
       packet  it receives.  When a remote system receives a ping
       packet, it can do one of three things with the  TTL  field
       in its response:

       (1)    Not  change  it; this is what Berkeley Unix systems
              did until 4.3 BSD tahoe level  releases.   In  this
              case  the  TTL value in the received packet will be
              255 minus the number of routers in  the  round-trip
              path.

       (2)    Set  it  to 255; this is what Berkeley Unix systems
              have done since the 4.3  tahoe  release.   In  this
              case  the  TTL value in the received packet will be
              255 minus the number of routers in  the  path  from
              the remote system to the pinging host.

       (3)    Set  it to some other value.  Some machines use the
              same value for ICMP packets that they use  for  TCP
              packets,  for  example either 30 or 60.  Others may
              use completely wild values.

BUGS
       Many Hosts and Gateways ignore the RECORD_ROUTE option.

       The maximum IP header length is too small for options like
       RECORD_ROUTE  to  be  completely useful.  There's not much
       that we can do about that however.

       Flood pinging is not recommended  in  general,  and  flood
       pinging  the  broadcast  address should only be done under
       very controlled conditions.

AUTHOR
       Mike Muuss

SEE ALSO
       netstat(1), ifconfig(8C)



                           May 25, 1989                         4

