path: root/core/iputils/iputils-s20101006-manpages.patch

--- /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/arping.8	2011-01-19 04:10:18.000000000 -0500
@@ -0,0 +1,110 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "ARPING" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+arping \- send ARP REQUEST to a neighbour host
+.SH SYNOPSIS
+
+\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
+
+.SH "DESCRIPTION"
+.PP
+Ping \fIdestination\fR on device \fIinterface\fR by ARP packets,
+using source address \fIsource\fR.
+.SH "OPTIONS"
+.TP
+\fB-A\fR
+The same as \fB-U\fR, but ARP REPLY packets used instead
+of ARP REQUEST.
+.TP
+\fB-b\fR
+Send only MAC level broadcasts. Normally \fBarping\fR starts
+from sending broadcast, and switch to unicast after reply received.
+.TP
+\fB-c \fIcount\fB\fR
+Stop after sending \fIcount\fR ARP REQUEST
+packets. With 
+\fIdeadline\fR
+option, \fBarping\fR waits for
+\fIcount\fR ARP REPLY packets, until the timeout expires.
+.TP
+\fB-D\fR
+Duplicate address detection mode (DAD). See 
+RFC2131, 4.4.1.
+Returns 0, if DAD succeeded i.e. no replies are received
+.TP
+\fB-f\fR
+Finish after the first reply confirming that target is alive.
+.TP
+\fB-I \fIinterface\fB\fR
+Name of network device where to send ARP REQUEST packets. This option
+is required.
+.TP
+\fB-h\fR
+Print help page and exit.
+.TP
+\fB-q\fR
+Quiet output. Nothing is displayed.
+.TP
+\fB-s \fIsource\fB\fR
+IP source address to use in ARP packets.
+If this option is absent, source address is:
+.RS
+.TP 0.2i
+\(bu
+In DAD mode (with option \fB-D\fR) set to 0.0.0.0.
+.TP 0.2i
+\(bu
+In Unsolicited ARP mode (with options \fB-U\fR or \fB-A\fR)
+set to \fIdestination\fR.
+.TP 0.2i
+\(bu
+Otherwise, it is calculated from routing tables.
+.RE
+.TP
+\fB-U\fR
+Unsolicited ARP mode to update neighbours' ARP caches.
+No replies are expected.
+.TP
+\fB-V\fR
+Print version of the program and exit.
+.TP
+\fB-w \fIdeadline\fB\fR
+Specify a timeout, in seconds, before
+\fBarping\fR
+exits regardless of how many
+packets have been sent or received. In this case
+\fBarping\fR
+does not stop after
+\fIcount\fR
+packet are sent, it waits either for
+\fIdeadline\fR
+expire or until
+\fIcount\fR
+probes are answered.
+.SH "SEE ALSO"
+.PP
+\fBping\fR(8),
+\fBclockdiff\fR(8),
+\fBtracepath\fR(8).
+.SH "AUTHOR"
+.PP
+\fBarping\fR was written by
+Alexey Kuznetsov
+<kuznet@ms2.inr.ac.ru>.
+It is now maintained by
+YOSHIFUJI Hideaki
+<yoshfuji@skbuff.net>.
+.SH "SECURITY"
+.PP
+\fBarping\fR requires CAP_NET_RAWIO capability
+to be executed. It is not recommended to be used as set-uid root,
+because it allows user to modify ARP caches of neighbour hosts.
+.SH "AVAILABILITY"
+.PP
+\fBarping\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
--- /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/clockdiff.8	2011-01-19 04:10:19.000000000 -0500
@@ -0,0 +1,81 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "CLOCKDIFF" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+clockdiff \- measure clock difference between hosts
+.SH SYNOPSIS
+
+\fBclockdiff\fR [ \fB-o\fR]  [ \fB-o1\fR]  \fB\fIdestination\fB\fR
+
+.SH "DESCRIPTION"
+.PP
+\fBclockdiff\fR Measures clock difference between us and
+\fIdestination\fR with 1 msec resolution using ICMP TIMESTAMP
+[2]
+packets or, optionally, IP TIMESTAMP option
+[3]
+option added to ICMP ECHO.
+[1]
+.SH "OPTIONS"
+.TP
+\fB-o\fR
+Use IP TIMESTAMP with ICMP ECHO instead of ICMP TIMESTAMP
+messages. It is useful with some destinations, which do not support
+ICMP TIMESTAMP (f.e. Solaris <2.4).
+.TP
+\fB-o1\fR
+Slightly different form of \fB-o\fR, namely it uses three-term
+IP TIMESTAMP with prespecified hop addresses instead of four term one.
+What flavor works better depends on target host. Particularly,
+\fB-o\fR is better for Linux.
+.SH "WARNINGS"
+.TP 0.2i
+\(bu
+Some nodes (Cisco) use non-standard timestamps, which is allowed
+by RFC, but makes timestamps mostly useless.
+.TP 0.2i
+\(bu
+Some nodes generate messed timestamps (Solaris>2.4), when
+run \fBxntpd\fR. Seems, its IP stack uses a corrupted clock source,
+which is synchronized to time-of-day clock periodically and jumps
+randomly making timestamps mostly useless. Good news is that you can
+use NTP in this case, which is even better.
+.TP 0.2i
+\(bu
+\fBclockdiff\fR shows difference in time modulo 24 days.
+.SH "SEE ALSO"
+.PP
+\fBping\fR(8),
+\fBarping\fR(8),
+\fBtracepath\fR(8).
+.SH "REFERENCES"
+.PP
+[1] ICMP ECHO,
+RFC0792, page 14.
+.PP
+[2] ICMP TIMESTAMP,
+RFC0792, page 16.
+.PP
+[3] IP TIMESTAMP option,
+RFC0791, 3.1, page 16.
+.SH "AUTHOR"
+.PP
+\fBclockdiff\fR was compiled by
+Alexey Kuznetsov
+<kuznet@ms2.inr.ac.ru>. It was based on code borrowed
+from BSD \fBtimed\fR daemon.
+It is now maintained by
+YOSHIFUJI Hideaki
+<yoshfuji@skbuff.net>.
+.SH "SECURITY"
+.PP
+\fBclockdiff\fR requires CAP_NET_RAWIO capability
+to be executed. It is safe to be used as set-uid root.
+.SH "AVAILABILITY"
+.PP
+\fBclockdiff\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
--- /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/ping.8	2011-01-19 04:10:19.000000000 -0500
@@ -0,0 +1,408 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "PING" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+ping, ping6 \- send ICMP ECHO_REQUEST to network hosts
+.SH SYNOPSIS
+
+\fBping\fR [ \fB-LRUbdfnqrvVaAB\fR]  [ \fB-c \fIcount\fB\fR]  [ \fB-m \fImark\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-N \fInioption\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
+
+.SH "DESCRIPTION"
+.PP
+\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST
+datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway.
+ECHO_REQUEST datagrams (``pings'') have an IP and ICMP
+header, followed by a struct timeval and then an arbitrary
+number of ``pad'' bytes used to fill out the packet.
+.PP
+\fBping6\fR can also send Node Information Queries (RFC4620).
+.SH "OPTIONS"
+.TP
+\fB-a\fR
+Audible ping.
+.TP
+\fB-A\fR
+Adaptive ping. Interpacket interval adapts to round-trip time, so that
+effectively not more than one (or more, if preload is set) unanswered probes
+present in the network. Minimal interval is 200msec for not super-user.
+On networks with low rtt this mode is essentially equivalent to flood mode.  
+.TP
+\fB-b\fR
+Allow pinging a broadcast address.
+.TP
+\fB-B\fR
+Do not allow \fBping\fR to change source address of probes.
+The address is bound to one selected when \fBping\fR starts.
+.TP
+\fB-m \fImark\fB\fR
+use \fImark\fR to tag the packets going out. This is useful
+for variety of reasons within the kernel such as using policy
+routing to select specific outbound processing.
+.TP
+\fB-c \fIcount\fB\fR
+Stop after sending \fIcount\fR ECHO_REQUEST
+packets. With 
+\fIdeadline\fR
+option, \fBping\fR waits for
+\fIcount\fR ECHO_REPLY packets, until the timeout expires.
+.TP
+\fB-d\fR
+Set the SO_DEBUG option on the socket being used.
+Essentially, this socket option is not used by Linux kernel. 
+.TP
+\fB-F \fIflow label\fB\fR
+Allocate and set 20 bit flow label on echo request packets.
+(Only \fBping6\fR). If value is zero, kernel allocates random flow label.
+.TP
+\fB-f\fR
+Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed,
+while for ever ECHO_REPLY received a backspace is printed.
+This provides a rapid display of how many packets are being dropped.
+If interval is not given, it sets interval to zero and
+outputs packets as fast as they come back or one hundred times per second,
+whichever is more.
+Only the super-user may use this option with zero interval.
+.TP
+\fB-i \fIinterval\fB\fR
+Wait \fIinterval\fR seconds between sending each packet.
+The default is to wait for one second between each packet normally,
+or not to wait in flood mode. Only super-user may set interval
+to values less 0.2 seconds.
+.TP
+\fB-I \fIinterface address\fB\fR
+Set source address to specified interface address. Argument
+may be numeric IP address or name of device. When pinging IPv6
+link-local address this option is required.
+.TP
+\fB-l \fIpreload\fB\fR
+If \fIpreload\fR is specified,
+\fBping\fR sends that many packets not waiting for reply.
+Only the super-user may select preload more than 3.
+.TP
+\fB-L\fR
+Suppress loopback of multicast packets.  This flag only applies if the ping
+destination is a multicast address.
+.TP
+\fB-N \fInioption\fB\fR
+Send ICMPv6 Node Information Queries (RFC4620), instead of Echo Request.
+.RS
+.TP
+\fBname\fR
+Queries for Node Names.
+.RE
+.RS
+.TP
+\fBipv6\fR
+Queries for IPv6 Addresses. There are several IPv6 specific flags.
+.RS
+.TP
+\fBipv6-global\fR
+Request IPv6 global-scope addresses.
+.RE
+.RS
+.TP
+\fBipv6-sitelocal\fR
+Request IPv6 site-local addresses.
+.RE
+.RS
+.TP
+\fBipv6-linklocal\fR
+Request IPv6 link-local addresses.
+.RE
+.RS
+.TP
+\fBipv6-all\fR
+Request IPv6 addresses on other interfaces.
+.RE
+.RE
+.RS
+.TP
+\fBipv4\fR
+Queries for IPv4 Addresses.  There is one IPv4 specific flag.
+.RS
+.TP
+\fBipv4-all\fR
+Request IPv4 addresses on other interfaces.
+.RE
+.RE
+.RS
+.TP
+\fBsubject-ipv6=\fIipv6addr\fB\fR
+IPv6 subject address.
+.RE
+.RS
+.TP
+\fBsubject-ipv4=\fIipv4addr\fB\fR
+IPv4 subject address.
+.RE
+.RS
+.TP
+\fBsubject-name=\fInodename\fB\fR
+Subject name.  If it contains more than one dot,
+fully-qualified domain name is assumed.
+.RE
+.RS
+.TP
+\fBsubject-fqdn=\fInodename\fB\fR
+Subject name.  Fully-qualified domain name is
+always assumed.
+.RE
+.TP
+\fB-n\fR
+Numeric output only.
+No attempt will be made to lookup symbolic names for host addresses.
+.TP
+\fB-p \fIpattern\fB\fR
+You may specify up to 16 ``pad'' bytes to fill out the packet you send.
+This is useful for diagnosing data-dependent problems in a network.
+For example, \fB-p ff\fR will cause the sent packet
+to be filled with all ones.
+.TP
+\fB-D\fR
+Print timestamp (unix time + microseconds as in gettimeofday) before
+each line.
+.TP
+\fB-Q \fItos\fB\fR
+Set Quality of Service -related bits in ICMP datagrams.  
+\fItos\fR can be either decimal or hex number.
+Traditionally (RFC1349), these have been interpreted as: 0 for reserved
+(currently being redefined as congestion control), 1-4 for Type of Service
+and 5-7 for Precedence.
+Possible settings for Type of Service are: minimal cost: 0x02, 
+reliability: 0x04, throughput: 0x08, low delay: 0x10.  Multiple TOS bits
+should not be set simultaneously.  Possible settings for
+special Precedence range from priority (0x20) to net control (0xe0).  You
+must be root (CAP_NET_ADMIN capability) to use Critical or
+higher precedence value.  You cannot set
+bit 0x01 (reserved) unless ECN has been enabled in the kernel.
+In RFC2474, these fields has been redefined as 8-bit Differentiated
+Services (DS), consisting of: bits 0-1 of separate data (ECN will be used,
+here), and bits 2-7 of Differentiated Services Codepoint (DSCP).
+.TP
+\fB-q\fR
+Quiet output.
+Nothing is displayed except the summary lines at startup time and
+when finished.
+.TP
+\fB-R\fR
+Record route.
+Includes the RECORD_ROUTE option in the ECHO_REQUEST
+packet and displays the route buffer on returned packets.
+Note that the IP header is only large enough for nine such routes.
+Many hosts ignore or discard this option.
+.TP
+\fB-r\fR
+Bypass the normal routing tables and send directly to a host on an attached
+interface.
+If the host is not on a directly-attached network, an error is returned.
+This option can be used to ping a local host through an interface
+that has no route through it provided the option \fB-I\fR is also
+used.
+.TP
+\fB-s \fIpacketsize\fB\fR
+Specifies the number of data bytes to be sent.  
+The default is 56, which translates into 64 ICMP
+data bytes when combined with the 8 bytes of ICMP header data.
+.TP
+\fB-S \fIsndbuf\fB\fR
+Set socket sndbuf. If not specified, it is selected to buffer
+not more than one packet.
+.TP
+\fB-t \fIttl\fB\fR
+Set the IP Time to Live.
+.TP
+\fB-T \fItimestamp option\fB\fR
+Set special IP timestamp options.
+\fItimestamp option\fR may be either 
+\fItsonly\fR (only timestamps), 
+\fItsandaddr\fR (timestamps and addresses) or 
+\fItsprespec host1 [host2 [host3 [host4]]]\fR
+(timestamp prespecified hops).
+.TP
+\fB-M \fIhint\fB\fR
+Select Path MTU Discovery strategy.
+\fIhint\fR may be either \fIdo\fR
+(prohibit fragmentation, even local one), 
+\fIwant\fR (do PMTU discovery, fragment locally when packet size
+is large), or \fIdont\fR (do not set DF flag).
+.TP
+\fB-U\fR
+Print full user-to-user latency (the old behaviour). Normally
+\fBping\fR
+prints network round trip time, which can be different
+f.e. due to DNS failures. 
+.TP
+\fB-v\fR
+Verbose output.
+.TP
+\fB-V\fR
+Show version and exit.
+.TP
+\fB-w \fIdeadline\fB\fR
+Specify a timeout, in seconds, before
+\fBping\fR
+exits regardless of how many
+packets have been sent or received. In this case
+\fBping\fR
+does not stop after
+\fIcount\fR
+packet are sent, it waits either for
+\fIdeadline\fR
+expire or until
+\fIcount\fR
+probes are answered or for some error notification from network.   
+.TP
+\fB-W \fItimeout\fB\fR
+Time to wait for a response, in seconds. The option affects only timeout
+in absense of any responses, otherwise \fBping\fR waits for two RTTs.
+.PP
+When using \fBping\fR for fault isolation, it should first be run
+on the local host, to verify that the local network interface is up
+and running. Then, hosts and gateways further and further away should be
+``pinged''. Round-trip times and packet loss statistics are computed.
+If duplicate packets are received, they are not included in the packet
+loss calculation, although the round trip time of these packets is used
+in calculating the minimum/average/maximum round-trip time numbers.
+When the specified number of packets have been sent (and received) or
+if the program is terminated with a
+SIGINT, a brief summary is displayed. Shorter current statistics
+can be obtained without termination of process with signal
+SIGQUIT.
+.PP
+If \fBping\fR does not receive any reply packets at all it will
+exit with code 1. If a packet 
+\fIcount\fR
+and
+\fIdeadline\fR
+are both specified, and fewer than
+\fIcount\fR
+packets are received by the time the
+\fIdeadline\fR
+has arrived, it will also exit with code 1. 
+On other error it exits with code 2. Otherwise it exits with code 0. This
+makes it possible to use the exit code to see if a host is alive or
+not.
+.PP
+This program is intended for use in network testing, measurement and
+management.
+Because of the load it can impose on the network, it is unwise to use
+\fBping\fR during normal operations or from automated scripts.
+.SH "ICMP PACKET DETAILS"
+.PP
+An IP header without options is 20 bytes.
+An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth
+of ICMP header followed by an arbitrary amount of data.
+When a \fIpacketsize\fR is given, this indicated the size of this
+extra piece of data (the default is 56). Thus the amount of data received
+inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes
+more than the requested data space (the ICMP header).
+.PP
+If the data space is at least of size of struct timeval
+\fBping\fR uses the beginning bytes of this space to include
+a timestamp which it uses in the computation of round trip times.
+If the data space is shorter, no round trip times are given.
+.SH "DUPLICATE AND DAMAGED PACKETS"
+.PP
+\fBping\fR will report duplicate and damaged packets.
+Duplicate packets should never occur, and seem to be caused by
+inappropriate link-level retransmissions.
+Duplicates may occur in many situations and are rarely (if ever) a
+good sign, although the presence of low levels of duplicates may not
+always be cause for alarm.
+.PP
+Damaged packets are obviously serious cause for alarm and often
+indicate broken hardware somewhere in the
+\fBping\fR packet's path (in the network or in the hosts).
+.SH "TRYING DIFFERENT DATA PATTERNS"
+.PP
+The (inter)network layer should never treat packets differently depending
+on the data contained in the data portion.
+Unfortunately, data-dependent problems have been known to sneak into
+networks and remain undetected for long periods of time.
+In many cases the particular pattern that will have problems is something
+that doesn't have sufficient ``transitions'', such as all ones or all
+zeros, or a pattern right at the edge, such as almost all zeros.
+It isn't necessarily enough to specify a data pattern of all zeros (for
+example) on the command line because the pattern that is of interest is
+at the data link level, and the relationship between what you type and
+what the controllers transmit can be complicated.
+.PP
+This means that if you have a data-dependent problem you will probably
+have to do a lot of testing to find it.
+If you are lucky, you may manage to find a file that either can't be sent
+across your network or that takes much longer to transfer than other
+similar length files.
+You can then examine this file for repeated patterns that you can test
+using the \fB-p\fR option of \fBping\fR.
+.SH "TTL DETAILS"
+.PP
+The TTL value of an IP packet represents the maximum number of IP routers
+that the packet can go through before being thrown away.
+In current practice you can expect each router in the Internet to decrement
+the TTL field by exactly one.
+.PP
+The TCP/IP specification states that the TTL field for TCP
+packets should be set to 60, but many systems use smaller values
+(4.3 BSD uses 30, 4.2 used 15).
+.PP
+The maximum possible value of this field is 255, and most Unix systems set
+the TTL field of ICMP ECHO_REQUEST packets to 255.
+This is why you will find you can ``ping'' some hosts, but not reach them
+with
+\fBtelnet\fR(1)
+or
+\fBftp\fR(1).
+.PP
+In normal operation ping prints the ttl value from the packet it receives.
+When a remote system receives a ping packet, it can do one of three things
+with the TTL field in its response:
+.TP 0.2i
+\(bu
+Not change it; this is what Berkeley Unix systems did before the
+4.3BSD Tahoe release. In this case the TTL value in the received packet
+will be 255 minus the number of routers in the round-trip path.
+.TP 0.2i
+\(bu
+Set it to 255; this is what current Berkeley Unix systems do.
+In this case the TTL value in the received packet will be 255 minus the
+number of routers in the path \fBfrom\fR
+the remote system \fBto\fR the \fBping\fRing host.
+.TP 0.2i
+\(bu
+Set it to some other value. Some machines use the same value for
+ICMP packets that they use for TCP packets, for example either 30 or 60.
+Others may use completely wild values.
+.SH "BUGS"
+.TP 0.2i
+\(bu
+Many Hosts and Gateways ignore the RECORD_ROUTE option.
+.TP 0.2i
+\(bu
+The maximum IP header length is too small for options like
+RECORD_ROUTE to be completely useful.
+There's not much that that can be done about this, however.
+.TP 0.2i
+\(bu
+Flood pinging is not recommended in general, and flood pinging the
+broadcast address should only be done under very controlled conditions.
+.SH "SEE ALSO"
+.PP
+\fBnetstat\fR(1),
+\fBifconfig\fR(8).
+.SH "HISTORY"
+.PP
+The \fBping\fR command appeared in 4.3BSD.
+.PP
+The version described here is its descendant specific to Linux.
+.SH "SECURITY"
+.PP
+\fBping\fR requires CAP_NET_RAWIO capability
+to be executed. It may be used as set-uid root.
+.SH "AVAILABILITY"
+.PP
+\fBping\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
--- /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/rdisc.8	2011-01-19 04:10:20.000000000 -0500
@@ -0,0 +1,110 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "RDISC" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+rdisc \- network router discovery daemon
+.SH SYNOPSIS
+
+\fBrdisc\fR [ \fB-abdfstvV\fR]  [ \fB\fIsend_address\fB\fR]  [ \fB\fIreceive_address\fB\fR] 
+
+.SH "DESCRIPTION"
+.PP
+\fBrdisc\fR implements client side of the ICMP router discover protocol.
+\fBrdisc\fR is invoked at boot time to populate the network
+routing tables with default routes. 
+.PP
+\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address
+(or \fIreceive_address\fR provided it is given) 
+for ROUTER_ADVERTISE messages from routers. The received
+messages are handled by first ignoring those listed router addresses
+with which the host does not share a network. Among the remaining addresses
+the ones with the highest preference are selected as default routers
+and a default route is entered in the kernel routing table
+for each one of them.
+.PP
+Optionally, \fBrdisc\fR can avoid waiting for routers to announce 
+themselves by sending out a few ROUTER_SOLICITATION messages
+to the ALL_ROUTERS (224.0.0.2) multicast address 
+(or \fIsend_address\fR provided it is given) 
+when it is started.
+.PP
+A timer is associated with each router address and the address will
+no longer be considered for inclusion in the the routing tables if the 
+timer expires before a new 
+\fBadvertise\fR message is received from the router.
+The address will also be excluded from consideration if the host receives an 
+\fBadvertise\fR
+message with the preference being maximally negative.
+.PP
+Server side of router discovery protocol is supported by Cisco IOS
+and by any more or less complete UNIX routing daemon, f.e \fBgated\fR.
+.SH "OPTIONS"
+.TP
+\fB-a\fR
+Accept all routers independently of the preference they have in their 
+\fBadvertise\fR messages.
+Normally \fBrdisc\fR only accepts (and enters in the kernel routing
+tables) the router or routers with the highest preference.
+.TP
+\fB-b\fR
+Opposite to \fB-a\fR, i.e. install only router with the best
+preference value. It is default behaviour.
+.TP
+\fB-d\fR
+Send debugging messages to syslog.
+.TP
+\fB-f\fR
+Run \fBrdisc\fR forever even if no routers are found.
+Normally \fBrdisc\fR gives up if it has not received any 
+\fBadvertise\fR message after after soliciting three times,
+in which case it exits with a non-zero exit code.
+If \fB-f\fR is not specified in the first form then 
+\fB-s\fR must be specified.
+.TP
+\fB-s\fR
+Send three \fBsolicitation\fR messages initially to quickly discover
+the routers when the system is booted.
+When \fB-s\fR is specified \fBrdisc\fR
+exits with a non-zero exit code if it can not find any routers.
+This can be overridden with the \fB-f\fR option.
+.TP
+\fB-t\fR
+Test mode. Do not go to background.
+.TP
+\fB-v\fR
+Be verbose i.e. send lots of debugging messages to syslog.
+.TP
+\fB-V\fR
+Print version and exit.
+.SH "HISTORY"
+.PP
+This program was developed by Sun Microsystems (see copyright
+notice in source file). It was ported to Linux by
+Alexey Kuznetsov
+<kuznet@ms2.inr.ac.ru>.
+It is now maintained by
+YOSHIFUJI Hideaki
+<yoshfuji@skbuff.net>.
+.SH "SEE ALSO"
+.PP
+\fBicmp\fR(7),
+\fBinet\fR(7),
+\fBping\fR(8).
+.SH "REFERENCES"
+.PP
+Deering, S.E.,ed "ICMP Router Discovery Messages",
+RFC1256, Network Information Center, SRI International,
+Menlo Park, Calif., September 1991.
+.SH "SECURITY"
+.PP
+\fBrdisc\fR requires CAP_NET_RAWIO to listen
+and send ICMP messages and capability CAP_NET_ADMIN
+to update routing tables. 
+.SH "AVAILABILITY"
+.PP
+\fBrdisc\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
--- /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/tracepath.8	2011-01-19 04:10:20.000000000 -0500
@@ -0,0 +1,97 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "TRACEPATH" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+tracepath, tracepath6 \- traces path to a network host discovering MTU along this path
+.SH SYNOPSIS
+
+\fBtracepath\fR [ \fB-n\fR]  [ \fB-b\fR]  [ \fB-l \fIpktlen\fB\fR]  \fB\fIdestination\fB\fR [ \fB\fIport\fB\fR] 
+
+.SH "DESCRIPTION"
+.PP
+It traces path to \fIdestination\fR discovering MTU along this path.
+It uses UDP port \fIport\fR or some random port.
+It is similar to \fBtraceroute\fR, only does not require superuser
+privileges and has no fancy options.
+.PP
+\fBtracepath6\fR is good replacement for \fBtraceroute6\fR
+and classic example of application of Linux error queues.
+The situation with IPv4 is worse, because commercial
+IP routers do not return enough information in icmp error messages.
+Probably, it will change, when they will be updated.
+For now it uses Van Jacobson's trick, sweeping a range
+of UDP ports to maintain trace history.
+.SH "OPTIONS"
+.TP
+\fB-n\fR
+Print primarily IP addresses numerically.
+.TP
+\fB-b\fR
+Print both of host names and IP addresses.
+.TP
+\fB-l\fR
+Sets the initial packet length to \fIpktlen\fR instead of
+65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR.
+.SH "OUTPUT"
+.PP
+
+.nf
+root@mops:~ # tracepath6 3ffe:2400:0:109::2
+ 1?: [LOCALHOST]                              pmtu 1500
+ 1:  dust.inr.ac.ru                   0.411ms
+ 2:  dust.inr.ac.ru        asymm  1   0.390ms pmtu 1480
+ 2:  3ffe:2400:0:109::2               463.514ms reached
+     Resume: pmtu 1480 hops 2 back 2
+.fi
+.PP
+The first column shows TTL of the probe, followed by colon.
+Usually value of TTL is obtained from reply from network,
+but sometimes reply does not contain necessary information and
+we have to guess it. In this case the number is followed by ?.
+.PP
+The second column shows the network hop, which replied to the probe.
+It is either address of router or word [LOCALHOST], if
+the probe was not sent to the network.
+.PP
+The rest of line shows miscellaneous information about path to
+the correspinding hetwork hop. As rule it contains value of RTT.
+Additionally, it can show Path MTU, when it changes.
+If the path is asymmetric
+or the probe finishes before it reach prescribed hop, difference
+between number of hops in forward and backward direction is shown
+following keyword async. This information is not reliable.
+F.e. the third line shows asymmetry of 1, it is because the first probe
+with TTL of 2 was rejected at the first hop due to Path MTU Discovery.
+.PP
+The last line summarizes information about all the path to the destination,
+it shows detected Path MTU, amount of hops to the destination and our
+guess about amount of hops from the destination to us, which can be
+different when the path is asymmetric.
+.SH "SEE ALSO"
+.PP
+\fBtraceroute\fR(8),
+\fBtraceroute6\fR(8),
+\fBping\fR(8).
+.SH "AUTHOR"
+.PP
+\fBtracepath\fR was written by
+Alexey Kuznetsov
+<kuznet@ms2.inr.ac.ru>.
+.SH "SECURITY"
+.PP
+No security issues.
+.PP
+This lapidary deserves to be elaborated.
+\fBtracepath\fR is not a privileged program, unlike
+\fBtraceroute\fR, \fBping\fR and other beasts of this kind.
+\fBtracepath\fR may be executed by everyone who has some access
+to network, enough to send UDP datagrams to investigated destination
+using given port.
+.SH "AVAILABILITY"
+.PP
+\fBtracepath\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
diff -Naur /dev/null iputils-s20101006/doc/rarpd.8
---  /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/rarpd.8	2011-01-08 20:09:51.270811811 -0500
@@ -0,0 +1,84 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "RARPD" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+rarpd \- answer RARP REQUESTs
+.SH SYNOPSIS
+
+\fBarping\fR [\fB-aAvde\fR] [\fB-b \fIbootdir\fB\fR] [\fB\fIinterface\fB\fR]
+
+.SH "DESCRIPTION"
+.PP
+Listens
+RARP
+requests from clients. Provided MAC address of client
+is found in \fI/etc/ethers\fR database and
+obtained host name is resolvable to an IP address appropriate
+for attached network, \fBrarpd\fR answers to client with RARPD
+reply carrying an IP address.
+.PP
+To allow multiple boot servers on the network \fBrarpd\fR
+optionally checks for presence Sun-like bootable image in TFTP directory.
+It should have form \fBHexadecimal_IP.ARCH\fR, f.e. to load
+sparc 193.233.7.98 \fIC1E90762.SUN4M\fR is linked to
+an image appropriate for SUM4M in directory \fI/etc/tftpboot\fR.
+.SH "WARNING"
+.PP
+This facility is deeply obsoleted by
+BOOTP
+and later
+DHCP protocols.
+However, some clients really still need this to boot.
+.SH "OPTIONS"
+.TP
+\fB-a\fR
+Listen on all the interfaces. Currently it is an internal
+option, its function is overridden with \fIinterface\fR
+argument. It should not be used.
+.TP
+\fB-A\fR
+Listen not only RARP but also ARP messages, some rare clients
+use ARP by some unknown reason.
+.TP
+\fB-v\fR
+Be verbose.
+.TP
+\fB-d\fR
+Debug mode. Do not go to background.
+.TP
+\fB-e\fR
+Do not check for presence of a boot image, reply if MAC address
+resolves to a valid IP address using \fI/etc/ethers\fR
+database and DNS. 
+.TP
+\fB-b \fIbootdir\fB\fR
+TFTP boot directory. Default is \fI/etc/tftpboot\fR
+.SH "SEE ALSO"
+.PP
+\fBarping\fR(8),
+\fBtftpd\fR(8).
+.SH "AUTHOR"
+.PP
+\fBrarpd\fR was written by
+Alexey Kuznetsov
+<kuznet@ms2.inr.ac.ru>.
+It is now maintained by
+YOSHIFUJI Hideaki
+<yoshfuji@skbuff.net>.
+.SH "SECURITY"
+.PP
+\fBrarpd\fR requires CAP_NET_RAWIO capability
+to listen and send RARP and ARP packets. It also needs CAP_NET_ADMIN
+to give to kernel hint for ARP resolution; this is not strictly required,
+but some (most of, to be more exact) clients are so badly broken that
+are not able to answer ARP before they are finally booted. This is
+not wonderful taking into account that clients using RARPD in 2002
+are all unsupported relic creatures of 90's and even earlier.
+.SH "AVAILABILITY"
+.PP
+\fBrarpd\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
diff -Naur /dev/null iputils-s20101006/doc/tftpd.8
--- /dev/null	2011-01-26 09:02:28.396666668 -0500
+++ iputils-s20101006/doc/tftpd.8	2011-01-08 20:09:51.723407498 -0500
@@ -0,0 +1,85 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "TFTPD" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+tftpd \- Trivial File Transfer Protocol server
+.SH SYNOPSIS
+
+\fBtftpd\fR \fB\fIdirectory\fB\fR
+
+.SH "DESCRIPTION"
+.PP
+\fBtftpd\fR is a server which supports the DARPA
+Trivial File Transfer Protocol
+(RFC1350).
+The TFTP server is started
+by \fBinetd\fR(8).
+.PP
+\fIdirectory\fR is required argument; if it is not given
+\fBtftpd\fR aborts. This path is prepended to any file name requested
+via TFTP protocol, effectively chrooting \fBtftpd\fR to this directory.
+File names are validated not to escape out of this directory, however
+administrator may configure such escape using symbolic links.
+.PP
+It is in difference of variants of \fBtftpd\fR usually distributed
+with unix-like systems, which take a list of directories and match
+file names to start from one of given prefixes or to some random
+default, when no arguments were given. There are two reasons not to
+behave in this way: first, it is inconvenient, clients are not expected
+to know something about layout of filesystem on server host.
+And second, TFTP protocol is not a tool for browsing of server's filesystem,
+it is just an agent allowing to boot dumb clients. 
+.PP
+In the case when \fBtftpd\fR is used together with
+\fBrarpd\fR(8),
+tftp directories in these services should coincide and it is expected
+that each client booted via TFTP has boot image corresponding
+its IP address with an architecture suffix following Sun Microsystems
+conventions. See 
+\fBrarpd\fR(8)
+for more details.
+.SH "SECURITY"
+.PP
+TFTP protocol does not provide any authentication.
+Due to this capital flaw \fBtftpd\fR is not able to restrict
+access to files and will allow only publically readable
+files to be accessed. Files may be written only if they already
+exist and are publically writable.
+.PP
+Impact is evident, directory exported via TFTP \fBmust not\fR
+contain sensitive information of any kind, everyone is allowed
+to read it as soon as a client is allowed. Boot images do not contain
+such information as rule, however you should think twice before
+publishing f.e. Cisco IOS config files via TFTP, they contain
+\fBunencrypted\fR passwords and may contain some information
+about the network, which you were not going to make public.
+.PP
+The \fBtftpd\fR server should be executed by \fBinetd\fR
+with dropped root privileges, namely with a user ID giving minimal
+access to files published in tftp directory. If it is executed
+as superuser occasionally, \fBtftpd\fR drops its UID and GID
+to 65534, which is most likely not the thing which you expect.
+However, this is not very essential; remember, only files accessible
+for everyone can be read or written via TFTP.
+.SH "SEE ALSO"
+.PP
+\fBrarpd\fR(8),
+\fBtftp\fR(1),
+\fBinetd\fR(8).
+.SH "HISTORY"
+.PP
+The \fBtftpd\fR command appeared in 4.2BSD. The source in iputils
+is cleaned up both syntactically (ANSIized) and semantically (UDP socket IO).
+.PP
+It is distributed with iputils mostly as good demo of an interesting feature
+(MSG_CONFIRM) allowing to boot long images by dumb clients
+not answering ARP requests until they are finally booted.
+However, this is full functional and can be used in production.
+.SH "AVAILABILITY"
+.PP
+\fBtftpd\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
diff -Naur /dev/null iputils-s20101006/doc/traceroute6.8
--- /dev/null	1969-12-31 19:00:00.000000000 -0500
+++ iputils-s20101006/doc/traceroute6.8	2011-01-08 20:09:52.114781859 -0500
@@ -0,0 +1,42 @@
+.\" This manpage has been automatically generated by docbook2man 
+.\" from a DocBook document.  This tool can be found at:
+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
+.\" Please send any bug reports, improvements, comments, patches, 
+.\" etc. to Steve Cheng <steve@ggi-project.org>.
+.TH "TRACEROUTE6" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils"
+.SH NAME
+traceroute6 \- traces path to a network host
+.SH SYNOPSIS
+
+\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]
+
+.SH "DESCRIPTION"
+.PP
+Description can be found in 
+\fBtraceroute\fR(8),
+all the references to IP replaced to IPv6. It is needless to copy
+the description from there.
+.SH "SEE ALSO"
+.PP
+\fBtraceroute\fR(8),
+\fBtracepath\fR(8),
+\fBping\fR(8).
+.SH "HISTORY"
+.PP
+This program has long history. Author of \fBtraceroute\fR
+is Van Jacobson and it first appeared in 1988. This clone is
+based on a port of \fBtraceroute\fR to IPv6 published
+in NRL IPv6 distribution in 1996. In turn, it was ported
+to Linux by Pedro Roque. After this it was kept in sync by    
+Alexey Kuznetsov
+<kuznet@ms2.inr.ac.ru>. And eventually entered
+\fBiputils\fR package.
+.SH "SECURITY"
+.PP
+\fBtracepath6\fR requires CAP_NET_RAWIO capability
+to be executed. It is safe to be used as set-uid root.
+.SH "AVAILABILITY"
+.PP
+\fBtraceroute6\fR is part of \fIiputils\fR package
+and the latest versions are  available in source form at
+http://www.skbuff.net/iputils/iputils-current.tar.bz2.