source: patches/iputils-s20071127-manpages-2.patch@ 8fed28a

clfs-1.2 clfs-2.1 clfs-3.0.0-systemd clfs-3.0.0-sysvinit systemd sysvinit
Last change on this file since 8fed28a was 8201ceeb, checked in by Jim Gifford <clfs@…>, 16 years ago

Corrected Patch for iputils

  • Property mode set to 100644
File size: 29.2 KB
  • TabularUnified doc/arping.8

    Submitted By: Jim Gifford <jim at cross-lfs dot org>
    Date: 2009-02-18
    Initial Package Version: s20071127
    Upstream Status: Unknown
    Origin: Jim Gifford
    Description: Provides the man pages (adding docbook2man with all its
                 dependencies would be a major addition to the book, so I built it
                 -once- on a completed system and saved the data).
    
    diff -Naur doc/arping.8 doc/arping.8
     
     1.\" This manpage has been automatically generated by docbook2man
     2.\" from a DocBook document.  This tool can be found at:
     3.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
     4.\" Please send any bug reports, improvements, comments, patches,
     5.\" etc. to Steve Cheng <steve@ggi-project.org>.
     6.TH "ARPING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
     7.SH NAME
     8arping \- send ARP REQUEST to a neighbour host
     9.SH SYNOPSIS
     10
     11\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
     12
     13.SH "DESCRIPTION"
     14.PP
     15Ping \fIdestination\fR on device \fIinterface\fR by ARP packets,
     16using source address \fIsource\fR.
     17.SH "OPTIONS"
     18.TP
     19\fB-A\fR
     20The same as \fB-U\fR, but ARP REPLY packets used instead
     21of ARP REQUEST.
     22.TP
     23\fB-b\fR
     24Send only MAC level broadcasts. Normally \fBarping\fR starts
     25from sending broadcast, and switch to unicast after reply received.
     26.TP
     27\fB-c \fIcount\fB\fR
     28Stop after sending \fIcount\fR ARP REQUEST
     29packets. With
     30\fIdeadline\fR
     31option, \fBarping\fR waits for
     32\fIcount\fR ARP REPLY packets, until the timeout expires.
     33.TP
     34\fB-D\fR
     35Duplicate address detection mode (DAD). See
     36RFC2131, 4.4.1.
     37Returns 0, if DAD succeeded i.e. no replies are received
     38.TP
     39\fB-f\fR
     40Finish after the first reply confirming that target is alive.
     41.TP
     42\fB-I \fIinterface\fB\fR
     43Name of network device where to send ARP REQUEST packets. This option
     44is required.
     45.TP
     46\fB-h\fR
     47Print help page and exit.
     48.TP
     49\fB-q\fR
     50Quiet output. Nothing is displayed.
     51.TP
     52\fB-s \fIsource\fB\fR
     53IP source address to use in ARP packets.
     54If this option is absent, source address is:
     55.RS
     56.TP 0.2i
     57\(bu
     58In DAD mode (with option \fB-D\fR) set to 0.0.0.0.
     59.TP 0.2i
     60\(bu
     61In Unsolicited ARP mode (with options \fB-U\fR or \fB-A\fR)
     62set to \fIdestination\fR.
     63.TP 0.2i
     64\(bu
     65Otherwise, it is calculated from routing tables.
     66.RE
     67.TP
     68\fB-U\fR
     69Unsolicited ARP mode to update neighbours' ARP caches.
     70No replies are expected.
     71.TP
     72\fB-V\fR
     73Print version of the program and exit.
     74.TP
     75\fB-w \fIdeadline\fB\fR
     76Specify a timeout, in seconds, before
     77\fBarping\fR
     78exits regardless of how many
     79packets have been sent or received. In this case
     80\fBarping\fR
     81does not stop after
     82\fIcount\fR
     83packet are sent, it waits either for
     84\fIdeadline\fR
     85expire or until
     86\fIcount\fR
     87probes are answered.
     88.SH "SEE ALSO"
     89.PP
     90\fBping\fR(8),
     91\fBclockdiff\fR(8),
     92\fBtracepath\fR(8).
     93.SH "AUTHOR"
     94.PP
     95\fBarping\fR was written by
     96Alexey Kuznetsov
     97<kuznet@ms2.inr.ac.ru>.
     98It is now maintained by
     99YOSHIFUJI Hideaki
     100<yoshfuji@skbuff.net>.
     101.SH "SECURITY"
     102.PP
     103\fBarping\fR requires CAP_NET_RAWIO capability
     104to be executed. It is not recommended to be used as set-uid root,
     105because it allows user to modify ARP caches of neighbour hosts.
     106.SH "AVAILABILITY"
     107.PP
     108\fBarping\fR is part of \fIiputils\fR package
     109and the latest versions are  available in source form at
     110http://www.skbuff.net/iputils/iputils-current.tar.bz2.
  • TabularUnified doc/clockdiff.8

    diff -Naur doc/clockdiff.8 doc/clockdiff.8
     
     1.\" This manpage has been automatically generated by docbook2man
     2.\" from a DocBook document.  This tool can be found at:
     3.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
     4.\" Please send any bug reports, improvements, comments, patches,
     5.\" etc. to Steve Cheng <steve@ggi-project.org>.
     6.TH "CLOCKDIFF" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
     7.SH NAME
     8clockdiff \- measure clock difference between hosts
     9.SH SYNOPSIS
     10
     11\fBclockdiff\fR [\fB-o\fR] [\fB-o1\fR] \fB\fIdestination\fB\fR
     12
     13.SH "DESCRIPTION"
     14.PP
     15\fBclockdiff\fR Measures clock difference between us and
     16\fIdestination\fR with 1 msec resolution using ICMP TIMESTAMP
     17[2]
     18packets or, optionally, IP TIMESTAMP option
     19[3]
     20option added to ICMP ECHO.
     21[1]
     22.SH "OPTIONS"
     23.TP
     24\fB-o\fR
     25Use IP TIMESTAMP with ICMP ECHO instead of ICMP TIMESTAMP
     26messages. It is useful with some destinations, which do not support
     27ICMP TIMESTAMP (f.e. Solaris <2.4).
     28.TP
     29\fB-o1\fR
     30Slightly different form of \fB-o\fR, namely it uses three-term
     31IP TIMESTAMP with prespecified hop addresses instead of four term one.
     32What flavor works better depends on target host. Particularly,
     33\fB-o\fR is better for Linux.
     34.SH "WARNINGS"
     35.TP 0.2i
     36\(bu
     37Some nodes (Cisco) use non-standard timestamps, which is allowed
     38by RFC, but makes timestamps mostly useless.
     39.TP 0.2i
     40\(bu
     41Some nodes generate messed timestamps (Solaris>2.4), when
     42run \fBxntpd\fR. Seems, its IP stack uses a corrupted clock source,
     43which is synchronized to time-of-day clock periodically and jumps
     44randomly making timestamps mostly useless. Good news is that you can
     45use NTP in this case, which is even better.
     46.TP 0.2i
     47\(bu
     48\fBclockdiff\fR shows difference in time modulo 24 days.
     49.SH "SEE ALSO"
     50.PP
     51\fBping\fR(8),
     52\fBarping\fR(8),
     53\fBtracepath\fR(8).
     54.SH "REFERENCES"
     55.PP
     56[1] ICMP ECHO,
     57RFC0792, page 14.
     58.PP
     59[2] ICMP TIMESTAMP,
     60RFC0792, page 16.
     61.PP
     62[3] IP TIMESTAMP option,
     63RFC0791, 3.1, page 16.
     64.SH "AUTHOR"
     65.PP
     66\fBclockdiff\fR was compiled by
     67Alexey Kuznetsov
     68<kuznet@ms2.inr.ac.ru>. It was based on code borrowed
     69from BSD \fBtimed\fR daemon.
     70It is now maintained by
     71YOSHIFUJI Hideaki
     72<yoshfuji@skbuff.net>.
     73.SH "SECURITY"
     74.PP
     75\fBclockdiff\fR requires CAP_NET_RAWIO capability
     76to be executed. It is safe to be used as set-uid root.
     77.SH "AVAILABILITY"
     78.PP
     79\fBclockdiff\fR is part of \fIiputils\fR package
     80and the latest versions are  available in source form at
     81http://www.skbuff.net/iputils/iputils-current.tar.bz2.
  • TabularUnified doc/ping.8

    diff -Naur doc/ping.8 doc/ping.8
     
     1.\" This manpage has been automatically generated by docbook2man
     2.\" from a DocBook document.  This tool can be found at:
     3.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
     4.\" Please send any bug reports, improvements, comments, patches,
     5.\" etc. to Steve Cheng <steve@ggi-project.org>.
     6.TH "PING" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
     7.SH NAME
     8ping, ping6 \- send ICMP ECHO_REQUEST to network hosts
     9.SH SYNOPSIS
     10
     11\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
     12
     13.SH "DESCRIPTION"
     14.PP
     15\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST
     16datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway.
     17ECHO_REQUEST datagrams (``pings'') have an IP and ICMP
     18header, followed by a struct timeval and then an arbitrary
     19number of ``pad'' bytes used to fill out the packet.
     20.SH "OPTIONS"
     21.TP
     22\fB-a\fR
     23Audible ping.
     24.TP
     25\fB-A\fR
     26Adaptive ping. Interpacket interval adapts to round-trip time, so that
     27effectively not more than one (or more, if preload is set) unanswered probes
     28present in the network. Minimal interval is 200msec for not super-user.
     29On networks with low rtt this mode is essentially equivalent to flood mode. 
     30.TP
     31\fB-b\fR
     32Allow pinging a broadcast address.
     33.TP
     34\fB-B\fR
     35Do not allow \fBping\fR to change source address of probes.
     36The address is bound to one selected when \fBping\fR starts.
     37.TP
     38\fB-c \fIcount\fB\fR
     39Stop after sending \fIcount\fR ECHO_REQUEST
     40packets. With
     41\fIdeadline\fR
     42option, \fBping\fR waits for
     43\fIcount\fR ECHO_REPLY packets, until the timeout expires.
     44.TP
     45\fB-d\fR
     46Set the SO_DEBUG option on the socket being used.
     47Essentially, this socket option is not used by Linux kernel.
     48.TP
     49\fB-F \fIflow label\fB\fR
     50Allocate and set 20 bit flow label on echo request packets.
     51(Only \fBping6\fR). If value is zero, kernel allocates random flow label.
     52.TP
     53\fB-f\fR
     54Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed,
     55while for ever ECHO_REPLY received a backspace is printed.
     56This provides a rapid display of how many packets are being dropped.
     57If interval is not given, it sets interval to zero and
     58outputs packets as fast as they come back or one hundred times per second,
     59whichever is more.
     60Only the super-user may use this option with zero interval.
     61.TP
     62\fB-i \fIinterval\fB\fR
     63Wait \fIinterval\fR seconds between sending each packet.
     64The default is to wait for one second between each packet normally,
     65or not to wait in flood mode. Only super-user may set interval
     66to values less 0.2 seconds.
     67.TP
     68\fB-I \fIinterface address\fB\fR
     69Set source address to specified interface address. Argument
     70may be numeric IP address or name of device. When pinging IPv6
     71link-local address this option is required.
     72.TP
     73\fB-l \fIpreload\fB\fR
     74If \fIpreload\fR is specified,
     75\fBping\fR sends that many packets not waiting for reply.
     76Only the super-user may select preload more than 3.
     77.TP
     78\fB-L\fR
     79Suppress loopback of multicast packets.  This flag only applies if the ping
     80destination is a multicast address.
     81.TP
     82\fB-n\fR
     83Numeric output only.
     84No attempt will be made to lookup symbolic names for host addresses.
     85.TP
     86\fB-p \fIpattern\fB\fR
     87You may specify up to 16 ``pad'' bytes to fill out the packet you send.
     88This is useful for diagnosing data-dependent problems in a network.
     89For example, \fB-p ff\fR will cause the sent packet
     90to be filled with all ones.
     91.TP
     92\fB-Q \fItos\fB\fR
     93Set Quality of Service -related bits in ICMP datagrams. 
     94\fItos\fR can be either decimal or hex number.
     95Traditionally (RFC1349), these have been interpreted as: 0 for reserved
     96(currently being redefined as congestion control), 1-4 for Type of Service
     97and 5-7 for Precedence.
     98Possible settings for Type of Service are: minimal cost: 0x02,
     99reliability: 0x04, throughput: 0x08, low delay: 0x10.  Multiple TOS bits
     100should not be set simultaneously.  Possible settings for
     101special Precedence range from priority (0x20) to net control (0xe0).  You
     102must be root (CAP_NET_ADMIN capability) to use Critical or
     103higher precedence value.  You cannot set
     104bit 0x01 (reserved) unless ECN has been enabled in the kernel.
     105In RFC2474, these fields has been redefined as 8-bit Differentiated
     106Services (DS), consisting of: bits 0-1 of separate data (ECN will be used,
     107here), and bits 2-7 of Differentiated Services Codepoint (DSCP).
     108.TP
     109\fB-q\fR
     110Quiet output.
     111Nothing is displayed except the summary lines at startup time and
     112when finished.
     113.TP
     114\fB-R\fR
     115Record route.
     116Includes the RECORD_ROUTE option in the ECHO_REQUEST
     117packet and displays the route buffer on returned packets.
     118Note that the IP header is only large enough for nine such routes.
     119Many hosts ignore or discard this option.
     120.TP
     121\fB-r\fR
     122Bypass the normal routing tables and send directly to a host on an attached
     123interface.
     124If the host is not on a directly-attached network, an error is returned.
     125This option can be used to ping a local host through an interface
     126that has no route through it provided the option \fB-I\fR is also
     127used.
     128.TP
     129\fB-s \fIpacketsize\fB\fR
     130Specifies the number of data bytes to be sent. 
     131The default is 56, which translates into 64 ICMP
     132data bytes when combined with the 8 bytes of ICMP header data.
     133.TP
     134\fB-S \fIsndbuf\fB\fR
     135Set socket sndbuf. If not specified, it is selected to buffer
     136not more than one packet.
     137.TP
     138\fB-t \fIttl\fB\fR
     139Set the IP Time to Live.
     140.TP
     141\fB-T \fItimestamp option\fB\fR
     142Set special IP timestamp options.
     143\fItimestamp option\fR may be either
     144\fItsonly\fR (only timestamps),
     145\fItsandaddr\fR (timestamps and addresses) or
     146\fItsprespec host1 [host2 [host3 [host4]]]\fR
     147(timestamp prespecified hops).
     148.TP
     149\fB-M \fIhint\fB\fR
     150Select Path MTU Discovery strategy.
     151\fIhint\fR may be either \fIdo\fR
     152(prohibit fragmentation, even local one),
     153\fIwant\fR (do PMTU discovery, fragment locally when packet size
     154is large), or \fIdont\fR (do not set DF flag).
     155.TP
     156\fB-U\fR
     157Print full user-to-user latency (the old behaviour). Normally
     158\fBping\fR
     159prints network round trip time, which can be different
     160f.e. due to DNS failures.
     161.TP
     162\fB-v\fR
     163Verbose output.
     164.TP
     165\fB-V\fR
     166Show version and exit.
     167.TP
     168\fB-w \fIdeadline\fB\fR
     169Specify a timeout, in seconds, before
     170\fBping\fR
     171exits regardless of how many
     172packets have been sent or received. In this case
     173\fBping\fR
     174does not stop after
     175\fIcount\fR
     176packet are sent, it waits either for
     177\fIdeadline\fR
     178expire or until
     179\fIcount\fR
     180probes are answered or for some error notification from network.   
     181.TP
     182\fB-W \fItimeout\fB\fR
     183Time to wait for a response, in seconds. The option affects only timeout
     184in absense of any responses, otherwise \fBping\fR waits for two RTTs.
     185.PP
     186When using \fBping\fR for fault isolation, it should first be run
     187on the local host, to verify that the local network interface is up
     188and running. Then, hosts and gateways further and further away should be
     189``pinged''. Round-trip times and packet loss statistics are computed.
     190If duplicate packets are received, they are not included in the packet
     191loss calculation, although the round trip time of these packets is used
     192in calculating the minimum/average/maximum round-trip time numbers.
     193When the specified number of packets have been sent (and received) or
     194if the program is terminated with a
     195SIGINT, a brief summary is displayed. Shorter current statistics
     196can be obtained without termination of process with signal
     197SIGQUIT.
     198.PP
     199If \fBping\fR does not receive any reply packets at all it will
     200exit with code 1. If a packet
     201\fIcount\fR
     202and
     203\fIdeadline\fR
     204are both specified, and fewer than
     205\fIcount\fR
     206packets are received by the time the
     207\fIdeadline\fR
     208has arrived, it will also exit with code 1.
     209On other error it exits with code 2. Otherwise it exits with code 0. This
     210makes it possible to use the exit code to see if a host is alive or
     211not.
     212.PP
     213This program is intended for use in network testing, measurement and
     214management.
     215Because of the load it can impose on the network, it is unwise to use
     216\fBping\fR during normal operations or from automated scripts.
     217.SH "ICMP PACKET DETAILS"
     218.PP
     219An IP header without options is 20 bytes.
     220An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth
     221of ICMP header followed by an arbitrary amount of data.
     222When a \fIpacketsize\fR is given, this indicated the size of this
     223extra piece of data (the default is 56). Thus the amount of data received
     224inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes
     225more than the requested data space (the ICMP header).
     226.PP
     227If the data space is at least of size of struct timeval
     228\fBping\fR uses the beginning bytes of this space to include
     229a timestamp which it uses in the computation of round trip times.
     230If the data space is shorter, no round trip times are given.
     231.SH "DUPLICATE AND DAMAGED PACKETS"
     232.PP
     233\fBping\fR will report duplicate and damaged packets.
     234Duplicate packets should never occur, and seem to be caused by
     235inappropriate link-level retransmissions.
     236Duplicates may occur in many situations and are rarely (if ever) a
     237good sign, although the presence of low levels of duplicates may not
     238always be cause for alarm.
     239.PP
     240Damaged packets are obviously serious cause for alarm and often
     241indicate broken hardware somewhere in the
     242\fBping\fR packet's path (in the network or in the hosts).
     243.SH "TRYING DIFFERENT DATA PATTERNS"
     244.PP
     245The (inter)network layer should never treat packets differently depending
     246on the data contained in the data portion.
     247Unfortunately, data-dependent problems have been known to sneak into
     248networks and remain undetected for long periods of time.
     249In many cases the particular pattern that will have problems is something
     250that doesn't have sufficient ``transitions'', such as all ones or all
     251zeros, or a pattern right at the edge, such as almost all zeros.
     252It isn't necessarily enough to specify a data pattern of all zeros (for
     253example) on the command line because the pattern that is of interest is
     254at the data link level, and the relationship between what you type and
     255what the controllers transmit can be complicated.
     256.PP
     257This means that if you have a data-dependent problem you will probably
     258have to do a lot of testing to find it.
     259If you are lucky, you may manage to find a file that either can't be sent
     260across your network or that takes much longer to transfer than other
     261similar length files.
     262You can then examine this file for repeated patterns that you can test
     263using the \fB-p\fR option of \fBping\fR.
     264.SH "TTL DETAILS"
     265.PP
     266The TTL value of an IP packet represents the maximum number of IP routers
     267that the packet can go through before being thrown away.
     268In current practice you can expect each router in the Internet to decrement
     269the TTL field by exactly one.
     270.PP
     271The TCP/IP specification states that the TTL field for TCP
     272packets should be set to 60, but many systems use smaller values
     273(4.3 BSD uses 30, 4.2 used 15).
     274.PP
     275The maximum possible value of this field is 255, and most Unix systems set
     276the TTL field of ICMP ECHO_REQUEST packets to 255.
     277This is why you will find you can ``ping'' some hosts, but not reach them
     278with
     279\fBtelnet\fR(1)
     280or
     281\fBftp\fR(1).
     282.PP
     283In normal operation ping prints the ttl value from the packet it receives.
     284When a remote system receives a ping packet, it can do one of three things
     285with the TTL field in its response:
     286.TP 0.2i
     287\(bu
     288Not change it; this is what Berkeley Unix systems did before the
     2894.3BSD Tahoe release. In this case the TTL value in the received packet
     290will be 255 minus the number of routers in the round-trip path.
     291.TP 0.2i
     292\(bu
     293Set it to 255; this is what current Berkeley Unix systems do.
     294In this case the TTL value in the received packet will be 255 minus the
     295number of routers in the path \fBfrom\fR
     296the remote system \fBto\fR the \fBping\fRing host.
     297.TP 0.2i
     298\(bu
     299Set it to some other value. Some machines use the same value for
     300ICMP packets that they use for TCP packets, for example either 30 or 60.
     301Others may use completely wild values.
     302.SH "BUGS"
     303.TP 0.2i
     304\(bu
     305Many Hosts and Gateways ignore the RECORD_ROUTE option.
     306.TP 0.2i
     307\(bu
     308The maximum IP header length is too small for options like
     309RECORD_ROUTE to be completely useful.
     310There's not much that that can be done about this, however.
     311.TP 0.2i
     312\(bu
     313Flood pinging is not recommended in general, and flood pinging the
     314broadcast address should only be done under very controlled conditions.
     315.SH "SEE ALSO"
     316.PP
     317\fBnetstat\fR(1),
     318\fBifconfig\fR(8).
     319.SH "HISTORY"
     320.PP
     321The \fBping\fR command appeared in 4.3BSD.
     322.PP
     323The version described here is its descendant specific to Linux.
     324.SH "SECURITY"
     325.PP
     326\fBping\fR requires CAP_NET_RAWIO capability
     327to be executed. It may be used as set-uid root.
     328.SH "AVAILABILITY"
     329.PP
     330\fBping\fR is part of \fIiputils\fR package
     331and the latest versions are  available in source form at
     332http://www.skbuff.net/iputils/iputils-current.tar.bz2.
  • TabularUnified doc/rdisc.8

    diff -Naur doc/rdisc.8 doc/rdisc.8
     
     1.\" This manpage has been automatically generated by docbook2man
     2.\" from a DocBook document.  This tool can be found at:
     3.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
     4.\" Please send any bug reports, improvements, comments, patches,
     5.\" etc. to Steve Cheng <steve@ggi-project.org>.
     6.TH "RDISC" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
     7.SH NAME
     8rdisc \- network router discovery daemon
     9.SH SYNOPSIS
     10
     11\fBrdisc\fR [\fB-abdfstvV\fR] [\fB\fIsend_address\fB\fR] [\fB\fIreceive_address\fB\fR]
     12
     13.SH "DESCRIPTION"
     14.PP
     15\fBrdisc\fR implements client side of the ICMP router discover protocol.
     16\fBrdisc\fR is invoked at boot time to populate the network
     17routing tables with default routes.
     18.PP
     19\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address
     20(or \fIreceive_address\fR provided it is given)
     21for ROUTER_ADVERTISE messages from routers. The received
     22messages are handled by first ignoring those listed router addresses
     23with which the host does not share a network. Among the remaining addresses
     24the ones with the highest preference are selected as default routers
     25and a default route is entered in the kernel routing table
     26for each one of them.
     27.PP
     28Optionally, \fBrdisc\fR can avoid waiting for routers to announce
     29themselves by sending out a few ROUTER_SOLICITATION messages
     30to the ALL_ROUTERS (224.0.0.2) multicast address
     31(or \fIsend_address\fR provided it is given)
     32when it is started.
     33.PP
     34A timer is associated with each router address and the address will
     35no longer be considered for inclusion in the the routing tables if the
     36timer expires before a new
     37\fBadvertise\fR message is received from the router.
     38The address will also be excluded from consideration if the host receives an
     39\fBadvertise\fR
     40message with the preference being maximally negative.
     41.PP
     42Server side of router discovery protocol is supported by Cisco IOS
     43and by any more or less complete UNIX routing daemon, f.e \fBgated\fR.
     44.SH "OPTIONS"
     45.TP
     46\fB-a\fR
     47Accept all routers independently of the preference they have in their
     48\fBadvertise\fR messages.
     49Normally \fBrdisc\fR only accepts (and enters in the kernel routing
     50tables) the router or routers with the highest preference.
     51.TP
     52\fB-b\fR
     53Opposite to \fB-a\fR, i.e. install only router with the best
     54preference value. It is default behaviour.
     55.TP
     56\fB-d\fR
     57Send debugging messages to syslog.
     58.TP
     59\fB-f\fR
     60Run \fBrdisc\fR forever even if no routers are found.
     61Normally \fBrdisc\fR gives up if it has not received any
     62\fBadvertise\fR message after after soliciting three times,
     63in which case it exits with a non-zero exit code.
     64If \fB-f\fR is not specified in the first form then
     65\fB-s\fR must be specified.
     66.TP
     67\fB-s\fR
     68Send three \fBsolicitation\fR messages initially to quickly discover
     69the routers when the system is booted.
     70When \fB-s\fR is specified \fBrdisc\fR
     71exits with a non-zero exit code if it can not find any routers.
     72This can be overridden with the \fB-f\fR option.
     73.TP
     74\fB-t\fR
     75Test mode. Do not go to background.
     76.TP
     77\fB-v\fR
     78Be verbose i.e. send lots of debugging messages to syslog.
     79.TP
     80\fB-V\fR
     81Print version and exit.
     82.SH "HISTORY"
     83.PP
     84This program was developed by Sun Microsystems (see copyright
     85notice in source file). It was ported to Linux by
     86Alexey Kuznetsov
     87<kuznet@ms2.inr.ac.ru>.
     88It is now maintained by
     89YOSHIFUJI Hideaki
     90<yoshfuji@skbuff.net>.
     91.SH "SEE ALSO"
     92.PP
     93\fBicmp\fR(7),
     94\fBinet\fR(7),
     95\fBping\fR(8).
     96.SH "REFERENCES"
     97.PP
     98Deering, S.E.,ed "ICMP Router Discovery Messages",
     99RFC1256, Network Information Center, SRI International,
     100Menlo Park, Calif., September 1991.
     101.SH "SECURITY"
     102.PP
     103\fBrdisc\fR requires CAP_NET_RAWIO to listen
     104and send ICMP messages and capability CAP_NET_ADMIN
     105to update routing tables.
     106.SH "AVAILABILITY"
     107.PP
     108\fBrdisc\fR is part of \fIiputils\fR package
     109and the latest versions are  available in source form at
     110http://www.skbuff.net/iputils/iputils-current.tar.bz2.
  • TabularUnified doc/tracepath.8

    diff -Naur doc/tracepath.8 doc/tracepath.8
     
     1.\" This manpage has been automatically generated by docbook2man
     2.\" from a DocBook document.  This tool can be found at:
     3.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
     4.\" Please send any bug reports, improvements, comments, patches,
     5.\" etc. to Steve Cheng <steve@ggi-project.org>.
     6.TH "TRACEPATH" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
     7.SH NAME
     8tracepath, tracepath6 \- traces path to a network host discovering MTU along this path
     9.SH SYNOPSIS
     10
     11\fBtracepath\fR [\fB-n\fR] [\fB-l \fIpktlen\fB\fR] \fB\fIdestination\fB\fR [\fB\fIport\fB\fR]
     12
     13.SH "DESCRIPTION"
     14.PP
     15It traces path to \fIdestination\fR discovering MTU along this path.
     16It uses UDP port \fIport\fR or some random port.
     17It is similar to \fBtraceroute\fR, only does not not require superuser
     18privileges and has no fancy options.
     19.PP
     20\fBtracepath6\fR is good replacement for \fBtraceroute6\fR
     21and classic example of application of Linux error queues.
     22The situation with \fBtracepath\fR is worse, because commercial
     23IP routers do not return enough information in icmp error messages.
     24Probably, it will change, when they will be updated.
     25For now it uses Van Jacobson's trick, sweeping a range
     26of UDP ports to maintain trace history.
     27.SH "OPTIONS"
     28.TP
     29\fB-n\fR
     30Do not look up host names.  Only print IP addresses numerically.
     31.TP
     32\fB-l\fR
     33Sets the initial packet length to \fIpktlen\fR instead of
     3465536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR.
     35.SH "OUTPUT"
     36.PP
     37
     38.nf
     39root@mops:~ # tracepath6 3ffe:2400:0:109::2
     40 1?: [LOCALHOST]                              pmtu 1500
     41 1:  dust.inr.ac.ru                   0.411ms
     42 2:  dust.inr.ac.ru        asymm  1   0.390ms pmtu 1480
     43 2:  3ffe:2400:0:109::2               463.514ms reached
     44     Resume: pmtu 1480 hops 2 back 2
     45.fi
     46.PP
     47The first column shows TTL of the probe, followed by colon.
     48Usually value of TTL is obtained from reply from network,
     49but sometimes reply does not contain necessary information and
     50we have to guess it. In this case the number is followed by ?.
     51.PP
     52The second column shows the network hop, which replied to the probe.
     53It is either address of router or word [LOCALHOST], if
     54the probe was not sent to the network.
     55.PP
     56The rest of line shows miscellaneous information about path to
     57the correspinding hetwork hop. As rule it contains value of RTT.
     58Additionally, it can show Path MTU, when it changes.
     59If the path is asymmetric
     60or the probe finishes before it reach prescribed hop, difference
     61between number of hops in forward and backward direction is shown
     62folloing keyword async. This information is not reliable.
     63F.e. the third line shows asymmetry of 1, it is because the first probe
     64with TTL of 2 was rejected at the first hop due to Path MTU Discovery.
     65.PP
     66The last line summarizes information about all the path to the destination,
     67it shows detected Path MTU, amount of hops to the destination and our
     68guess about amount of hops from the destination to us, which can be
     69different when the path is asymmetric.
     70.SH "SEE ALSO"
     71.PP
     72\fBtraceroute\fR(8),
     73\fBtraceroute6\fR(8),
     74\fBping\fR(8).
     75.SH "AUTHOR"
     76.PP
     77\fBtracepath\fR was written by
     78Alexey Kuznetsov
     79<kuznet@ms2.inr.ac.ru>.
     80.SH "SECURITY"
     81.PP
     82No security issues.
     83.PP
     84This lapidary deserves to be elaborated.
     85\fBtracepath\fR is not a privileged program, unlike
     86\fBtraceroute\fR, \fBping\fR and other beasts of this kind.
     87\fBtracepath\fR may be executed by everyone who has some access
     88to network, enough to send UDP datagrams to investigated destination
     89using given port.
     90.SH "AVAILABILITY"
     91.PP
     92\fBtracepath\fR is part of \fIiputils\fR package
     93and the latest versions are  available in source form at
     94http://www.skbuff.net/iputils/iputils-current.tar.bz2.
  • TabularUnified doc/traceroute6.8

    diff -Naur doc/traceroute6.8 doc/traceroute6.8
     
     1.\" This manpage has been automatically generated by docbook2man
     2.\" from a DocBook document.  This tool can be found at:
     3.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
     4.\" Please send any bug reports, improvements, comments, patches,
     5.\" etc. to Steve Cheng <steve@ggi-project.org>.
     6.TH "TRACEROUTE6" "8" "18 February 2009" "iputils-071127" "System Manager's Manual: iputils"
     7.SH NAME
     8traceroute6 \- traces path to a network host
     9.SH SYNOPSIS
     10
     11\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]
     12
     13.SH "DESCRIPTION"
     14.PP
     15Description can be found in
     16\fBtraceroute\fR(8),
     17all the references to IP replaced to IPv6. It is needless to copy
     18the description from there.
     19.SH "SEE ALSO"
     20.PP
     21\fBtraceroute\fR(8),
     22\fBtracepath\fR(8),
     23\fBping\fR(8).
     24.SH "HISTORY"
     25.PP
     26This program has long history. Author of \fBtraceroute\fR
     27is Van Jacobson and it first appeared in 1988. This clone is
     28based on a port of \fBtraceroute\fR to IPv6 published
     29in NRL IPv6 distribution in 1996. In turn, it was ported
     30to Linux by Pedro Roque. After this it was kept in sync by   
     31Alexey Kuznetsov
     32<kuznet@ms2.inr.ac.ru>. And eventually entered
     33\fBiputils\fR package.
     34.SH "SECURITY"
     35.PP
     36\fBtracepath6\fR requires CAP_NET_RAWIO capability
     37to be executed. It is safe to be used as set-uid root.
     38.SH "AVAILABILITY"
     39.PP
     40\fBtraceroute6\fR is part of \fIiputils\fR package
     41and the latest versions are  available in source form at
     42http://www.skbuff.net/iputils/iputils-current.tar.bz2.
Note: See TracBrowser for help on using the repository browser.