[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 |
---|
| 8 | -once- on a completed system and saved the data). |
---|
| 9 | |
---|
| 10 | diff -Naur iputils-s20071127.orig/doc/arping.8 iputils-s20071127/doc/arping.8 |
---|
| 11 | --- iputils-s20071127.orig/doc/arping.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 12 | +++ iputils-s20071127/doc/arping.8 2009-02-18 20:52:34.000000000 -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 iputils-s20071127.orig/doc/clockdiff.8 iputils-s20071127/doc/clockdiff.8 |
---|
| 125 | --- iputils-s20071127.orig/doc/clockdiff.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 126 | +++ iputils-s20071127/doc/clockdiff.8 2009-02-18 20:52:38.000000000 -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 iputils-s20071127.orig/doc/pg3.8 iputils-s20071127/doc/pg3.8 |
---|
| 210 | --- iputils-s20071127.orig/doc/pg3.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 211 | +++ iputils-s20071127/doc/pg3.8 2009-02-18 20:52:42.000000000 -0800 |
---|
| 212 | @@ -0,0 +1,86 @@ |
---|
| 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 "PG3" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 219 | +.SH NAME |
---|
| 220 | +pg3, ipg, pgset \- send stream of UDP packets |
---|
| 221 | +.SH SYNOPSIS |
---|
| 222 | + |
---|
| 223 | +\fBsource ipg\fR |
---|
| 224 | + |
---|
| 225 | + |
---|
| 226 | +\fBpg\fR |
---|
| 227 | + |
---|
| 228 | + |
---|
| 229 | +\fBpgset\fR \fB\fICOMMAND\fB\fR |
---|
| 230 | + |
---|
| 231 | +.SH "DESCRIPTION" |
---|
| 232 | +.PP |
---|
| 233 | +\fBipg\fR is not a program, it is script which should be sourced |
---|
| 234 | +to \fBbash\fR. When sourced it loads module \fIpg3\fR and |
---|
| 235 | +exports a few of functions accessible from parent shell. These macros |
---|
| 236 | +are \fBpg\fR to start packet injection and to get the results of run; |
---|
| 237 | +and \fBpgset\fR to setup packet generator. |
---|
| 238 | +.PP |
---|
| 239 | +\fBpgset\fR can send the following commands to module \fIpg3\fR: |
---|
| 240 | +.SH "COMMAND" |
---|
| 241 | +.TP |
---|
| 242 | +\fBodev \fIDEVICE\fB\fR |
---|
| 243 | +Name of Ethernet device to test. See |
---|
| 244 | +warning below. |
---|
| 245 | +.TP |
---|
| 246 | +\fBpkt_size \fIBYTES\fB\fR |
---|
| 247 | +Size of packet to generate. The size includes all the headers: UDP, IP, |
---|
| 248 | +MAC, but does not account for overhead internal to medium, i.e. FCS |
---|
| 249 | +and various paddings. |
---|
| 250 | +.TP |
---|
| 251 | +\fBfrags \fINUMBER\fB\fR |
---|
| 252 | +Each packet will contain \fINUMBER\fR of fragments. |
---|
| 253 | +Maximal amount for linux-2.4 is 6. Far not all the devices support |
---|
| 254 | +fragmented buffers. |
---|
| 255 | +.TP |
---|
| 256 | +\fBcount \fINUMBER\fB\fR |
---|
| 257 | +Send stream of \fINUMBER\fR of packets and stop after this. |
---|
| 258 | +.TP |
---|
| 259 | +\fBipg \fITIME\fB\fR |
---|
| 260 | +Introduce artificial delay between packets of \fITIME\fR |
---|
| 261 | +microseconds. |
---|
| 262 | +.TP |
---|
| 263 | +\fBdst \fIIP_ADDRESS\fB\fR |
---|
| 264 | +Select IP destination where the stream is sent to. |
---|
| 265 | +Beware, never set this address at random. \fBpg3\fR is not a toy, |
---|
| 266 | +it creates really tough stream. Default value is 0.0.0.0. |
---|
| 267 | +.TP |
---|
| 268 | +\fBdst \fIMAC_ADDRESS\fB\fR |
---|
| 269 | +Select MAC destination where the stream is sent to. |
---|
| 270 | +Default value is 00:00:00:00:00:00 in hope that this will not be received |
---|
| 271 | +by any node on LAN. |
---|
| 272 | +.TP |
---|
| 273 | +\fBstop\fR |
---|
| 274 | +Abort packet injection. |
---|
| 275 | +.SH "WARNING" |
---|
| 276 | +.PP |
---|
| 277 | +When output device is set to some random device different |
---|
| 278 | +of hardware Ethernet device, \fBpg3\fR will crash kernel. |
---|
| 279 | +.PP |
---|
| 280 | +Do not use it on VLAN, ethertap, VTUN and other devices, |
---|
| 281 | +which emulate Ethernet not being real Ethernet in fact. |
---|
| 282 | +.SH "AUTHOR" |
---|
| 283 | +.PP |
---|
| 284 | +\fBpg3\fR was written by Robert Olsson <robert.olsson@its.uu.se>. |
---|
| 285 | +.SH "SECURITY" |
---|
| 286 | +.PP |
---|
| 287 | +This can be used only by superuser. |
---|
| 288 | +.PP |
---|
| 289 | +This tool creates floods of packets which is unlikely to be handled |
---|
| 290 | +even by high-end machines. For example, it saturates gigabit link with |
---|
| 291 | +60 byte packets when used with Intel's e1000. In face of such stream |
---|
| 292 | +switches, routers and end hosts may deadlock, crash, explode. |
---|
| 293 | +Use only in test lab environment. |
---|
| 294 | +.SH "AVAILABILITY" |
---|
| 295 | +.PP |
---|
| 296 | +\fBpg3\fR is part of \fIiputils\fR package |
---|
| 297 | +and the latest versions are available in source form at |
---|
| 298 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|
| 299 | diff -Naur iputils-s20071127.orig/doc/ping.8 iputils-s20071127/doc/ping.8 |
---|
| 300 | --- iputils-s20071127.orig/doc/ping.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 301 | +++ iputils-s20071127/doc/ping.8 2009-02-18 20:52:44.000000000 -0800 |
---|
| 302 | @@ -0,0 +1,332 @@ |
---|
| 303 | +.\" This manpage has been automatically generated by docbook2man |
---|
| 304 | +.\" from a DocBook document. This tool can be found at: |
---|
| 305 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> |
---|
| 306 | +.\" Please send any bug reports, improvements, comments, patches, |
---|
| 307 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. |
---|
| 308 | +.TH "PING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 309 | +.SH NAME |
---|
| 310 | +ping, ping6 \- send ICMP ECHO_REQUEST to network hosts |
---|
| 311 | +.SH SYNOPSIS |
---|
| 312 | + |
---|
| 313 | +\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 |
---|
| 314 | + |
---|
| 315 | +.SH "DESCRIPTION" |
---|
| 316 | +.PP |
---|
| 317 | +\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST |
---|
| 318 | +datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. |
---|
| 319 | +ECHO_REQUEST datagrams (``pings'') have an IP and ICMP |
---|
| 320 | +header, followed by a struct timeval and then an arbitrary |
---|
| 321 | +number of ``pad'' bytes used to fill out the packet. |
---|
| 322 | +.SH "OPTIONS" |
---|
| 323 | +.TP |
---|
| 324 | +\fB-a\fR |
---|
| 325 | +Audible ping. |
---|
| 326 | +.TP |
---|
| 327 | +\fB-A\fR |
---|
| 328 | +Adaptive ping. Interpacket interval adapts to round-trip time, so that |
---|
| 329 | +effectively not more than one (or more, if preload is set) unanswered probes |
---|
| 330 | +present in the network. Minimal interval is 200msec for not super-user. |
---|
| 331 | +On networks with low rtt this mode is essentially equivalent to flood mode. |
---|
| 332 | +.TP |
---|
| 333 | +\fB-b\fR |
---|
| 334 | +Allow pinging a broadcast address. |
---|
| 335 | +.TP |
---|
| 336 | +\fB-B\fR |
---|
| 337 | +Do not allow \fBping\fR to change source address of probes. |
---|
| 338 | +The address is bound to one selected when \fBping\fR starts. |
---|
| 339 | +.TP |
---|
| 340 | +\fB-c \fIcount\fB\fR |
---|
| 341 | +Stop after sending \fIcount\fR ECHO_REQUEST |
---|
| 342 | +packets. With |
---|
| 343 | +\fIdeadline\fR |
---|
| 344 | +option, \fBping\fR waits for |
---|
| 345 | +\fIcount\fR ECHO_REPLY packets, until the timeout expires. |
---|
| 346 | +.TP |
---|
| 347 | +\fB-d\fR |
---|
| 348 | +Set the SO_DEBUG option on the socket being used. |
---|
| 349 | +Essentially, this socket option is not used by Linux kernel. |
---|
| 350 | +.TP |
---|
| 351 | +\fB-F \fIflow label\fB\fR |
---|
| 352 | +Allocate and set 20 bit flow label on echo request packets. |
---|
| 353 | +(Only \fBping6\fR). If value is zero, kernel allocates random flow label. |
---|
| 354 | +.TP |
---|
| 355 | +\fB-f\fR |
---|
| 356 | +Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed, |
---|
| 357 | +while for ever ECHO_REPLY received a backspace is printed. |
---|
| 358 | +This provides a rapid display of how many packets are being dropped. |
---|
| 359 | +If interval is not given, it sets interval to zero and |
---|
| 360 | +outputs packets as fast as they come back or one hundred times per second, |
---|
| 361 | +whichever is more. |
---|
| 362 | +Only the super-user may use this option with zero interval. |
---|
| 363 | +.TP |
---|
| 364 | +\fB-i \fIinterval\fB\fR |
---|
| 365 | +Wait \fIinterval\fR seconds between sending each packet. |
---|
| 366 | +The default is to wait for one second between each packet normally, |
---|
| 367 | +or not to wait in flood mode. Only super-user may set interval |
---|
| 368 | +to values less 0.2 seconds. |
---|
| 369 | +.TP |
---|
| 370 | +\fB-I \fIinterface address\fB\fR |
---|
| 371 | +Set source address to specified interface address. Argument |
---|
| 372 | +may be numeric IP address or name of device. When pinging IPv6 |
---|
| 373 | +link-local address this option is required. |
---|
| 374 | +.TP |
---|
| 375 | +\fB-l \fIpreload\fB\fR |
---|
| 376 | +If \fIpreload\fR is specified, |
---|
| 377 | +\fBping\fR sends that many packets not waiting for reply. |
---|
| 378 | +Only the super-user may select preload more than 3. |
---|
| 379 | +.TP |
---|
| 380 | +\fB-L\fR |
---|
| 381 | +Suppress loopback of multicast packets. This flag only applies if the ping |
---|
| 382 | +destination is a multicast address. |
---|
| 383 | +.TP |
---|
| 384 | +\fB-n\fR |
---|
| 385 | +Numeric output only. |
---|
| 386 | +No attempt will be made to lookup symbolic names for host addresses. |
---|
| 387 | +.TP |
---|
| 388 | +\fB-p \fIpattern\fB\fR |
---|
| 389 | +You may specify up to 16 ``pad'' bytes to fill out the packet you send. |
---|
| 390 | +This is useful for diagnosing data-dependent problems in a network. |
---|
| 391 | +For example, \fB-p ff\fR will cause the sent packet |
---|
| 392 | +to be filled with all ones. |
---|
| 393 | +.TP |
---|
| 394 | +\fB-Q \fItos\fB\fR |
---|
| 395 | +Set Quality of Service -related bits in ICMP datagrams. |
---|
| 396 | +\fItos\fR can be either decimal or hex number. |
---|
| 397 | +Traditionally (RFC1349), these have been interpreted as: 0 for reserved |
---|
| 398 | +(currently being redefined as congestion control), 1-4 for Type of Service |
---|
| 399 | +and 5-7 for Precedence. |
---|
| 400 | +Possible settings for Type of Service are: minimal cost: 0x02, |
---|
| 401 | +reliability: 0x04, throughput: 0x08, low delay: 0x10. Multiple TOS bits |
---|
| 402 | +should not be set simultaneously. Possible settings for |
---|
| 403 | +special Precedence range from priority (0x20) to net control (0xe0). You |
---|
| 404 | +must be root (CAP_NET_ADMIN capability) to use Critical or |
---|
| 405 | +higher precedence value. You cannot set |
---|
| 406 | +bit 0x01 (reserved) unless ECN has been enabled in the kernel. |
---|
| 407 | +In RFC2474, these fields has been redefined as 8-bit Differentiated |
---|
| 408 | +Services (DS), consisting of: bits 0-1 of separate data (ECN will be used, |
---|
| 409 | +here), and bits 2-7 of Differentiated Services Codepoint (DSCP). |
---|
| 410 | +.TP |
---|
| 411 | +\fB-q\fR |
---|
| 412 | +Quiet output. |
---|
| 413 | +Nothing is displayed except the summary lines at startup time and |
---|
| 414 | +when finished. |
---|
| 415 | +.TP |
---|
| 416 | +\fB-R\fR |
---|
| 417 | +Record route. |
---|
| 418 | +Includes the RECORD_ROUTE option in the ECHO_REQUEST |
---|
| 419 | +packet and displays the route buffer on returned packets. |
---|
| 420 | +Note that the IP header is only large enough for nine such routes. |
---|
| 421 | +Many hosts ignore or discard this option. |
---|
| 422 | +.TP |
---|
| 423 | +\fB-r\fR |
---|
| 424 | +Bypass the normal routing tables and send directly to a host on an attached |
---|
| 425 | +interface. |
---|
| 426 | +If the host is not on a directly-attached network, an error is returned. |
---|
| 427 | +This option can be used to ping a local host through an interface |
---|
| 428 | +that has no route through it provided the option \fB-I\fR is also |
---|
| 429 | +used. |
---|
| 430 | +.TP |
---|
| 431 | +\fB-s \fIpacketsize\fB\fR |
---|
| 432 | +Specifies the number of data bytes to be sent. |
---|
| 433 | +The default is 56, which translates into 64 ICMP |
---|
| 434 | +data bytes when combined with the 8 bytes of ICMP header data. |
---|
| 435 | +.TP |
---|
| 436 | +\fB-S \fIsndbuf\fB\fR |
---|
| 437 | +Set socket sndbuf. If not specified, it is selected to buffer |
---|
| 438 | +not more than one packet. |
---|
| 439 | +.TP |
---|
| 440 | +\fB-t \fIttl\fB\fR |
---|
| 441 | +Set the IP Time to Live. |
---|
| 442 | +.TP |
---|
| 443 | +\fB-T \fItimestamp option\fB\fR |
---|
| 444 | +Set special IP timestamp options. |
---|
| 445 | +\fItimestamp option\fR may be either |
---|
| 446 | +\fItsonly\fR (only timestamps), |
---|
| 447 | +\fItsandaddr\fR (timestamps and addresses) or |
---|
| 448 | +\fItsprespec host1 [host2 [host3 [host4]]]\fR |
---|
| 449 | +(timestamp prespecified hops). |
---|
| 450 | +.TP |
---|
| 451 | +\fB-M \fIhint\fB\fR |
---|
| 452 | +Select Path MTU Discovery strategy. |
---|
| 453 | +\fIhint\fR may be either \fIdo\fR |
---|
| 454 | +(prohibit fragmentation, even local one), |
---|
| 455 | +\fIwant\fR (do PMTU discovery, fragment locally when packet size |
---|
| 456 | +is large), or \fIdont\fR (do not set DF flag). |
---|
| 457 | +.TP |
---|
| 458 | +\fB-U\fR |
---|
| 459 | +Print full user-to-user latency (the old behaviour). Normally |
---|
| 460 | +\fBping\fR |
---|
| 461 | +prints network round trip time, which can be different |
---|
| 462 | +f.e. due to DNS failures. |
---|
| 463 | +.TP |
---|
| 464 | +\fB-v\fR |
---|
| 465 | +Verbose output. |
---|
| 466 | +.TP |
---|
| 467 | +\fB-V\fR |
---|
| 468 | +Show version and exit. |
---|
| 469 | +.TP |
---|
| 470 | +\fB-w \fIdeadline\fB\fR |
---|
| 471 | +Specify a timeout, in seconds, before |
---|
| 472 | +\fBping\fR |
---|
| 473 | +exits regardless of how many |
---|
| 474 | +packets have been sent or received. In this case |
---|
| 475 | +\fBping\fR |
---|
| 476 | +does not stop after |
---|
| 477 | +\fIcount\fR |
---|
| 478 | +packet are sent, it waits either for |
---|
| 479 | +\fIdeadline\fR |
---|
| 480 | +expire or until |
---|
| 481 | +\fIcount\fR |
---|
| 482 | +probes are answered or for some error notification from network. |
---|
| 483 | +.TP |
---|
| 484 | +\fB-W \fItimeout\fB\fR |
---|
| 485 | +Time to wait for a response, in seconds. The option affects only timeout |
---|
| 486 | +in absense of any responses, otherwise \fBping\fR waits for two RTTs. |
---|
| 487 | +.PP |
---|
| 488 | +When using \fBping\fR for fault isolation, it should first be run |
---|
| 489 | +on the local host, to verify that the local network interface is up |
---|
| 490 | +and running. Then, hosts and gateways further and further away should be |
---|
| 491 | +``pinged''. Round-trip times and packet loss statistics are computed. |
---|
| 492 | +If duplicate packets are received, they are not included in the packet |
---|
| 493 | +loss calculation, although the round trip time of these packets is used |
---|
| 494 | +in calculating the minimum/average/maximum round-trip time numbers. |
---|
| 495 | +When the specified number of packets have been sent (and received) or |
---|
| 496 | +if the program is terminated with a |
---|
| 497 | +SIGINT, a brief summary is displayed. Shorter current statistics |
---|
| 498 | +can be obtained without termination of process with signal |
---|
| 499 | +SIGQUIT. |
---|
| 500 | +.PP |
---|
| 501 | +If \fBping\fR does not receive any reply packets at all it will |
---|
| 502 | +exit with code 1. If a packet |
---|
| 503 | +\fIcount\fR |
---|
| 504 | +and |
---|
| 505 | +\fIdeadline\fR |
---|
| 506 | +are both specified, and fewer than |
---|
| 507 | +\fIcount\fR |
---|
| 508 | +packets are received by the time the |
---|
| 509 | +\fIdeadline\fR |
---|
| 510 | +has arrived, it will also exit with code 1. |
---|
| 511 | +On other error it exits with code 2. Otherwise it exits with code 0. This |
---|
| 512 | +makes it possible to use the exit code to see if a host is alive or |
---|
| 513 | +not. |
---|
| 514 | +.PP |
---|
| 515 | +This program is intended for use in network testing, measurement and |
---|
| 516 | +management. |
---|
| 517 | +Because of the load it can impose on the network, it is unwise to use |
---|
| 518 | +\fBping\fR during normal operations or from automated scripts. |
---|
| 519 | +.SH "ICMP PACKET DETAILS" |
---|
| 520 | +.PP |
---|
| 521 | +An IP header without options is 20 bytes. |
---|
| 522 | +An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth |
---|
| 523 | +of ICMP header followed by an arbitrary amount of data. |
---|
| 524 | +When a \fIpacketsize\fR is given, this indicated the size of this |
---|
| 525 | +extra piece of data (the default is 56). Thus the amount of data received |
---|
| 526 | +inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes |
---|
| 527 | +more than the requested data space (the ICMP header). |
---|
| 528 | +.PP |
---|
| 529 | +If the data space is at least of size of struct timeval |
---|
| 530 | +\fBping\fR uses the beginning bytes of this space to include |
---|
| 531 | +a timestamp which it uses in the computation of round trip times. |
---|
| 532 | +If the data space is shorter, no round trip times are given. |
---|
| 533 | +.SH "DUPLICATE AND DAMAGED PACKETS" |
---|
| 534 | +.PP |
---|
| 535 | +\fBping\fR will report duplicate and damaged packets. |
---|
| 536 | +Duplicate packets should never occur, and seem to be caused by |
---|
| 537 | +inappropriate link-level retransmissions. |
---|
| 538 | +Duplicates may occur in many situations and are rarely (if ever) a |
---|
| 539 | +good sign, although the presence of low levels of duplicates may not |
---|
| 540 | +always be cause for alarm. |
---|
| 541 | +.PP |
---|
| 542 | +Damaged packets are obviously serious cause for alarm and often |
---|
| 543 | +indicate broken hardware somewhere in the |
---|
| 544 | +\fBping\fR packet's path (in the network or in the hosts). |
---|
| 545 | +.SH "TRYING DIFFERENT DATA PATTERNS" |
---|
| 546 | +.PP |
---|
| 547 | +The (inter)network layer should never treat packets differently depending |
---|
| 548 | +on the data contained in the data portion. |
---|
| 549 | +Unfortunately, data-dependent problems have been known to sneak into |
---|
| 550 | +networks and remain undetected for long periods of time. |
---|
| 551 | +In many cases the particular pattern that will have problems is something |
---|
| 552 | +that doesn't have sufficient ``transitions'', such as all ones or all |
---|
| 553 | +zeros, or a pattern right at the edge, such as almost all zeros. |
---|
| 554 | +It isn't necessarily enough to specify a data pattern of all zeros (for |
---|
| 555 | +example) on the command line because the pattern that is of interest is |
---|
| 556 | +at the data link level, and the relationship between what you type and |
---|
| 557 | +what the controllers transmit can be complicated. |
---|
| 558 | +.PP |
---|
| 559 | +This means that if you have a data-dependent problem you will probably |
---|
| 560 | +have to do a lot of testing to find it. |
---|
| 561 | +If you are lucky, you may manage to find a file that either can't be sent |
---|
| 562 | +across your network or that takes much longer to transfer than other |
---|
| 563 | +similar length files. |
---|
| 564 | +You can then examine this file for repeated patterns that you can test |
---|
| 565 | +using the \fB-p\fR option of \fBping\fR. |
---|
| 566 | +.SH "TTL DETAILS" |
---|
| 567 | +.PP |
---|
| 568 | +The TTL value of an IP packet represents the maximum number of IP routers |
---|
| 569 | +that the packet can go through before being thrown away. |
---|
| 570 | +In current practice you can expect each router in the Internet to decrement |
---|
| 571 | +the TTL field by exactly one. |
---|
| 572 | +.PP |
---|
| 573 | +The TCP/IP specification states that the TTL field for TCP |
---|
| 574 | +packets should be set to 60, but many systems use smaller values |
---|
| 575 | +(4.3 BSD uses 30, 4.2 used 15). |
---|
| 576 | +.PP |
---|
| 577 | +The maximum possible value of this field is 255, and most Unix systems set |
---|
| 578 | +the TTL field of ICMP ECHO_REQUEST packets to 255. |
---|
| 579 | +This is why you will find you can ``ping'' some hosts, but not reach them |
---|
| 580 | +with |
---|
| 581 | +\fBtelnet\fR(1) |
---|
| 582 | +or |
---|
| 583 | +\fBftp\fR(1). |
---|
| 584 | +.PP |
---|
| 585 | +In normal operation ping prints the ttl value from the packet it receives. |
---|
| 586 | +When a remote system receives a ping packet, it can do one of three things |
---|
| 587 | +with the TTL field in its response: |
---|
| 588 | +.TP 0.2i |
---|
| 589 | +\(bu |
---|
| 590 | +Not change it; this is what Berkeley Unix systems did before the |
---|
| 591 | +4.3BSD Tahoe release. In this case the TTL value in the received packet |
---|
| 592 | +will be 255 minus the number of routers in the round-trip path. |
---|
| 593 | +.TP 0.2i |
---|
| 594 | +\(bu |
---|
| 595 | +Set it to 255; this is what current Berkeley Unix systems do. |
---|
| 596 | +In this case the TTL value in the received packet will be 255 minus the |
---|
| 597 | +number of routers in the path \fBfrom\fR |
---|
| 598 | +the remote system \fBto\fR the \fBping\fRing host. |
---|
| 599 | +.TP 0.2i |
---|
| 600 | +\(bu |
---|
| 601 | +Set it to some other value. Some machines use the same value for |
---|
| 602 | +ICMP packets that they use for TCP packets, for example either 30 or 60. |
---|
| 603 | +Others may use completely wild values. |
---|
| 604 | +.SH "BUGS" |
---|
| 605 | +.TP 0.2i |
---|
| 606 | +\(bu |
---|
| 607 | +Many Hosts and Gateways ignore the RECORD_ROUTE option. |
---|
| 608 | +.TP 0.2i |
---|
| 609 | +\(bu |
---|
| 610 | +The maximum IP header length is too small for options like |
---|
| 611 | +RECORD_ROUTE to be completely useful. |
---|
| 612 | +There's not much that that can be done about this, however. |
---|
| 613 | +.TP 0.2i |
---|
| 614 | +\(bu |
---|
| 615 | +Flood pinging is not recommended in general, and flood pinging the |
---|
| 616 | +broadcast address should only be done under very controlled conditions. |
---|
| 617 | +.SH "SEE ALSO" |
---|
| 618 | +.PP |
---|
| 619 | +\fBnetstat\fR(1), |
---|
| 620 | +\fBifconfig\fR(8). |
---|
| 621 | +.SH "HISTORY" |
---|
| 622 | +.PP |
---|
| 623 | +The \fBping\fR command appeared in 4.3BSD. |
---|
| 624 | +.PP |
---|
| 625 | +The version described here is its descendant specific to Linux. |
---|
| 626 | +.SH "SECURITY" |
---|
| 627 | +.PP |
---|
| 628 | +\fBping\fR requires CAP_NET_RAWIO capability |
---|
| 629 | +to be executed. It may be used as set-uid root. |
---|
| 630 | +.SH "AVAILABILITY" |
---|
| 631 | +.PP |
---|
| 632 | +\fBping\fR is part of \fIiputils\fR package |
---|
| 633 | +and the latest versions are available in source form at |
---|
| 634 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|
| 635 | diff -Naur iputils-s20071127.orig/doc/rarpd.8 iputils-s20071127/doc/rarpd.8 |
---|
| 636 | --- iputils-s20071127.orig/doc/rarpd.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 637 | +++ iputils-s20071127/doc/rarpd.8 2009-02-18 20:52:48.000000000 -0800 |
---|
| 638 | @@ -0,0 +1,84 @@ |
---|
| 639 | +.\" This manpage has been automatically generated by docbook2man |
---|
| 640 | +.\" from a DocBook document. This tool can be found at: |
---|
| 641 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> |
---|
| 642 | +.\" Please send any bug reports, improvements, comments, patches, |
---|
| 643 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. |
---|
| 644 | +.TH "RARPD" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 645 | +.SH NAME |
---|
| 646 | +rarpd \- answer RARP REQUESTs |
---|
| 647 | +.SH SYNOPSIS |
---|
| 648 | + |
---|
| 649 | +\fBarping\fR [\fB-aAvde\fR] [\fB-b \fIbootdir\fB\fR] [\fB\fIinterface\fB\fR] |
---|
| 650 | + |
---|
| 651 | +.SH "DESCRIPTION" |
---|
| 652 | +.PP |
---|
| 653 | +Listens |
---|
| 654 | +RARP |
---|
| 655 | +requests from clients. Provided MAC address of client |
---|
| 656 | +is found in \fI/etc/ethers\fR database and |
---|
| 657 | +obtained host name is resolvable to an IP address appropriate |
---|
| 658 | +for attached network, \fBrarpd\fR answers to client with RARPD |
---|
| 659 | +reply carrying an IP address. |
---|
| 660 | +.PP |
---|
| 661 | +To allow multiple boot servers on the network \fBrarpd\fR |
---|
| 662 | +optionally checks for presence Sun-like bootable image in TFTP directory. |
---|
| 663 | +It should have form \fBHexadecimal_IP.ARCH\fR, f.e. to load |
---|
| 664 | +sparc 193.233.7.98 \fIC1E90762.SUN4M\fR is linked to |
---|
| 665 | +an image appropriate for SUM4M in directory \fI/etc/tftpboot\fR. |
---|
| 666 | +.SH "WARNING" |
---|
| 667 | +.PP |
---|
| 668 | +This facility is deeply obsoleted by |
---|
| 669 | +BOOTP |
---|
| 670 | +and later |
---|
| 671 | +DHCP protocols. |
---|
| 672 | +However, some clients really still need this to boot. |
---|
| 673 | +.SH "OPTIONS" |
---|
| 674 | +.TP |
---|
| 675 | +\fB-a\fR |
---|
| 676 | +Listen on all the interfaces. Currently it is an internal |
---|
| 677 | +option, its function is overridden with \fIinterface\fR |
---|
| 678 | +argument. It should not be used. |
---|
| 679 | +.TP |
---|
| 680 | +\fB-A\fR |
---|
| 681 | +Listen not only RARP but also ARP messages, some rare clients |
---|
| 682 | +use ARP by some unknown reason. |
---|
| 683 | +.TP |
---|
| 684 | +\fB-v\fR |
---|
| 685 | +Be verbose. |
---|
| 686 | +.TP |
---|
| 687 | +\fB-d\fR |
---|
| 688 | +Debug mode. Do not go to background. |
---|
| 689 | +.TP |
---|
| 690 | +\fB-e\fR |
---|
| 691 | +Do not check for presence of a boot image, reply if MAC address |
---|
| 692 | +resolves to a valid IP address using \fI/etc/ethers\fR |
---|
| 693 | +database and DNS. |
---|
| 694 | +.TP |
---|
| 695 | +\fB-b \fIbootdir\fB\fR |
---|
| 696 | +TFTP boot directory. Default is \fI/etc/tftpboot\fR |
---|
| 697 | +.SH "SEE ALSO" |
---|
| 698 | +.PP |
---|
| 699 | +\fBarping\fR(8), |
---|
| 700 | +\fBtftpd\fR(8). |
---|
| 701 | +.SH "AUTHOR" |
---|
| 702 | +.PP |
---|
| 703 | +\fBrarpd\fR was written by |
---|
| 704 | +Alexey Kuznetsov |
---|
| 705 | +<kuznet@ms2.inr.ac.ru>. |
---|
| 706 | +It is now maintained by |
---|
| 707 | +YOSHIFUJI Hideaki |
---|
| 708 | +<yoshfuji@skbuff.net>. |
---|
| 709 | +.SH "SECURITY" |
---|
| 710 | +.PP |
---|
| 711 | +\fBrarpd\fR requires CAP_NET_RAWIO capability |
---|
| 712 | +to listen and send RARP and ARP packets. It also needs CAP_NET_ADMIN |
---|
| 713 | +to give to kernel hint for ARP resolution; this is not strictly required, |
---|
| 714 | +but some (most of, to be more exact) clients are so badly broken that |
---|
| 715 | +are not able to answer ARP before they are finally booted. This is |
---|
| 716 | +not wonderful taking into account that clients using RARPD in 2002 |
---|
| 717 | +are all unsupported relic creatures of 90's and even earlier. |
---|
| 718 | +.SH "AVAILABILITY" |
---|
| 719 | +.PP |
---|
| 720 | +\fBrarpd\fR is part of \fIiputils\fR package |
---|
| 721 | +and the latest versions are available in source form at |
---|
| 722 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|
| 723 | diff -Naur iputils-s20071127.orig/doc/rdisc.8 iputils-s20071127/doc/rdisc.8 |
---|
| 724 | --- iputils-s20071127.orig/doc/rdisc.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 725 | +++ iputils-s20071127/doc/rdisc.8 2009-02-18 20:52:53.000000000 -0800 |
---|
| 726 | @@ -0,0 +1,110 @@ |
---|
| 727 | +.\" This manpage has been automatically generated by docbook2man |
---|
| 728 | +.\" from a DocBook document. This tool can be found at: |
---|
| 729 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> |
---|
| 730 | +.\" Please send any bug reports, improvements, comments, patches, |
---|
| 731 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. |
---|
| 732 | +.TH "RDISC" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 733 | +.SH NAME |
---|
| 734 | +rdisc \- network router discovery daemon |
---|
| 735 | +.SH SYNOPSIS |
---|
| 736 | + |
---|
| 737 | +\fBrdisc\fR [\fB-abdfstvV\fR] [\fB\fIsend_address\fB\fR] [\fB\fIreceive_address\fB\fR] |
---|
| 738 | + |
---|
| 739 | +.SH "DESCRIPTION" |
---|
| 740 | +.PP |
---|
| 741 | +\fBrdisc\fR implements client side of the ICMP router discover protocol. |
---|
| 742 | +\fBrdisc\fR is invoked at boot time to populate the network |
---|
| 743 | +routing tables with default routes. |
---|
| 744 | +.PP |
---|
| 745 | +\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address |
---|
| 746 | +(or \fIreceive_address\fR provided it is given) |
---|
| 747 | +for ROUTER_ADVERTISE messages from routers. The received |
---|
| 748 | +messages are handled by first ignoring those listed router addresses |
---|
| 749 | +with which the host does not share a network. Among the remaining addresses |
---|
| 750 | +the ones with the highest preference are selected as default routers |
---|
| 751 | +and a default route is entered in the kernel routing table |
---|
| 752 | +for each one of them. |
---|
| 753 | +.PP |
---|
| 754 | +Optionally, \fBrdisc\fR can avoid waiting for routers to announce |
---|
| 755 | +themselves by sending out a few ROUTER_SOLICITATION messages |
---|
| 756 | +to the ALL_ROUTERS (224.0.0.2) multicast address |
---|
| 757 | +(or \fIsend_address\fR provided it is given) |
---|
| 758 | +when it is started. |
---|
| 759 | +.PP |
---|
| 760 | +A timer is associated with each router address and the address will |
---|
| 761 | +no longer be considered for inclusion in the the routing tables if the |
---|
| 762 | +timer expires before a new |
---|
| 763 | +\fBadvertise\fR message is received from the router. |
---|
| 764 | +The address will also be excluded from consideration if the host receives an |
---|
| 765 | +\fBadvertise\fR |
---|
| 766 | +message with the preference being maximally negative. |
---|
| 767 | +.PP |
---|
| 768 | +Server side of router discovery protocol is supported by Cisco IOS |
---|
| 769 | +and by any more or less complete UNIX routing daemon, f.e \fBgated\fR. |
---|
| 770 | +.SH "OPTIONS" |
---|
| 771 | +.TP |
---|
| 772 | +\fB-a\fR |
---|
| 773 | +Accept all routers independently of the preference they have in their |
---|
| 774 | +\fBadvertise\fR messages. |
---|
| 775 | +Normally \fBrdisc\fR only accepts (and enters in the kernel routing |
---|
| 776 | +tables) the router or routers with the highest preference. |
---|
| 777 | +.TP |
---|
| 778 | +\fB-b\fR |
---|
| 779 | +Opposite to \fB-a\fR, i.e. install only router with the best |
---|
| 780 | +preference value. It is default behaviour. |
---|
| 781 | +.TP |
---|
| 782 | +\fB-d\fR |
---|
| 783 | +Send debugging messages to syslog. |
---|
| 784 | +.TP |
---|
| 785 | +\fB-f\fR |
---|
| 786 | +Run \fBrdisc\fR forever even if no routers are found. |
---|
| 787 | +Normally \fBrdisc\fR gives up if it has not received any |
---|
| 788 | +\fBadvertise\fR message after after soliciting three times, |
---|
| 789 | +in which case it exits with a non-zero exit code. |
---|
| 790 | +If \fB-f\fR is not specified in the first form then |
---|
| 791 | +\fB-s\fR must be specified. |
---|
| 792 | +.TP |
---|
| 793 | +\fB-s\fR |
---|
| 794 | +Send three \fBsolicitation\fR messages initially to quickly discover |
---|
| 795 | +the routers when the system is booted. |
---|
| 796 | +When \fB-s\fR is specified \fBrdisc\fR |
---|
| 797 | +exits with a non-zero exit code if it can not find any routers. |
---|
| 798 | +This can be overridden with the \fB-f\fR option. |
---|
| 799 | +.TP |
---|
| 800 | +\fB-t\fR |
---|
| 801 | +Test mode. Do not go to background. |
---|
| 802 | +.TP |
---|
| 803 | +\fB-v\fR |
---|
| 804 | +Be verbose i.e. send lots of debugging messages to syslog. |
---|
| 805 | +.TP |
---|
| 806 | +\fB-V\fR |
---|
| 807 | +Print version and exit. |
---|
| 808 | +.SH "HISTORY" |
---|
| 809 | +.PP |
---|
| 810 | +This program was developed by Sun Microsystems (see copyright |
---|
| 811 | +notice in source file). It was ported to Linux by |
---|
| 812 | +Alexey Kuznetsov |
---|
| 813 | +<kuznet@ms2.inr.ac.ru>. |
---|
| 814 | +It is now maintained by |
---|
| 815 | +YOSHIFUJI Hideaki |
---|
| 816 | +<yoshfuji@skbuff.net>. |
---|
| 817 | +.SH "SEE ALSO" |
---|
| 818 | +.PP |
---|
| 819 | +\fBicmp\fR(7), |
---|
| 820 | +\fBinet\fR(7), |
---|
| 821 | +\fBping\fR(8). |
---|
| 822 | +.SH "REFERENCES" |
---|
| 823 | +.PP |
---|
| 824 | +Deering, S.E.,ed "ICMP Router Discovery Messages", |
---|
| 825 | +RFC1256, Network Information Center, SRI International, |
---|
| 826 | +Menlo Park, Calif., September 1991. |
---|
| 827 | +.SH "SECURITY" |
---|
| 828 | +.PP |
---|
| 829 | +\fBrdisc\fR requires CAP_NET_RAWIO to listen |
---|
| 830 | +and send ICMP messages and capability CAP_NET_ADMIN |
---|
| 831 | +to update routing tables. |
---|
| 832 | +.SH "AVAILABILITY" |
---|
| 833 | +.PP |
---|
| 834 | +\fBrdisc\fR is part of \fIiputils\fR package |
---|
| 835 | +and the latest versions are available in source form at |
---|
| 836 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|
| 837 | diff -Naur iputils-s20071127.orig/doc/tftpd.8 iputils-s20071127/doc/tftpd.8 |
---|
| 838 | --- iputils-s20071127.orig/doc/tftpd.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 839 | +++ iputils-s20071127/doc/tftpd.8 2009-02-18 20:52:57.000000000 -0800 |
---|
| 840 | @@ -0,0 +1,85 @@ |
---|
| 841 | +.\" This manpage has been automatically generated by docbook2man |
---|
| 842 | +.\" from a DocBook document. This tool can be found at: |
---|
| 843 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> |
---|
| 844 | +.\" Please send any bug reports, improvements, comments, patches, |
---|
| 845 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. |
---|
| 846 | +.TH "TFTPD" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 847 | +.SH NAME |
---|
| 848 | +tftpd \- Trivial File Transfer Protocol server |
---|
| 849 | +.SH SYNOPSIS |
---|
| 850 | + |
---|
| 851 | +\fBtftpd\fR \fB\fIdirectory\fB\fR |
---|
| 852 | + |
---|
| 853 | +.SH "DESCRIPTION" |
---|
| 854 | +.PP |
---|
| 855 | +\fBtftpd\fR is a server which supports the DARPA |
---|
| 856 | +Trivial File Transfer Protocol |
---|
| 857 | +(RFC1350). |
---|
| 858 | +The TFTP server is started |
---|
| 859 | +by \fBinetd\fR(8). |
---|
| 860 | +.PP |
---|
| 861 | +\fIdirectory\fR is required argument; if it is not given |
---|
| 862 | +\fBtftpd\fR aborts. This path is prepended to any file name requested |
---|
| 863 | +via TFTP protocol, effectively chrooting \fBtftpd\fR to this directory. |
---|
| 864 | +File names are validated not to escape out of this directory, however |
---|
| 865 | +administrator may configure such escape using symbolic links. |
---|
| 866 | +.PP |
---|
| 867 | +It is in difference of variants of \fBtftpd\fR usually distributed |
---|
| 868 | +with unix-like systems, which take a list of directories and match |
---|
| 869 | +file names to start from one of given prefixes or to some random |
---|
| 870 | +default, when no arguments were given. There are two reasons not to |
---|
| 871 | +behave in this way: first, it is inconvenient, clients are not expected |
---|
| 872 | +to know something about layout of filesystem on server host. |
---|
| 873 | +And second, TFTP protocol is not a tool for browsing of server's filesystem, |
---|
| 874 | +it is just an agent allowing to boot dumb clients. |
---|
| 875 | +.PP |
---|
| 876 | +In the case when \fBtftpd\fR is used together with |
---|
| 877 | +\fBrarpd\fR(8), |
---|
| 878 | +tftp directories in these services should coincide and it is expected |
---|
| 879 | +that each client booted via TFTP has boot image corresponding |
---|
| 880 | +its IP address with an architecture suffix following Sun Microsystems |
---|
| 881 | +conventions. See |
---|
| 882 | +\fBrarpd\fR(8) |
---|
| 883 | +for more details. |
---|
| 884 | +.SH "SECURITY" |
---|
| 885 | +.PP |
---|
| 886 | +TFTP protocol does not provide any authentication. |
---|
| 887 | +Due to this capital flaw \fBtftpd\fR is not able to restrict |
---|
| 888 | +access to files and will allow only publically readable |
---|
| 889 | +files to be accessed. Files may be written only if they already |
---|
| 890 | +exist and are publically writable. |
---|
| 891 | +.PP |
---|
| 892 | +Impact is evident, directory exported via TFTP \fBmust not\fR |
---|
| 893 | +contain sensitive information of any kind, everyone is allowed |
---|
| 894 | +to read it as soon as a client is allowed. Boot images do not contain |
---|
| 895 | +such information as rule, however you should think twice before |
---|
| 896 | +publishing f.e. Cisco IOS config files via TFTP, they contain |
---|
| 897 | +\fBunencrypted\fR passwords and may contain some information |
---|
| 898 | +about the network, which you were not going to make public. |
---|
| 899 | +.PP |
---|
| 900 | +The \fBtftpd\fR server should be executed by \fBinetd\fR |
---|
| 901 | +with dropped root privileges, namely with a user ID giving minimal |
---|
| 902 | +access to files published in tftp directory. If it is executed |
---|
| 903 | +as superuser occasionally, \fBtftpd\fR drops its UID and GID |
---|
| 904 | +to 65534, which is most likely not the thing which you expect. |
---|
| 905 | +However, this is not very essential; remember, only files accessible |
---|
| 906 | +for everyone can be read or written via TFTP. |
---|
| 907 | +.SH "SEE ALSO" |
---|
| 908 | +.PP |
---|
| 909 | +\fBrarpd\fR(8), |
---|
| 910 | +\fBtftp\fR(1), |
---|
| 911 | +\fBinetd\fR(8). |
---|
| 912 | +.SH "HISTORY" |
---|
| 913 | +.PP |
---|
| 914 | +The \fBtftpd\fR command appeared in 4.2BSD. The source in iputils |
---|
| 915 | +is cleaned up both syntactically (ANSIized) and semantically (UDP socket IO). |
---|
| 916 | +.PP |
---|
| 917 | +It is distributed with iputils mostly as good demo of an interesting feature |
---|
| 918 | +(MSG_CONFIRM) allowing to boot long images by dumb clients |
---|
| 919 | +not answering ARP requests until they are finally booted. |
---|
| 920 | +However, this is full functional and can be used in production. |
---|
| 921 | +.SH "AVAILABILITY" |
---|
| 922 | +.PP |
---|
| 923 | +\fBtftpd\fR is part of \fIiputils\fR package |
---|
| 924 | +and the latest versions are available in source form at |
---|
| 925 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|
| 926 | diff -Naur iputils-s20071127.orig/doc/tracepath.8 iputils-s20071127/doc/tracepath.8 |
---|
| 927 | --- iputils-s20071127.orig/doc/tracepath.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 928 | +++ iputils-s20071127/doc/tracepath.8 2009-02-18 20:53:04.000000000 -0800 |
---|
| 929 | @@ -0,0 +1,94 @@ |
---|
| 930 | +.\" This manpage has been automatically generated by docbook2man |
---|
| 931 | +.\" from a DocBook document. This tool can be found at: |
---|
| 932 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> |
---|
| 933 | +.\" Please send any bug reports, improvements, comments, patches, |
---|
| 934 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. |
---|
| 935 | +.TH "TRACEPATH" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 936 | +.SH NAME |
---|
| 937 | +tracepath, tracepath6 \- traces path to a network host discovering MTU along this path |
---|
| 938 | +.SH SYNOPSIS |
---|
| 939 | + |
---|
| 940 | +\fBtracepath\fR [\fB-n\fR] [\fB-l \fIpktlen\fB\fR] \fB\fIdestination\fB\fR [\fB\fIport\fB\fR] |
---|
| 941 | + |
---|
| 942 | +.SH "DESCRIPTION" |
---|
| 943 | +.PP |
---|
| 944 | +It traces path to \fIdestination\fR discovering MTU along this path. |
---|
| 945 | +It uses UDP port \fIport\fR or some random port. |
---|
| 946 | +It is similar to \fBtraceroute\fR, only does not not require superuser |
---|
| 947 | +privileges and has no fancy options. |
---|
| 948 | +.PP |
---|
| 949 | +\fBtracepath6\fR is good replacement for \fBtraceroute6\fR |
---|
| 950 | +and classic example of application of Linux error queues. |
---|
| 951 | +The situation with \fBtracepath\fR is worse, because commercial |
---|
| 952 | +IP routers do not return enough information in icmp error messages. |
---|
| 953 | +Probably, it will change, when they will be updated. |
---|
| 954 | +For now it uses Van Jacobson's trick, sweeping a range |
---|
| 955 | +of UDP ports to maintain trace history. |
---|
| 956 | +.SH "OPTIONS" |
---|
| 957 | +.TP |
---|
| 958 | +\fB-n\fR |
---|
| 959 | +Do not look up host names. Only print IP addresses numerically. |
---|
| 960 | +.TP |
---|
| 961 | +\fB-l\fR |
---|
| 962 | +Sets the initial packet length to \fIpktlen\fR instead of |
---|
| 963 | +65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR. |
---|
| 964 | +.SH "OUTPUT" |
---|
| 965 | +.PP |
---|
| 966 | + |
---|
| 967 | +.nf |
---|
| 968 | +root@mops:~ # tracepath6 3ffe:2400:0:109::2 |
---|
| 969 | + 1?: [LOCALHOST] pmtu 1500 |
---|
| 970 | + 1: dust.inr.ac.ru 0.411ms |
---|
| 971 | + 2: dust.inr.ac.ru asymm 1 0.390ms pmtu 1480 |
---|
| 972 | + 2: 3ffe:2400:0:109::2 463.514ms reached |
---|
| 973 | + Resume: pmtu 1480 hops 2 back 2 |
---|
| 974 | +.fi |
---|
| 975 | +.PP |
---|
| 976 | +The first column shows TTL of the probe, followed by colon. |
---|
| 977 | +Usually value of TTL is obtained from reply from network, |
---|
| 978 | +but sometimes reply does not contain necessary information and |
---|
| 979 | +we have to guess it. In this case the number is followed by ?. |
---|
| 980 | +.PP |
---|
| 981 | +The second column shows the network hop, which replied to the probe. |
---|
| 982 | +It is either address of router or word [LOCALHOST], if |
---|
| 983 | +the probe was not sent to the network. |
---|
| 984 | +.PP |
---|
| 985 | +The rest of line shows miscellaneous information about path to |
---|
| 986 | +the correspinding hetwork hop. As rule it contains value of RTT. |
---|
| 987 | +Additionally, it can show Path MTU, when it changes. |
---|
| 988 | +If the path is asymmetric |
---|
| 989 | +or the probe finishes before it reach prescribed hop, difference |
---|
| 990 | +between number of hops in forward and backward direction is shown |
---|
| 991 | +folloing keyword async. This information is not reliable. |
---|
| 992 | +F.e. the third line shows asymmetry of 1, it is because the first probe |
---|
| 993 | +with TTL of 2 was rejected at the first hop due to Path MTU Discovery. |
---|
| 994 | +.PP |
---|
| 995 | +Te last line summarizes information about all the path to the destination, |
---|
| 996 | +it shows detected Path MTU, amount of hops to the destination and our |
---|
| 997 | +guess about amount of hops from the destination to us, which can be |
---|
| 998 | +different when the path is asymmetric. |
---|
| 999 | +.SH "SEE ALSO" |
---|
| 1000 | +.PP |
---|
| 1001 | +\fBtraceroute\fR(8), |
---|
| 1002 | +\fBtraceroute6\fR(8), |
---|
| 1003 | +\fBping\fR(8). |
---|
| 1004 | +.SH "AUTHOR" |
---|
| 1005 | +.PP |
---|
| 1006 | +\fBtracepath\fR was written by |
---|
| 1007 | +Alexey Kuznetsov |
---|
| 1008 | +<kuznet@ms2.inr.ac.ru>. |
---|
| 1009 | +.SH "SECURITY" |
---|
| 1010 | +.PP |
---|
| 1011 | +No security issues. |
---|
| 1012 | +.PP |
---|
| 1013 | +This lapidary deserves to be elaborated. |
---|
| 1014 | +\fBtracepath\fR is not a privileged program, unlike |
---|
| 1015 | +\fBtraceroute\fR, \fBping\fR and other beasts of this kind. |
---|
| 1016 | +\fBtracepath\fR may be executed by everyone who has some access |
---|
| 1017 | +to network, enough to send UDP datagrams to investigated destination |
---|
| 1018 | +using given port. |
---|
| 1019 | +.SH "AVAILABILITY" |
---|
| 1020 | +.PP |
---|
| 1021 | +\fBtracepath\fR is part of \fIiputils\fR package |
---|
| 1022 | +and the latest versions are available in source form at |
---|
| 1023 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|
| 1024 | diff -Naur iputils-s20071127.orig/doc/traceroute6.8 iputils-s20071127/doc/traceroute6.8 |
---|
| 1025 | --- iputils-s20071127.orig/doc/traceroute6.8 1969-12-31 16:00:00.000000000 -0800 |
---|
| 1026 | +++ iputils-s20071127/doc/traceroute6.8 2009-02-18 20:53:04.000000000 -0800 |
---|
| 1027 | @@ -0,0 +1,42 @@ |
---|
| 1028 | +.\" This manpage has been automatically generated by docbook2man |
---|
| 1029 | +.\" from a DocBook document. This tool can be found at: |
---|
| 1030 | +.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> |
---|
| 1031 | +.\" Please send any bug reports, improvements, comments, patches, |
---|
| 1032 | +.\" etc. to Steve Cheng <steve@ggi-project.org>. |
---|
| 1033 | +.TH "TRACEROUTE6" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils" |
---|
| 1034 | +.SH NAME |
---|
| 1035 | +traceroute6 \- traces path to a network host |
---|
| 1036 | +.SH SYNOPSIS |
---|
| 1037 | + |
---|
| 1038 | +\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] |
---|
| 1039 | + |
---|
| 1040 | +.SH "DESCRIPTION" |
---|
| 1041 | +.PP |
---|
| 1042 | +Description can be found in |
---|
| 1043 | +\fBtraceroute\fR(8), |
---|
| 1044 | +all the references to IP replaced to IPv6. It is needless to copy |
---|
| 1045 | +the description from there. |
---|
| 1046 | +.SH "SEE ALSO" |
---|
| 1047 | +.PP |
---|
| 1048 | +\fBtraceroute\fR(8), |
---|
| 1049 | +\fBtracepath\fR(8), |
---|
| 1050 | +\fBping\fR(8). |
---|
| 1051 | +.SH "HISTORY" |
---|
| 1052 | +.PP |
---|
| 1053 | +This program has long history. Author of \fBtraceroute\fR |
---|
| 1054 | +is Van Jacobson and it first appeared in 1988. This clone is |
---|
| 1055 | +based on a port of \fBtraceroute\fR to IPv6 published |
---|
| 1056 | +in NRL IPv6 distribution in 1996. In turn, it was ported |
---|
| 1057 | +to Linux by Pedro Roque. After this it was kept in sync by |
---|
| 1058 | +Alexey Kuznetsov |
---|
| 1059 | +<kuznet@ms2.inr.ac.ru>. And eventually entered |
---|
| 1060 | +\fBiputils\fR package. |
---|
| 1061 | +.SH "SECURITY" |
---|
| 1062 | +.PP |
---|
| 1063 | +\fBtracepath6\fR requires CAP_NET_RAWIO capability |
---|
| 1064 | +to be executed. It is safe to be used as set-uid root. |
---|
| 1065 | +.SH "AVAILABILITY" |
---|
| 1066 | +.PP |
---|
| 1067 | +\fBtraceroute6\fR is part of \fIiputils\fR package |
---|
| 1068 | +and the latest versions are available in source form at |
---|
| 1069 | +http://www.skbuff.net/iputils/iputils-current.tar.bz2. |
---|