[52f035d] | 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 |
---|
[8d00c46] | 8 | -once- on a completed system and saved the data). |
---|
[52f035d] | 9 | |
---|
[8201ceeb] | 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 |
---|
[52f035d] | 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. |
---|
[8201ceeb] | 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 |
---|
[52f035d] | 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. |
---|
[8201ceeb] | 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 |
---|
[52f035d] | 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. |
---|
[8201ceeb] | 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 |
---|
[52f035d] | 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. |
---|
[8201ceeb] | 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 |
---|
[52f035d] | 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 |
---|
[8d00c46] | 728 | +The last line summarizes information about all the path to the destination, |
---|
[52f035d] | 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. |
---|
[8201ceeb] | 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 |
---|
[52f035d] | 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. |
---|
[8d00c46] | 803 | |
---|