1.\" Copyright (c) 1985, 1991, 1993 2.\" The Regents of the University of California. All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 3. All advertising materials mentioning features or use of this software 13.\" must display the following acknowledgement: 14.\" This product includes software developed by the University of 15.\" California, Berkeley and its contributors. 16.\" 4. Neither the name of the University nor the names of its contributors 17.\" may be used to endorse or promote products derived from this software 18.\" without specific prior written permission. 19.\" 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" @(#)ping.8 8.2 (Berkeley) 12/11/93 33.\" $FreeBSD$ 34.\" 35.Dd December 11, 1993 36.Dt PING 8 37.Os BSD 4.3 38.Sh NAME 39.Nm ping 40.Nd send 41.Tn ICMP ECHO_REQUEST 42packets to network hosts 43.Sh SYNOPSIS 44.Nm ping 45.Op Fl adfnqrvLRQ 46.Op Fl c Ar count 47.Op Fl i Ar wait 48.Op Fl I Ar interface 49.Op Fl l Ar preload 50.Op Fl p Ar pattern 51.Op Fl s Ar packetsize 52.Op Fl T Ar ttl 53.Ar host 54.Sh DESCRIPTION 55.Nm Ping 56uses the 57.Tn ICMP 58protocol's mandatory 59.Tn ECHO_REQUEST 60datagram to elicit an 61.Tn ICMP ECHO_RESPONSE 62from a host or gateway. 63.Tn ECHO_REQUEST 64datagrams (``pings'') have an IP and 65.Tn ICMP 66header, 67followed by a 68.Dq struct timeval 69and then an arbitrary number of ``pad'' bytes used to fill out the 70packet. 71The options are as follows: 72.Bl -tag -width Ds 73.It Fl a 74Audible. Include a bell (ASCII 0x07) character in the output when any packet 75is received. This option is ignored if other format options are present. 76.It Fl c Ar count 77Stop after sending (and receiving) 78.Ar count 79.Tn ECHO_RESPONSE 80packets. 81.It Fl d 82Set the 83.Dv SO_DEBUG 84option on the socket being used. 85.It Fl f 86Flood ping. 87Outputs packets as fast as they come back or one hundred times per second, 88whichever is more. 89For every 90.Tn ECHO_REQUEST 91sent a period ``.'' is printed, while for every 92.Tn ECHO_REPLY 93received a backspace is printed. 94This provides a rapid display of how many packets are being dropped. 95Only the super-user may use this option. 96.Bf -emphasis 97This can be very hard on a network and should be used with caution. 98.Ef 99.It Fl i Ar wait 100Wait 101.Ar wait 102seconds 103.Em between sending each packet . 104The default is to wait for one second between each packet. 105This option is incompatible with the 106.Fl f 107option. 108.It Fl I Ar interface 109Source multicast packets with the given interface address. 110This flag only applies if the ping destination is a multicast address. 111.It Fl l Ar preload 112If 113.Ar preload 114is specified, 115.Nm ping 116sends that many packets as fast as possible before falling into its normal 117mode of behavior. 118.It Fl L 119Suppress loopback of multicast packets. 120This flag only applies if the ping destination is a multicast address. 121.It Fl n 122Numeric output only. 123No attempt will be made to lookup symbolic names for host addresses. 124.It Fl p Ar pattern 125You may specify up to 16 ``pad'' bytes to fill out the packet you send. 126This is useful for diagnosing data-dependent problems in a network. 127For example, 128.Dq Li \-p ff 129will cause the sent packet to be filled with all 130ones. 131.It Fl Q 132Somewhat quiet output. 133Don't display ICMP error messages that are in response to our query messages. 134Originally, the 135.Fl v 136flag was required to display such errors, but 137.Fl v 138displays all ICMP error messages. On a busy machine, this output can 139be overbearing. Without the 140.Fl Q 141flag, 142.Nm 143prints out any ICMP error messages caused by its own ECHO_REQUEST 144messages. 145.It Fl q 146Quiet output. 147Nothing is displayed except the summary lines at startup time and 148when finished. 149.It Fl R 150Record route. 151Includes the 152.Tn RECORD_ROUTE 153option in the 154.Tn ECHO_REQUEST 155packet and displays 156the route buffer on returned packets. 157Note that the IP header is only large enough for nine such routes. 158Many hosts ignore or discard this option. 159.It Fl r 160Bypass the normal routing tables and send directly to a host on an attached 161network. 162If the host is not on a directly-attached network, an error is returned. 163This option can be used to ping a local host through an interface 164that has no route through it (e.g., after the interface was dropped by 165.Xr routed 8 ) . 166.It Fl s Ar packetsize 167Specifies the number of data bytes to be sent. 168The default is 56, which translates into 64 169.Tn ICMP 170data bytes when combined 171with the 8 bytes of 172.Tn ICMP 173header data. 174.It Fl T Ar ttl 175Set the IP Time To Live for multicasted packets. 176This flag only applies if the ping destination is a multicast address. 177.It Fl v 178Verbose output. 179.Tn ICMP 180packets other than 181.Tn ECHO_RESPONSE 182that are received are listed. 183.El 184.Pp 185When using 186.Nm ping 187for fault isolation, it should first be run on the local host, to verify 188that the local network interface is up and running. 189Then, hosts and gateways further and further away should be ``pinged''. 190Round-trip times and packet loss statistics are computed. 191If duplicate packets are received, they are not included in the packet 192loss calculation, although the round trip time of these packets is used 193in calculating the minimum/average/maximum round-trip time numbers. 194When the specified number of packets have been sent (and received) or 195if the program is terminated with a 196.Dv SIGINT , 197a brief summary is displayed. 198.Pp 199This program is intended for use in network testing, measurement and 200management. 201Because of the load it can impose on the network, it is unwise to use 202.Nm ping 203during normal operations or from automated scripts. 204.Sh ICMP PACKET DETAILS 205An IP header without options is 20 bytes. 206An 207.Tn ICMP 208.Tn ECHO_REQUEST 209packet contains an additional 8 bytes worth 210of 211.Tn ICMP 212header followed by an arbitrary amount of data. 213When a 214.Ar packetsize 215is given, this indicated the size of this extra piece of data (the 216default is 56). 217Thus the amount of data received inside of an IP packet of type 218.Tn ICMP 219.Tn ECHO_REPLY 220will always be 8 bytes more than the requested data space 221(the 222.Tn ICMP 223header). 224.Pp 225If the data space is at least eight bytes large, 226.Nm ping 227uses the first eight bytes of this space to include a timestamp which 228it uses in the computation of round trip times. 229If less than eight bytes of pad are specified, no round trip times are 230given. 231.Sh DUPLICATE AND DAMAGED PACKETS 232.Nm Ping 233will report duplicate and damaged packets. 234Duplicate packets should never occur when pinging a unicast address, 235and seem to be caused by 236inappropriate link-level retransmissions. 237Duplicates may occur in many situations and are rarely (if ever) a 238good sign, although the presence of low levels of duplicates may not 239always be cause for alarm. 240Duplicates are expected when pinging a broadcast or multicast address, 241since they are not really duplicates but replies from different hosts 242to the same request. 243.Pp 244Damaged packets are obviously serious cause for alarm and often 245indicate broken hardware somewhere in the 246.Nm ping 247packet's path (in the network or in the hosts). 248.Sh TRYING DIFFERENT DATA PATTERNS 249The (inter)network layer should never treat packets differently depending 250on the data contained in the data portion. 251Unfortunately, data-dependent problems have been known to sneak into 252networks and remain undetected for long periods of time. 253In many cases the particular pattern that will have problems is something 254that doesn't have sufficient ``transitions'', such as all ones or all 255zeros, or a pattern right at the edge, such as almost all zeros. 256It isn't necessarily enough to specify a data pattern of all zeros (for 257example) on the command line because the pattern that is of interest is 258at the data link level, and the relationship between what you type and 259what the controllers transmit can be complicated. 260.Pp 261This means that if you have a data-dependent problem you will probably 262have to do a lot of testing to find it. 263If you are lucky, you may manage to find a file that either can't be sent 264across your network or that takes much longer to transfer than other 265similar length files. 266You can then examine this file for repeated patterns that you can test 267using the 268.Fl p 269option of 270.Nm ping . 271.Sh TTL DETAILS 272The 273.Tn TTL 274value of an IP packet represents the maximum number of IP routers 275that the packet can go through before being thrown away. 276In current practice you can expect each router in the Internet to decrement 277the 278.Tn TTL 279field by exactly one. 280.Pp 281The 282.Tn TCP/IP 283specification states that the 284.Tn TTL 285field for 286.Tn TCP 287packets should 288be set to 60, but many systems use smaller values (4.3 289.Tn BSD 290uses 30, 4.2 used 29115). 292.Pp 293The maximum possible value of this field is 255, and most Unix systems set 294the 295.Tn TTL 296field of 297.Tn ICMP ECHO_REQUEST 298packets to 255. 299This is why you will find you can ``ping'' some hosts, but not reach them 300with 301.Xr telnet 1 302or 303.Xr ftp 1 . 304.Pp 305In normal operation ping prints the ttl value from the packet it receives. 306When a remote system receives a ping packet, it can do one of three things 307with the 308.Tn TTL 309field in its response: 310.Bl -bullet 311.It 312Not change it; this is what Berkeley Unix systems did before the 313.Bx 4.3 tahoe 314release. 315In this case the 316.Tn TTL 317value in the received packet will be 255 minus the 318number of routers in the round-trip path. 319.It 320Set it to 255; this is what current Berkeley Unix systems do. 321In this case the 322.Tn TTL 323value in the received packet will be 255 minus the 324number of routers in the path 325.Xr from 326the remote system 327.Em to 328the 329.Nm ping Ns Em ing 330host. 331.It 332Set it to some other value. 333Some machines use the same value for 334.Tn ICMP 335packets that they use for 336.Tn TCP 337packets, for example either 30 or 60. 338Others may use completely wild values. 339.El 340.Sh BUGS 341Many Hosts and Gateways ignore the 342.Tn RECORD_ROUTE 343option. 344.Pp 345The maximum IP header length is too small for options like 346.Tn RECORD_ROUTE 347to 348be completely useful. 349There's not much that can be done about this, however. 350.Pp 351Flood pinging is not recommended in general, and flood pinging the 352broadcast address should only be done under very controlled conditions. 353.Pp 354The 355.Fl v 356option is not worth much on busy hosts. 357.Sh SEE ALSO 358.Xr netstat 1 , 359.Xr ifconfig 8 , 360.Xr routed 8 361.Sh HISTORY 362The 363.Nm 364command appeared in 365.Bx 4.3 . 366