| 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 | |