Deleted Added
sdiff udiff text old ( 22990 ) new ( 23247 )
full compact
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.\" $Id: ping.8,v 1.7 1997/02/22 14:33:06 peter Exp $
34.\"
35.Dd March 1, 1997
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;
158the
159.Xr traceroute 8
160command is usually better at determining the route packets take to a
161particular destination.
162Many hosts ignore or discard the
163.Tn RECORD_ROUTE
164option.
165.It Fl r
166Bypass the normal routing tables and send directly to a host on an attached
167network.
168If the host is not on a directly-attached network, an error is returned.
169This option can be used to ping a local host through an interface
170that has no route through it (e.g., after the interface was dropped by
171.Xr routed 8 ) .
172.It Fl s Ar packetsize
173Specifies the number of data bytes to be sent.
174The default is 56, which translates into 64
175.Tn ICMP
176data bytes when combined
177with the 8 bytes of
178.Tn ICMP
179header data.
180.It Fl T Ar ttl
181Set the IP Time To Live for multicasted packets.
182This flag only applies if the ping destination is a multicast address.
183.It Fl v
184Verbose output.
185.Tn ICMP
186packets other than
187.Tn ECHO_RESPONSE
188that are received are listed.
189.El
190.Pp
191When using
192.Nm ping
193for fault isolation, it should first be run on the local host, to verify
194that the local network interface is up and running.
195Then, hosts and gateways further and further away should be ``pinged''.
196Round-trip times and packet loss statistics are computed.
197If duplicate packets are received, they are not included in the packet
198loss calculation, although the round trip time of these packets is used
199in calculating the minimum/average/maximum round-trip time numbers.
200When the specified number of packets have been sent (and received) or
201if the program is terminated with a
202.Dv SIGINT ,
203a brief summary is displayed.
204.Pp
205This program is intended for use in network testing, measurement and
206management.
207Because of the load it can impose on the network, it is unwise to use
208.Nm ping
209during normal operations or from automated scripts.
210.Sh ICMP PACKET DETAILS
211An IP header without options is 20 bytes.
212An
213.Tn ICMP
214.Tn ECHO_REQUEST
215packet contains an additional 8 bytes worth
216of
217.Tn ICMP
218header followed by an arbitrary amount of data.
219When a
220.Ar packetsize
221is given, this indicated the size of this extra piece of data (the
222default is 56).
223Thus the amount of data received inside of an IP packet of type
224.Tn ICMP
225.Tn ECHO_REPLY
226will always be 8 bytes more than the requested data space
227(the
228.Tn ICMP
229header).
230.Pp
231If the data space is at least eight bytes large,
232.Nm ping
233uses the first eight bytes of this space to include a timestamp which
234it uses in the computation of round trip times.
235If less than eight bytes of pad are specified, no round trip times are
236given.
237.Sh DUPLICATE AND DAMAGED PACKETS
238.Nm Ping
239will report duplicate and damaged packets.
240Duplicate packets should never occur when pinging a unicast address,
241and seem to be caused by
242inappropriate link-level retransmissions.
243Duplicates may occur in many situations and are rarely (if ever) a
244good sign, although the presence of low levels of duplicates may not
245always be cause for alarm.
246Duplicates are expected when pinging a broadcast or multicast address,
247since they are not really duplicates but replies from different hosts
248to the same request.
249.Pp
250Damaged packets are obviously serious cause for alarm and often
251indicate broken hardware somewhere in the
252.Nm ping
253packet's path (in the network or in the hosts).
254.Sh TRYING DIFFERENT DATA PATTERNS
255The (inter)network layer should never treat packets differently depending
256on the data contained in the data portion.
257Unfortunately, data-dependent problems have been known to sneak into
258networks and remain undetected for long periods of time.
259In many cases the particular pattern that will have problems is something
260that doesn't have sufficient ``transitions'', such as all ones or all
261zeros, or a pattern right at the edge, such as almost all zeros.
262It isn't necessarily enough to specify a data pattern of all zeros (for
263example) on the command line because the pattern that is of interest is
264at the data link level, and the relationship between what you type and
265what the controllers transmit can be complicated.
266.Pp
267This means that if you have a data-dependent problem you will probably
268have to do a lot of testing to find it.
269If you are lucky, you may manage to find a file that either can't be sent
270across your network or that takes much longer to transfer than other
271similar length files.
272You can then examine this file for repeated patterns that you can test
273using the
274.Fl p
275option of
276.Nm ping .
277.Sh TTL DETAILS
278The
279.Tn TTL
280value of an IP packet represents the maximum number of IP routers
281that the packet can go through before being thrown away.
282In current practice you can expect each router in the Internet to decrement
283the
284.Tn TTL
285field by exactly one.
286.Pp
287The
288.Tn TCP/IP
289specification states that the
290.Tn TTL
291field for
292.Tn TCP
293packets should
294be set to 60, but many systems use smaller values (4.3
295.Tn BSD
296uses 30, 4.2 used
29715).
298.Pp
299The maximum possible value of this field is 255, and most Unix systems set
300the
301.Tn TTL
302field of
303.Tn ICMP ECHO_REQUEST
304packets to 255.
305This is why you will find you can ``ping'' some hosts, but not reach them
306with
307.Xr telnet 1
308or
309.Xr ftp 1 .
310.Pp
311In normal operation ping prints the ttl value from the packet it receives.
312When a remote system receives a ping packet, it can do one of three things
313with the
314.Tn TTL
315field in its response:
316.Bl -bullet
317.It
318Not change it; this is what Berkeley Unix systems did before the
319.Bx 4.3 tahoe
320release.
321In this case the
322.Tn TTL
323value in the received packet will be 255 minus the
324number of routers in the round-trip path.
325.It
326Set it to 255; this is what current Berkeley Unix systems do.
327In this case the
328.Tn TTL
329value in the received packet will be 255 minus the
330number of routers in the path
331.Xr from
332the remote system
333.Em to
334the
335.Nm ping Ns Em ing
336host.
337.It
338Set it to some other value.
339Some machines use the same value for
340.Tn ICMP
341packets that they use for
342.Tn TCP
343packets, for example either 30 or 60.
344Others may use completely wild values.
345.El
346.Sh RETURN VALUES
347The
348.Nm ping
349command returns an exit status of zero if at least one response was
350heard from the specified
351.Ar host ;
352a status of two if the transmission was successful but no responses
353were received; or another value
354.Pq from Aq Pa sysexits.h
355if an error occurred.
356.Sh SEE ALSO
357.Xr netstat 1 ,
358.Xr ifconfig 8 ,
359.Xr routed 8 ,
360.Xr traceroute 8
361.Sh HISTORY
362The
363.Nm
364command appeared in
365.Bx 4.3 .
366.Sh AUTHORS
367The original
368.Nm
369command was written by Mike Muuss while at the US Army Ballistics
370Research Laboratory.
371.Sh BUGS
372Many Hosts and Gateways ignore the
373.Tn RECORD_ROUTE
374option.
375.Pp
376The maximum IP header length is too small for options like
377.Tn RECORD_ROUTE
378to
379be completely useful.
380There's not much that can be done about this, however.
381.Pp
382Flood pinging is not recommended in general, and flood pinging the
383broadcast address should only be done under very controlled conditions.
384.Pp
385The
386.Fl v
387option is not worth much on busy hosts.