Commit | Line | Data |
---|---|---|
6dca1d21 JB |
1 | Submitted By: Jim Gifford <jim at cross-lfs dot org> |
2 | Date: 2009-02-18 | |
3 | Initial Package Version: s20071127 | |
4 | Upstream Status: Unknown | |
5 | Origin: Jim Gifford | |
6 | Description: Provides the man pages (adding docbook2man with all its | |
7 | dependencies would be a major addition to the book, so I built it | |
8 | -once- on a completed system and saved the data). | |
9 | ||
10 | diff -Naur doc/arping.8 doc/arping.8 | |
11 | --- doc/arping.8 1969-12-31 16:00:00.000000000 -0800 | |
12 | +++ doc/arping.8 2009-02-18 23:20:33.249183964 -0800 | |
13 | @@ -0,0 +1,110 @@ | |
14 | +.\" This manpage has been automatically generated by docbook2man | |
15 | +.\" from a DocBook document. This tool can be found at: | |
16 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> | |
17 | +.\" Please send any bug reports, improvements, comments, patches, | |
18 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. | |
19 | +.TH "ARPING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" | |
20 | +.SH NAME | |
21 | +arping \- send ARP REQUEST to a neighbour host | |
22 | +.SH SYNOPSIS | |
23 | + | |
24 | +\fBarping\fR [\fB-AbDfhqUV\fR] [\fB-c \fIcount\fB\fR] [\fB-w \fIdeadline\fB\fR] [\fB-s \fIsource\fB\fR] \fB-I \fIinterface\fB\fR \fB\fIdestination\fB\fR | |
25 | + | |
26 | +.SH "DESCRIPTION" | |
27 | +.PP | |
28 | +Ping \fIdestination\fR on device \fIinterface\fR by ARP packets, | |
29 | +using source address \fIsource\fR. | |
30 | +.SH "OPTIONS" | |
31 | +.TP | |
32 | +\fB-A\fR | |
33 | +The same as \fB-U\fR, but ARP REPLY packets used instead | |
34 | +of ARP REQUEST. | |
35 | +.TP | |
36 | +\fB-b\fR | |
37 | +Send only MAC level broadcasts. Normally \fBarping\fR starts | |
38 | +from sending broadcast, and switch to unicast after reply received. | |
39 | +.TP | |
40 | +\fB-c \fIcount\fB\fR | |
41 | +Stop after sending \fIcount\fR ARP REQUEST | |
42 | +packets. With | |
43 | +\fIdeadline\fR | |
44 | +option, \fBarping\fR waits for | |
45 | +\fIcount\fR ARP REPLY packets, until the timeout expires. | |
46 | +.TP | |
47 | +\fB-D\fR | |
48 | +Duplicate address detection mode (DAD). See | |
49 | +RFC2131, 4.4.1. | |
50 | +Returns 0, if DAD succeeded i.e. no replies are received | |
51 | +.TP | |
52 | +\fB-f\fR | |
53 | +Finish after the first reply confirming that target is alive. | |
54 | +.TP | |
55 | +\fB-I \fIinterface\fB\fR | |
56 | +Name of network device where to send ARP REQUEST packets. This option | |
57 | +is required. | |
58 | +.TP | |
59 | +\fB-h\fR | |
60 | +Print help page and exit. | |
61 | +.TP | |
62 | +\fB-q\fR | |
63 | +Quiet output. Nothing is displayed. | |
64 | +.TP | |
65 | +\fB-s \fIsource\fB\fR | |
66 | +IP source address to use in ARP packets. | |
67 | +If this option is absent, source address is: | |
68 | +.RS | |
69 | +.TP 0.2i | |
70 | +\(bu | |
71 | +In DAD mode (with option \fB-D\fR) set to 0.0.0.0. | |
72 | +.TP 0.2i | |
73 | +\(bu | |
74 | +In Unsolicited ARP mode (with options \fB-U\fR or \fB-A\fR) | |
75 | +set to \fIdestination\fR. | |
76 | +.TP 0.2i | |
77 | +\(bu | |
78 | +Otherwise, it is calculated from routing tables. | |
79 | +.RE | |
80 | +.TP | |
81 | +\fB-U\fR | |
82 | +Unsolicited ARP mode to update neighbours' ARP caches. | |
83 | +No replies are expected. | |
84 | +.TP | |
85 | +\fB-V\fR | |
86 | +Print version of the program and exit. | |
87 | +.TP | |
88 | +\fB-w \fIdeadline\fB\fR | |
89 | +Specify a timeout, in seconds, before | |
90 | +\fBarping\fR | |
91 | +exits regardless of how many | |
92 | +packets have been sent or received. In this case | |
93 | +\fBarping\fR | |
94 | +does not stop after | |
95 | +\fIcount\fR | |
96 | +packet are sent, it waits either for | |
97 | +\fIdeadline\fR | |
98 | +expire or until | |
99 | +\fIcount\fR | |
100 | +probes are answered. | |
101 | +.SH "SEE ALSO" | |
102 | +.PP | |
103 | +\fBping\fR(8), | |
104 | +\fBclockdiff\fR(8), | |
105 | +\fBtracepath\fR(8). | |
106 | +.SH "AUTHOR" | |
107 | +.PP | |
108 | +\fBarping\fR was written by | |
109 | +Alexey Kuznetsov | |
110 | +<kuznet@ms2.inr.ac.ru>. | |
111 | +It is now maintained by | |
112 | +YOSHIFUJI Hideaki | |
113 | +<yoshfuji@skbuff.net>. | |
114 | +.SH "SECURITY" | |
115 | +.PP | |
116 | +\fBarping\fR requires CAP_NET_RAWIO capability | |
117 | +to be executed. It is not recommended to be used as set-uid root, | |
118 | +because it allows user to modify ARP caches of neighbour hosts. | |
119 | +.SH "AVAILABILITY" | |
120 | +.PP | |
121 | +\fBarping\fR is part of \fIiputils\fR package | |
122 | +and the latest versions are available in source form at | |
123 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. | |
124 | diff -Naur doc/clockdiff.8 doc/clockdiff.8 | |
125 | --- doc/clockdiff.8 1969-12-31 16:00:00.000000000 -0800 | |
126 | +++ doc/clockdiff.8 2009-02-18 23:20:33.249183964 -0800 | |
127 | @@ -0,0 +1,81 @@ | |
128 | +.\" This manpage has been automatically generated by docbook2man | |
129 | +.\" from a DocBook document. This tool can be found at: | |
130 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> | |
131 | +.\" Please send any bug reports, improvements, comments, patches, | |
132 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. | |
133 | +.TH "CLOCKDIFF" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" | |
134 | +.SH NAME | |
135 | +clockdiff \- measure clock difference between hosts | |
136 | +.SH SYNOPSIS | |
137 | + | |
138 | +\fBclockdiff\fR [\fB-o\fR] [\fB-o1\fR] \fB\fIdestination\fB\fR | |
139 | + | |
140 | +.SH "DESCRIPTION" | |
141 | +.PP | |
142 | +\fBclockdiff\fR Measures clock difference between us and | |
143 | +\fIdestination\fR with 1 msec resolution using ICMP TIMESTAMP | |
144 | +[2] | |
145 | +packets or, optionally, IP TIMESTAMP option | |
146 | +[3] | |
147 | +option added to ICMP ECHO. | |
148 | +[1] | |
149 | +.SH "OPTIONS" | |
150 | +.TP | |
151 | +\fB-o\fR | |
152 | +Use IP TIMESTAMP with ICMP ECHO instead of ICMP TIMESTAMP | |
153 | +messages. It is useful with some destinations, which do not support | |
154 | +ICMP TIMESTAMP (f.e. Solaris <2.4). | |
155 | +.TP | |
156 | +\fB-o1\fR | |
157 | +Slightly different form of \fB-o\fR, namely it uses three-term | |
158 | +IP TIMESTAMP with prespecified hop addresses instead of four term one. | |
159 | +What flavor works better depends on target host. Particularly, | |
160 | +\fB-o\fR is better for Linux. | |
161 | +.SH "WARNINGS" | |
162 | +.TP 0.2i | |
163 | +\(bu | |
164 | +Some nodes (Cisco) use non-standard timestamps, which is allowed | |
165 | +by RFC, but makes timestamps mostly useless. | |
166 | +.TP 0.2i | |
167 | +\(bu | |
168 | +Some nodes generate messed timestamps (Solaris>2.4), when | |
169 | +run \fBxntpd\fR. Seems, its IP stack uses a corrupted clock source, | |
170 | +which is synchronized to time-of-day clock periodically and jumps | |
171 | +randomly making timestamps mostly useless. Good news is that you can | |
172 | +use NTP in this case, which is even better. | |
173 | +.TP 0.2i | |
174 | +\(bu | |
175 | +\fBclockdiff\fR shows difference in time modulo 24 days. | |
176 | +.SH "SEE ALSO" | |
177 | +.PP | |
178 | +\fBping\fR(8), | |
179 | +\fBarping\fR(8), | |
180 | +\fBtracepath\fR(8). | |
181 | +.SH "REFERENCES" | |
182 | +.PP | |
183 | +[1] ICMP ECHO, | |
184 | +RFC0792, page 14. | |
185 | +.PP | |
186 | +[2] ICMP TIMESTAMP, | |
187 | +RFC0792, page 16. | |
188 | +.PP | |
189 | +[3] IP TIMESTAMP option, | |
190 | +RFC0791, 3.1, page 16. | |
191 | +.SH "AUTHOR" | |
192 | +.PP | |
193 | +\fBclockdiff\fR was compiled by | |
194 | +Alexey Kuznetsov | |
195 | +<kuznet@ms2.inr.ac.ru>. It was based on code borrowed | |
196 | +from BSD \fBtimed\fR daemon. | |
197 | +It is now maintained by | |
198 | +YOSHIFUJI Hideaki | |
199 | +<yoshfuji@skbuff.net>. | |
200 | +.SH "SECURITY" | |
201 | +.PP | |
202 | +\fBclockdiff\fR requires CAP_NET_RAWIO capability | |
203 | +to be executed. It is safe to be used as set-uid root. | |
204 | +.SH "AVAILABILITY" | |
205 | +.PP | |
206 | +\fBclockdiff\fR is part of \fIiputils\fR package | |
207 | +and the latest versions are available in source form at | |
208 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. | |
209 | diff -Naur doc/ping.8 doc/ping.8 | |
210 | --- doc/ping.8 1969-12-31 16:00:00.000000000 -0800 | |
211 | +++ doc/ping.8 2009-02-18 23:20:33.249183964 -0800 | |
212 | @@ -0,0 +1,332 @@ | |
213 | +.\" This manpage has been automatically generated by docbook2man | |
214 | +.\" from a DocBook document. This tool can be found at: | |
215 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> | |
216 | +.\" Please send any bug reports, improvements, comments, patches, | |
217 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. | |
218 | +.TH "PING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" | |
219 | +.SH NAME | |
220 | +ping, ping6 \- send ICMP ECHO_REQUEST to network hosts | |
221 | +.SH SYNOPSIS | |
222 | + | |
223 | +\fBping\fR [\fB-LRUbdfnqrvVaAB\fR] [\fB-c \fIcount\fB\fR] [\fB-i \fIinterval\fB\fR] [\fB-l \fIpreload\fB\fR] [\fB-p \fIpattern\fB\fR] [\fB-s \fIpacketsize\fB\fR] [\fB-t \fIttl\fB\fR] [\fB-w \fIdeadline\fB\fR] [\fB-F \fIflowlabel\fB\fR] [\fB-I \fIinterface\fB\fR] [\fB-M \fIhint\fB\fR] [\fB-Q \fItos\fB\fR] [\fB-S \fIsndbuf\fB\fR] [\fB-T \fItimestamp option\fB\fR] [\fB-W \fItimeout\fB\fR] [\fB\fIhop\fB\fR\fI ...\fR] \fB\fIdestination\fB\fR | |
224 | + | |
225 | +.SH "DESCRIPTION" | |
226 | +.PP | |
227 | +\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST | |
228 | +datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. | |
229 | +ECHO_REQUEST datagrams (``pings'') have an IP and ICMP | |
230 | +header, followed by a struct timeval and then an arbitrary | |
231 | +number of ``pad'' bytes used to fill out the packet. | |
232 | +.SH "OPTIONS" | |
233 | +.TP | |
234 | +\fB-a\fR | |
235 | +Audible ping. | |
236 | +.TP | |
237 | +\fB-A\fR | |
238 | +Adaptive ping. Interpacket interval adapts to round-trip time, so that | |
239 | +effectively not more than one (or more, if preload is set) unanswered probes | |
240 | +present in the network. Minimal interval is 200msec for not super-user. | |
241 | +On networks with low rtt this mode is essentially equivalent to flood mode. | |
242 | +.TP | |
243 | +\fB-b\fR | |
244 | +Allow pinging a broadcast address. | |
245 | +.TP | |
246 | +\fB-B\fR | |
247 | +Do not allow \fBping\fR to change source address of probes. | |
248 | +The address is bound to one selected when \fBping\fR starts. | |
249 | +.TP | |
250 | +\fB-c \fIcount\fB\fR | |
251 | +Stop after sending \fIcount\fR ECHO_REQUEST | |
252 | +packets. With | |
253 | +\fIdeadline\fR | |
254 | +option, \fBping\fR waits for | |
255 | +\fIcount\fR ECHO_REPLY packets, until the timeout expires. | |
256 | +.TP | |
257 | +\fB-d\fR | |
258 | +Set the SO_DEBUG option on the socket being used. | |
259 | +Essentially, this socket option is not used by Linux kernel. | |
260 | +.TP | |
261 | +\fB-F \fIflow label\fB\fR | |
262 | +Allocate and set 20 bit flow label on echo request packets. | |
263 | +(Only \fBping6\fR). If value is zero, kernel allocates random flow label. | |
264 | +.TP | |
265 | +\fB-f\fR | |
266 | +Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed, | |
267 | +while for ever ECHO_REPLY received a backspace is printed. | |
268 | +This provides a rapid display of how many packets are being dropped. | |
269 | +If interval is not given, it sets interval to zero and | |
270 | +outputs packets as fast as they come back or one hundred times per second, | |
271 | +whichever is more. | |
272 | +Only the super-user may use this option with zero interval. | |
273 | +.TP | |
274 | +\fB-i \fIinterval\fB\fR | |
275 | +Wait \fIinterval\fR seconds between sending each packet. | |
276 | +The default is to wait for one second between each packet normally, | |
277 | +or not to wait in flood mode. Only super-user may set interval | |
278 | +to values less 0.2 seconds. | |
279 | +.TP | |
280 | +\fB-I \fIinterface address\fB\fR | |
281 | +Set source address to specified interface address. Argument | |
282 | +may be numeric IP address or name of device. When pinging IPv6 | |
283 | +link-local address this option is required. | |
284 | +.TP | |
285 | +\fB-l \fIpreload\fB\fR | |
286 | +If \fIpreload\fR is specified, | |
287 | +\fBping\fR sends that many packets not waiting for reply. | |
288 | +Only the super-user may select preload more than 3. | |
289 | +.TP | |
290 | +\fB-L\fR | |
291 | +Suppress loopback of multicast packets. This flag only applies if the ping | |
292 | +destination is a multicast address. | |
293 | +.TP | |
294 | +\fB-n\fR | |
295 | +Numeric output only. | |
296 | +No attempt will be made to lookup symbolic names for host addresses. | |
297 | +.TP | |
298 | +\fB-p \fIpattern\fB\fR | |
299 | +You may specify up to 16 ``pad'' bytes to fill out the packet you send. | |
300 | +This is useful for diagnosing data-dependent problems in a network. | |
301 | +For example, \fB-p ff\fR will cause the sent packet | |
302 | +to be filled with all ones. | |
303 | +.TP | |
304 | +\fB-Q \fItos\fB\fR | |
305 | +Set Quality of Service -related bits in ICMP datagrams. | |
306 | +\fItos\fR can be either decimal or hex number. | |
307 | +Traditionally (RFC1349), these have been interpreted as: 0 for reserved | |
308 | +(currently being redefined as congestion control), 1-4 for Type of Service | |
309 | +and 5-7 for Precedence. | |
310 | +Possible settings for Type of Service are: minimal cost: 0x02, | |
311 | +reliability: 0x04, throughput: 0x08, low delay: 0x10. Multiple TOS bits | |
312 | +should not be set simultaneously. Possible settings for | |
313 | +special Precedence range from priority (0x20) to net control (0xe0). You | |
314 | +must be root (CAP_NET_ADMIN capability) to use Critical or | |
315 | +higher precedence value. You cannot set | |
316 | +bit 0x01 (reserved) unless ECN has been enabled in the kernel. | |
317 | +In RFC2474, these fields has been redefined as 8-bit Differentiated | |
318 | +Services (DS), consisting of: bits 0-1 of separate data (ECN will be used, | |
319 | +here), and bits 2-7 of Differentiated Services Codepoint (DSCP). | |
320 | +.TP | |
321 | +\fB-q\fR | |
322 | +Quiet output. | |
323 | +Nothing is displayed except the summary lines at startup time and | |
324 | +when finished. | |
325 | +.TP | |
326 | +\fB-R\fR | |
327 | +Record route. | |
328 | +Includes the RECORD_ROUTE option in the ECHO_REQUEST | |
329 | +packet and displays the route buffer on returned packets. | |
330 | +Note that the IP header is only large enough for nine such routes. | |
331 | +Many hosts ignore or discard this option. | |
332 | +.TP | |
333 | +\fB-r\fR | |
334 | +Bypass the normal routing tables and send directly to a host on an attached | |
335 | +interface. | |
336 | +If the host is not on a directly-attached network, an error is returned. | |
337 | +This option can be used to ping a local host through an interface | |
338 | +that has no route through it provided the option \fB-I\fR is also | |
339 | +used. | |
340 | +.TP | |
341 | +\fB-s \fIpacketsize\fB\fR | |
342 | +Specifies the number of data bytes to be sent. | |
343 | +The default is 56, which translates into 64 ICMP | |
344 | +data bytes when combined with the 8 bytes of ICMP header data. | |
345 | +.TP | |
346 | +\fB-S \fIsndbuf\fB\fR | |
347 | +Set socket sndbuf. If not specified, it is selected to buffer | |
348 | +not more than one packet. | |
349 | +.TP | |
350 | +\fB-t \fIttl\fB\fR | |
351 | +Set the IP Time to Live. | |
352 | +.TP | |
353 | +\fB-T \fItimestamp option\fB\fR | |
354 | +Set special IP timestamp options. | |
355 | +\fItimestamp option\fR may be either | |
356 | +\fItsonly\fR (only timestamps), | |
357 | +\fItsandaddr\fR (timestamps and addresses) or | |
358 | +\fItsprespec host1 [host2 [host3 [host4]]]\fR | |
359 | +(timestamp prespecified hops). | |
360 | +.TP | |
361 | +\fB-M \fIhint\fB\fR | |
362 | +Select Path MTU Discovery strategy. | |
363 | +\fIhint\fR may be either \fIdo\fR | |
364 | +(prohibit fragmentation, even local one), | |
365 | +\fIwant\fR (do PMTU discovery, fragment locally when packet size | |
366 | +is large), or \fIdont\fR (do not set DF flag). | |
367 | +.TP | |
368 | +\fB-U\fR | |
369 | +Print full user-to-user latency (the old behaviour). Normally | |
370 | +\fBping\fR | |
371 | +prints network round trip time, which can be different | |
372 | +f.e. due to DNS failures. | |
373 | +.TP | |
374 | +\fB-v\fR | |
375 | +Verbose output. | |
376 | +.TP | |
377 | +\fB-V\fR | |
378 | +Show version and exit. | |
379 | +.TP | |
380 | +\fB-w \fIdeadline\fB\fR | |
381 | +Specify a timeout, in seconds, before | |
382 | +\fBping\fR | |
383 | +exits regardless of how many | |
384 | +packets have been sent or received. In this case | |
385 | +\fBping\fR | |
386 | +does not stop after | |
387 | +\fIcount\fR | |
388 | +packet are sent, it waits either for | |
389 | +\fIdeadline\fR | |
390 | +expire or until | |
391 | +\fIcount\fR | |
392 | +probes are answered or for some error notification from network. | |
393 | +.TP | |
394 | +\fB-W \fItimeout\fB\fR | |
395 | +Time to wait for a response, in seconds. The option affects only timeout | |
396 | +in absense of any responses, otherwise \fBping\fR waits for two RTTs. | |
397 | +.PP | |
398 | +When using \fBping\fR for fault isolation, it should first be run | |
399 | +on the local host, to verify that the local network interface is up | |
400 | +and running. Then, hosts and gateways further and further away should be | |
401 | +``pinged''. Round-trip times and packet loss statistics are computed. | |
402 | +If duplicate packets are received, they are not included in the packet | |
403 | +loss calculation, although the round trip time of these packets is used | |
404 | +in calculating the minimum/average/maximum round-trip time numbers. | |
405 | +When the specified number of packets have been sent (and received) or | |
406 | +if the program is terminated with a | |
407 | +SIGINT, a brief summary is displayed. Shorter current statistics | |
408 | +can be obtained without termination of process with signal | |
409 | +SIGQUIT. | |
410 | +.PP | |
411 | +If \fBping\fR does not receive any reply packets at all it will | |
412 | +exit with code 1. If a packet | |
413 | +\fIcount\fR | |
414 | +and | |
415 | +\fIdeadline\fR | |
416 | +are both specified, and fewer than | |
417 | +\fIcount\fR | |
418 | +packets are received by the time the | |
419 | +\fIdeadline\fR | |
420 | +has arrived, it will also exit with code 1. | |
421 | +On other error it exits with code 2. Otherwise it exits with code 0. This | |
422 | +makes it possible to use the exit code to see if a host is alive or | |
423 | +not. | |
424 | +.PP | |
425 | +This program is intended for use in network testing, measurement and | |
426 | +management. | |
427 | +Because of the load it can impose on the network, it is unwise to use | |
428 | +\fBping\fR during normal operations or from automated scripts. | |
429 | +.SH "ICMP PACKET DETAILS" | |
430 | +.PP | |
431 | +An IP header without options is 20 bytes. | |
432 | +An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth | |
433 | +of ICMP header followed by an arbitrary amount of data. | |
434 | +When a \fIpacketsize\fR is given, this indicated the size of this | |
435 | +extra piece of data (the default is 56). Thus the amount of data received | |
436 | +inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes | |
437 | +more than the requested data space (the ICMP header). | |
438 | +.PP | |
439 | +If the data space is at least of size of struct timeval | |
440 | +\fBping\fR uses the beginning bytes of this space to include | |
441 | +a timestamp which it uses in the computation of round trip times. | |
442 | +If the data space is shorter, no round trip times are given. | |
443 | +.SH "DUPLICATE AND DAMAGED PACKETS" | |
444 | +.PP | |
445 | +\fBping\fR will report duplicate and damaged packets. | |
446 | +Duplicate packets should never occur, and seem to be caused by | |
447 | +inappropriate link-level retransmissions. | |
448 | +Duplicates may occur in many situations and are rarely (if ever) a | |
449 | +good sign, although the presence of low levels of duplicates may not | |
450 | +always be cause for alarm. | |
451 | +.PP | |
452 | +Damaged packets are obviously serious cause for alarm and often | |
453 | +indicate broken hardware somewhere in the | |
454 | +\fBping\fR packet's path (in the network or in the hosts). | |
455 | +.SH "TRYING DIFFERENT DATA PATTERNS" | |
456 | +.PP | |
457 | +The (inter)network layer should never treat packets differently depending | |
458 | +on the data contained in the data portion. | |
459 | +Unfortunately, data-dependent problems have been known to sneak into | |
460 | +networks and remain undetected for long periods of time. | |
461 | +In many cases the particular pattern that will have problems is something | |
462 | +that doesn't have sufficient ``transitions'', such as all ones or all | |
463 | +zeros, or a pattern right at the edge, such as almost all zeros. | |
464 | +It isn't necessarily enough to specify a data pattern of all zeros (for | |
465 | +example) on the command line because the pattern that is of interest is | |
466 | +at the data link level, and the relationship between what you type and | |
467 | +what the controllers transmit can be complicated. | |
468 | +.PP | |
469 | +This means that if you have a data-dependent problem you will probably | |
470 | +have to do a lot of testing to find it. | |
471 | +If you are lucky, you may manage to find a file that either can't be sent | |
472 | +across your network or that takes much longer to transfer than other | |
473 | +similar length files. | |
474 | +You can then examine this file for repeated patterns that you can test | |
475 | +using the \fB-p\fR option of \fBping\fR. | |
476 | +.SH "TTL DETAILS" | |
477 | +.PP | |
478 | +The TTL value of an IP packet represents the maximum number of IP routers | |
479 | +that the packet can go through before being thrown away. | |
480 | +In current practice you can expect each router in the Internet to decrement | |
481 | +the TTL field by exactly one. | |
482 | +.PP | |
483 | +The TCP/IP specification states that the TTL field for TCP | |
484 | +packets should be set to 60, but many systems use smaller values | |
485 | +(4.3 BSD uses 30, 4.2 used 15). | |
486 | +.PP | |
487 | +The maximum possible value of this field is 255, and most Unix systems set | |
488 | +the TTL field of ICMP ECHO_REQUEST packets to 255. | |
489 | +This is why you will find you can ``ping'' some hosts, but not reach them | |
490 | +with | |
491 | +\fBtelnet\fR(1) | |
492 | +or | |
493 | +\fBftp\fR(1). | |
494 | +.PP | |
495 | +In normal operation ping prints the ttl value from the packet it receives. | |
496 | +When a remote system receives a ping packet, it can do one of three things | |
497 | +with the TTL field in its response: | |
498 | +.TP 0.2i | |
499 | +\(bu | |
500 | +Not change it; this is what Berkeley Unix systems did before the | |
501 | +4.3BSD Tahoe release. In this case the TTL value in the received packet | |
502 | +will be 255 minus the number of routers in the round-trip path. | |
503 | +.TP 0.2i | |
504 | +\(bu | |
505 | +Set it to 255; this is what current Berkeley Unix systems do. | |
506 | +In this case the TTL value in the received packet will be 255 minus the | |
507 | +number of routers in the path \fBfrom\fR | |
508 | +the remote system \fBto\fR the \fBping\fRing host. | |
509 | +.TP 0.2i | |
510 | +\(bu | |
511 | +Set it to some other value. Some machines use the same value for | |
512 | +ICMP packets that they use for TCP packets, for example either 30 or 60. | |
513 | +Others may use completely wild values. | |
514 | +.SH "BUGS" | |
515 | +.TP 0.2i | |
516 | +\(bu | |
517 | +Many Hosts and Gateways ignore the RECORD_ROUTE option. | |
518 | +.TP 0.2i | |
519 | +\(bu | |
520 | +The maximum IP header length is too small for options like | |
521 | +RECORD_ROUTE to be completely useful. | |
522 | +There's not much that that can be done about this, however. | |
523 | +.TP 0.2i | |
524 | +\(bu | |
525 | +Flood pinging is not recommended in general, and flood pinging the | |
526 | +broadcast address should only be done under very controlled conditions. | |
527 | +.SH "SEE ALSO" | |
528 | +.PP | |
529 | +\fBnetstat\fR(1), | |
530 | +\fBifconfig\fR(8). | |
531 | +.SH "HISTORY" | |
532 | +.PP | |
533 | +The \fBping\fR command appeared in 4.3BSD. | |
534 | +.PP | |
535 | +The version described here is its descendant specific to Linux. | |
536 | +.SH "SECURITY" | |
537 | +.PP | |
538 | +\fBping\fR requires CAP_NET_RAWIO capability | |
539 | +to be executed. It may be used as set-uid root. | |
540 | +.SH "AVAILABILITY" | |
541 | +.PP | |
542 | +\fBping\fR is part of \fIiputils\fR package | |
543 | +and the latest versions are available in source form at | |
544 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. | |
545 | diff -Naur doc/rdisc.8 doc/rdisc.8 | |
546 | --- doc/rdisc.8 1969-12-31 16:00:00.000000000 -0800 | |
547 | +++ doc/rdisc.8 2009-02-18 23:20:33.249183964 -0800 | |
548 | @@ -0,0 +1,110 @@ | |
549 | +.\" This manpage has been automatically generated by docbook2man | |
550 | +.\" from a DocBook document. This tool can be found at: | |
551 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> | |
552 | +.\" Please send any bug reports, improvements, comments, patches, | |
553 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. | |
554 | +.TH "RDISC" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" | |
555 | +.SH NAME | |
556 | +rdisc \- network router discovery daemon | |
557 | +.SH SYNOPSIS | |
558 | + | |
559 | +\fBrdisc\fR [\fB-abdfstvV\fR] [\fB\fIsend_address\fB\fR] [\fB\fIreceive_address\fB\fR] | |
560 | + | |
561 | +.SH "DESCRIPTION" | |
562 | +.PP | |
563 | +\fBrdisc\fR implements client side of the ICMP router discover protocol. | |
564 | +\fBrdisc\fR is invoked at boot time to populate the network | |
565 | +routing tables with default routes. | |
566 | +.PP | |
567 | +\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address | |
568 | +(or \fIreceive_address\fR provided it is given) | |
569 | +for ROUTER_ADVERTISE messages from routers. The received | |
570 | +messages are handled by first ignoring those listed router addresses | |
571 | +with which the host does not share a network. Among the remaining addresses | |
572 | +the ones with the highest preference are selected as default routers | |
573 | +and a default route is entered in the kernel routing table | |
574 | +for each one of them. | |
575 | +.PP | |
576 | +Optionally, \fBrdisc\fR can avoid waiting for routers to announce | |
577 | +themselves by sending out a few ROUTER_SOLICITATION messages | |
578 | +to the ALL_ROUTERS (224.0.0.2) multicast address | |
579 | +(or \fIsend_address\fR provided it is given) | |
580 | +when it is started. | |
581 | +.PP | |
582 | +A timer is associated with each router address and the address will | |
583 | +no longer be considered for inclusion in the the routing tables if the | |
584 | +timer expires before a new | |
585 | +\fBadvertise\fR message is received from the router. | |
586 | +The address will also be excluded from consideration if the host receives an | |
587 | +\fBadvertise\fR | |
588 | +message with the preference being maximally negative. | |
589 | +.PP | |
590 | +Server side of router discovery protocol is supported by Cisco IOS | |
591 | +and by any more or less complete UNIX routing daemon, f.e \fBgated\fR. | |
592 | +.SH "OPTIONS" | |
593 | +.TP | |
594 | +\fB-a\fR | |
595 | +Accept all routers independently of the preference they have in their | |
596 | +\fBadvertise\fR messages. | |
597 | +Normally \fBrdisc\fR only accepts (and enters in the kernel routing | |
598 | +tables) the router or routers with the highest preference. | |
599 | +.TP | |
600 | +\fB-b\fR | |
601 | +Opposite to \fB-a\fR, i.e. install only router with the best | |
602 | +preference value. It is default behaviour. | |
603 | +.TP | |
604 | +\fB-d\fR | |
605 | +Send debugging messages to syslog. | |
606 | +.TP | |
607 | +\fB-f\fR | |
608 | +Run \fBrdisc\fR forever even if no routers are found. | |
609 | +Normally \fBrdisc\fR gives up if it has not received any | |
610 | +\fBadvertise\fR message after after soliciting three times, | |
611 | +in which case it exits with a non-zero exit code. | |
612 | +If \fB-f\fR is not specified in the first form then | |
613 | +\fB-s\fR must be specified. | |
614 | +.TP | |
615 | +\fB-s\fR | |
616 | +Send three \fBsolicitation\fR messages initially to quickly discover | |
617 | +the routers when the system is booted. | |
618 | +When \fB-s\fR is specified \fBrdisc\fR | |
619 | +exits with a non-zero exit code if it can not find any routers. | |
620 | +This can be overridden with the \fB-f\fR option. | |
621 | +.TP | |
622 | +\fB-t\fR | |
623 | +Test mode. Do not go to background. | |
624 | +.TP | |
625 | +\fB-v\fR | |
626 | +Be verbose i.e. send lots of debugging messages to syslog. | |
627 | +.TP | |
628 | +\fB-V\fR | |
629 | +Print version and exit. | |
630 | +.SH "HISTORY" | |
631 | +.PP | |
632 | +This program was developed by Sun Microsystems (see copyright | |
633 | +notice in source file). It was ported to Linux by | |
634 | +Alexey Kuznetsov | |
635 | +<kuznet@ms2.inr.ac.ru>. | |
636 | +It is now maintained by | |
637 | +YOSHIFUJI Hideaki | |
638 | +<yoshfuji@skbuff.net>. | |
639 | +.SH "SEE ALSO" | |
640 | +.PP | |
641 | +\fBicmp\fR(7), | |
642 | +\fBinet\fR(7), | |
643 | +\fBping\fR(8). | |
644 | +.SH "REFERENCES" | |
645 | +.PP | |
646 | +Deering, S.E.,ed "ICMP Router Discovery Messages", | |
647 | +RFC1256, Network Information Center, SRI International, | |
648 | +Menlo Park, Calif., September 1991. | |
649 | +.SH "SECURITY" | |
650 | +.PP | |
651 | +\fBrdisc\fR requires CAP_NET_RAWIO to listen | |
652 | +and send ICMP messages and capability CAP_NET_ADMIN | |
653 | +to update routing tables. | |
654 | +.SH "AVAILABILITY" | |
655 | +.PP | |
656 | +\fBrdisc\fR is part of \fIiputils\fR package | |
657 | +and the latest versions are available in source form at | |
658 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. | |
659 | diff -Naur doc/tracepath.8 doc/tracepath.8 | |
660 | --- doc/tracepath.8 1969-12-31 16:00:00.000000000 -0800 | |
661 | +++ doc/tracepath.8 2009-02-18 23:21:37.765316105 -0800 | |
662 | @@ -0,0 +1,94 @@ | |
663 | +.\" This manpage has been automatically generated by docbook2man | |
664 | +.\" from a DocBook document. This tool can be found at: | |
665 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> | |
666 | +.\" Please send any bug reports, improvements, comments, patches, | |
667 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. | |
668 | +.TH "TRACEPATH" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" | |
669 | +.SH NAME | |
670 | +tracepath, tracepath6 \- traces path to a network host discovering MTU along this path | |
671 | +.SH SYNOPSIS | |
672 | + | |
673 | +\fBtracepath\fR [\fB-n\fR] [\fB-l \fIpktlen\fB\fR] \fB\fIdestination\fB\fR [\fB\fIport\fB\fR] | |
674 | + | |
675 | +.SH "DESCRIPTION" | |
676 | +.PP | |
677 | +It traces path to \fIdestination\fR discovering MTU along this path. | |
678 | +It uses UDP port \fIport\fR or some random port. | |
679 | +It is similar to \fBtraceroute\fR, only does not not require superuser | |
680 | +privileges and has no fancy options. | |
681 | +.PP | |
682 | +\fBtracepath6\fR is good replacement for \fBtraceroute6\fR | |
683 | +and classic example of application of Linux error queues. | |
684 | +The situation with \fBtracepath\fR is worse, because commercial | |
685 | +IP routers do not return enough information in icmp error messages. | |
686 | +Probably, it will change, when they will be updated. | |
687 | +For now it uses Van Jacobson's trick, sweeping a range | |
688 | +of UDP ports to maintain trace history. | |
689 | +.SH "OPTIONS" | |
690 | +.TP | |
691 | +\fB-n\fR | |
692 | +Do not look up host names. Only print IP addresses numerically. | |
693 | +.TP | |
694 | +\fB-l\fR | |
695 | +Sets the initial packet length to \fIpktlen\fR instead of | |
696 | +65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR. | |
697 | +.SH "OUTPUT" | |
698 | +.PP | |
699 | + | |
700 | +.nf | |
701 | +root@mops:~ # tracepath6 3ffe:2400:0:109::2 | |
702 | + 1?: [LOCALHOST] pmtu 1500 | |
703 | + 1: dust.inr.ac.ru 0.411ms | |
704 | + 2: dust.inr.ac.ru asymm 1 0.390ms pmtu 1480 | |
705 | + 2: 3ffe:2400:0:109::2 463.514ms reached | |
706 | + Resume: pmtu 1480 hops 2 back 2 | |
707 | +.fi | |
708 | +.PP | |
709 | +The first column shows TTL of the probe, followed by colon. | |
710 | +Usually value of TTL is obtained from reply from network, | |
711 | +but sometimes reply does not contain necessary information and | |
712 | +we have to guess it. In this case the number is followed by ?. | |
713 | +.PP | |
714 | +The second column shows the network hop, which replied to the probe. | |
715 | +It is either address of router or word [LOCALHOST], if | |
716 | +the probe was not sent to the network. | |
717 | +.PP | |
718 | +The rest of line shows miscellaneous information about path to | |
719 | +the correspinding hetwork hop. As rule it contains value of RTT. | |
720 | +Additionally, it can show Path MTU, when it changes. | |
721 | +If the path is asymmetric | |
722 | +or the probe finishes before it reach prescribed hop, difference | |
723 | +between number of hops in forward and backward direction is shown | |
724 | +folloing keyword async. This information is not reliable. | |
725 | +F.e. the third line shows asymmetry of 1, it is because the first probe | |
726 | +with TTL of 2 was rejected at the first hop due to Path MTU Discovery. | |
727 | +.PP | |
728 | +The last line summarizes information about all the path to the destination, | |
729 | +it shows detected Path MTU, amount of hops to the destination and our | |
730 | +guess about amount of hops from the destination to us, which can be | |
731 | +different when the path is asymmetric. | |
732 | +.SH "SEE ALSO" | |
733 | +.PP | |
734 | +\fBtraceroute\fR(8), | |
735 | +\fBtraceroute6\fR(8), | |
736 | +\fBping\fR(8). | |
737 | +.SH "AUTHOR" | |
738 | +.PP | |
739 | +\fBtracepath\fR was written by | |
740 | +Alexey Kuznetsov | |
741 | +<kuznet@ms2.inr.ac.ru>. | |
742 | +.SH "SECURITY" | |
743 | +.PP | |
744 | +No security issues. | |
745 | +.PP | |
746 | +This lapidary deserves to be elaborated. | |
747 | +\fBtracepath\fR is not a privileged program, unlike | |
748 | +\fBtraceroute\fR, \fBping\fR and other beasts of this kind. | |
749 | +\fBtracepath\fR may be executed by everyone who has some access | |
750 | +to network, enough to send UDP datagrams to investigated destination | |
751 | +using given port. | |
752 | +.SH "AVAILABILITY" | |
753 | +.PP | |
754 | +\fBtracepath\fR is part of \fIiputils\fR package | |
755 | +and the latest versions are available in source form at | |
756 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. | |
757 | diff -Naur doc/traceroute6.8 doc/traceroute6.8 | |
758 | --- doc/traceroute6.8 1969-12-31 16:00:00.000000000 -0800 | |
759 | +++ doc/traceroute6.8 2009-02-18 23:20:33.249183964 -0800 | |
760 | @@ -0,0 +1,42 @@ | |
761 | +.\" This manpage has been automatically generated by docbook2man | |
762 | +.\" from a DocBook document. This tool can be found at: | |
763 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> | |
764 | +.\" Please send any bug reports, improvements, comments, patches, | |
765 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. | |
766 | +.TH "TRACEROUTE6" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" | |
767 | +.SH NAME | |
768 | +traceroute6 \- traces path to a network host | |
769 | +.SH SYNOPSIS | |
770 | + | |
771 | +\fBtraceroute6\fR [\fB-dnrvV\fR] [\fB-i \fIinterface\fB\fR] [\fB-m \fImax_ttl\fB\fR] [\fB-p \fIport\fB\fR] [\fB-q \fImax_probes\fB\fR] [\fB-s \fIsource\fB\fR] [\fB-w \fIwait time\fB\fR] \fB\fIdestination\fB\fR [\fB\fIsize\fB\fR] | |
772 | + | |
773 | +.SH "DESCRIPTION" | |
774 | +.PP | |
775 | +Description can be found in | |
776 | +\fBtraceroute\fR(8), | |
777 | +all the references to IP replaced to IPv6. It is needless to copy | |
778 | +the description from there. | |
779 | +.SH "SEE ALSO" | |
780 | +.PP | |
781 | +\fBtraceroute\fR(8), | |
782 | +\fBtracepath\fR(8), | |
783 | +\fBping\fR(8). | |
784 | +.SH "HISTORY" | |
785 | +.PP | |
786 | +This program has long history. Author of \fBtraceroute\fR | |
787 | +is Van Jacobson and it first appeared in 1988. This clone is | |
788 | +based on a port of \fBtraceroute\fR to IPv6 published | |
789 | +in NRL IPv6 distribution in 1996. In turn, it was ported | |
790 | +to Linux by Pedro Roque. After this it was kept in sync by | |
791 | +Alexey Kuznetsov | |
792 | +<kuznet@ms2.inr.ac.ru>. And eventually entered | |
793 | +\fBiputils\fR package. | |
794 | +.SH "SECURITY" | |
795 | +.PP | |
796 | +\fBtracepath6\fR requires CAP_NET_RAWIO capability | |
797 | +to be executed. It is safe to be used as set-uid root. | |
798 | +.SH "AVAILABILITY" | |
799 | +.PP | |
800 | +\fBtraceroute6\fR is part of \fIiputils\fR package | |
801 | +and the latest versions are available in source form at | |
802 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. | |
803 |