xref: /freebsd/sbin/ping/ping.8 (revision 4a0f765fbf09711e612e86fce8bb09ec43f482d9)
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