|
|
1.1 root 1: .\" Copyright (c) 1985 The Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted provided
5: .\" that: (1) source distributions retain this entire copyright notice and
6: .\" comment, and (2) distributions including binaries display the following
7: .\" acknowledgement: ``This product includes software developed by the
8: .\" University of California, Berkeley and its contributors'' in the
9: .\" documentation or other materials provided with the distribution and in
10: .\" all advertising materials mentioning features or use of this software.
11: .\" Neither the name of the University nor the names of its contributors may
12: .\" be used to endorse or promote products derived from this software without
13: .\" specific prior written permission.
14: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
15: .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
16: .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
17: .\"
18: .\" @(#)ping.8 6.6 (Berkeley) 6/24/90
19: .\"
20: .TH PING 8 "June 24, 1990"
21: .UC 6
22: .SH NAME
23: ping \- send ICMP ECHO_REQUEST packets to network hosts
24: .SH SYNOPSIS
25: .B ping
26: [
27: .B -dfnqrvR
28: ][
29: .B -c
30: count][
31: .B -i
32: wait][
33: .B -l
34: preload][
35: .B -p
36: pattern][
37: .B -s
38: packetsize]
39: .SH DESCRIPTION
40: .I Ping
41: uses the
42: ICMP protocol's mandatory ECHO_REQUEST datagram to elicit an
43: ICMP ECHO_RESPONSE from a host or gateway.
44: ECHO_REQUEST datagrams (``pings'') have an IP and ICMP header,
45: followed by a
46: .I struct timeval
47: and then an arbitrary number of ``pad'' bytes used to fill out the
48: packet.
49: The options are as follows:
50: Other options are:
51: .TP
52: .I "-c count"
53: Stop after sending (and receiving)
54: .I count
55: ECHO_RESPONSE packets.
56: .TP
57: .I -d
58: Set the SO_DEBUG option on the socket being used.
59: .TP
60: .I -f
61: Flood ping.
62: Outputs packets as fast as they come back or one hundred times per second,
63: whichever is more.
64: For every ECHO_REQUEST sent a period ``.'' is printed, while for ever
65: ECHO_REPLY received a backspace is printed.
66: This provides a rapid display of how many packets are being dropped.
67: Only the super-user may use this option.
68: .I "This can be very hard on a network and should be used with caution."
69: .TP
70: .I "-i wait"
71: Wait
72: .I wait seconds between sending each packet.
73: The default is to wait for one second between each packet.
74: This option is incompatible with the
75: .I -f
76: option.
77: .TP
78: .I -l preload
79: If
80: .I preload
81: is specified,
82: .I ping
83: sends that many packets as fast as possible before falling into its normal
84: mode of behavior.
85: .TP
86: .I -n
87: Numeric output only.
88: No attempt will be made to lookup symbolic names for host addresses.
89: .TP
90: .I "-p pattern"
91: You may specify up to 16 ``pad'' bytes to fill out the packet you send.
92: This is useful for diagnosing data-dependent problems in a network.
93: For example, ``-p ff'' will cause the sent packet to be filled with all
94: ones.
95: .TP
96: .I -q
97: Quiet output.
98: Nothing is displayed except the summary lines at startup time and
99: when finished.
100: .TP
101: .B -R
102: Record route.
103: Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays
104: the route buffer on returned packets.
105: Note that the IP header is only large enough for nine such routes.
106: Many hosts ignore or discard this option.
107: .TP
108: .I -r
109: Bypass the normal routing tables and send directly to a host on an attached
110: network.
111: If the host is not on a directly-attached network, an error is returned.
112: This option can be used to ping a local host through an interface
113: that has no route through it (e.g., after the interface was dropped by
114: .IR routed (8)).
115: .TP
116: .I "-s packetsize"
117: Specifies the number of data bytes to be sent.
118: The default is 56, which translates into 64 ICMP data bytes when combined
119: with the 8 bytes of ICMP header data.
120: .TP
121: .I -v
122: Verbose output.
123: ICMP packets other than ECHO_RESPONSE that are received are listed.
124: .PP
125: When using
126: .I ping
127: for fault isolation, it should first be run on the local host, to verify
128: that the local network interface is up and running.
129: Then, hosts and gateways further and further away should be ``pinged''.
130: Round-trip times and packet loss statistics are computed.
131: If duplicate packets are received, they are not included in the packet
132: loss calculation, although the round trip time of these packets is used
133: in calculating the minimum/average/maximum round-trip time numbers.
134: When the specified number of packets have been sent (and received) or
135: if the program is terminated with a SIGINT, a brief summary is displayed.
136: .PP
137: This program is intended for use in network testing, measurement and
138: management.
139: Because of the load it can impose on the network, it is unwise to use
140: .I ping
141: during normal operations or from automated scripts.
142: .SH ICMP PACKET DETAILS
143: An IP header without options is 20 bytes.
144: An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth
145: of ICMP header followed by an arbitrary amount of data.
146: When a
147: .I packetsize
148: is given, this indicated the size of this extra piece of data (the
149: default is 56).
150: Thus the amount of data received inside of an IP packet of type ICMP
151: ECHO_REPLY will always be 8 bytes more than the requested data space
152: (the ICMP header).
153: .PP
154: If the data space is at least eight bytes large,
155: .I ping
156: uses the first eight bytes of this space to include a timestamp which
157: it uses in the computation of round trip times.
158: If less than eight bytes of pad are specified, no round trip times are
159: given.
160: .SH DUPLICATE AND DAMAGED PACKETS
161: .I Ping
162: will report duplicate and damaged packets.
163: Duplicate packets should never occur, and seem to be caused by
164: inappropriate link-level retransmissions.
165: Duplicates may occur in many situations and are rarely (if ever) a
166: good sign, although the presence of low levels of duplicates may not
167: always be cause for alarm.
168: .PP
169: Damaged packets are obviously serious cause for alarm and often
170: indicate broken hardware somewhere in the
171: .I ping
172: packet's path (in the network or in the hosts).
173: .SH TRYING DIFFERENT DATA PATTERNS
174: The (inter)network layer should never treat packets differently depending
175: on the data contained in the data portion.
176: Unfortunately, data-dependent problems have been known to sneak into
177: networks and remain undetected for long periods of time.
178: In many cases the particular pattern that will have problems is something
179: that doesn't have sufficient ``transitions'', such as all ones or all
180: zeros, or a pattern right at the edge, such as almost all zeros.
181: It isn't necessarily enough to specify a data pattern of all zeros (for
182: example) on the command line because the pattern that is of interest is
183: at the data link level, and the relationship between what you type and
184: what the controllers transmit can be complicated.
185: .PP
186: This means that if you have a data-dependent problem you will probably
187: have to do a lot of testing to find it.
188: If you are lucky, you may manage to find a file that either can't be sent
189: across your network or that takes much longer to transfer than other
190: similar length files.
191: You can then examine this file for repeated patterns that you can test
192: using the \fI-p\fR option of \fIping\fR.
193: .SH TTL DETAILS
194: The TTL value of an IP packet represents the maximum number of IP routers
195: that the packet can go through before being thrown away.
196: In current practice you can expect each router in the Internet to decrement
197: the TTL field by exactly one.
198: .PP
199: The TCP/IP specification states that the TTL field for TCP packets should
200: be set to 60, but many systems use smaller values (4.3 BSD uses 30, 4.2 used
201: 15).
202: .PP
203: The maximum possible value of this field is 255, and most Unix systems set
204: the TTL field of ICMP ECHO_REQUEST packets to 255.
205: This is why you will find you can ``ping'' some hosts, but not reach them
206: with
207: .I telnet
208: or
209: .IR ftp .
210: .PP
211: In normal operation ping prints the ttl value from the packet it receives.
212: When a remote system receives a ping packet, it can do one of three things
213: with the TTL field in its response:
214: .TP
215: --
216: Not change it; this is what Berkeley Unix systems did before the 4.3BSD-tahoe
217: release.
218: In this case the TTL value in the received packet will be 255 minus the
219: number of routers in the round-trip path.
220: .TP
221: --
222: Set it to 255; this is what current Berkeley Unix systems do.
223: In this case the TTL value in the received packet will be 255 minus the
224: number of routers in the path
225: .I from
226: the remote system
227: .I to
228: the
229: .IR ping ing
230: host.
231: .TP
232: --
233: Set it to some other value.
234: Some machines use the same value for ICMP packets that they use for
235: TCP packets, for example either 30 or 60.
236: Others may use completely wild values.
237: .SH BUGS
238: Many Hosts and Gateways ignore the RECORD_ROUTE option.
239: .PP
240: The maximum IP header length is too small for options like RECORD_ROUTE to
241: be completely useful.
242: There's not much that that can be done about this, however.
243: .PP
244: Flood pinging is not recommended in general, and flood pinging the
245: broadcast address should only be done under very controlled conditions.
246: .SH SEE ALSO
247: netstat(1), ifconfig(8), routed(8)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.