Submitted By: William Harrington Date: 2015-08-30 Initial Package Version: s20150815 Upstream Status: Applied Origin: git://git.linux-ipv6.org/gitroot/iputils.git Description: Edits Makefile USE_ Variables and includes man pages. diff -Naur iputils-s20150815.orig/Makefile iputils-s20150815/Makefile --- iputils-s20150815.orig/Makefile 2015-08-15 14:07:28.000000000 +0000 +++ iputils-s20150815/Makefile 2015-08-24 00:28:16.063196187 +0000 @@ -27,7 +27,7 @@ # sysfs support (with libsysfs - deprecated) [no|yes|static] USE_SYSFS=no # IDN support [yes|no|static] -USE_IDN=yes +USE_IDN=no # Do not use getifaddrs [no|yes|static] WITHOUT_IFADDRS=no @@ -35,7 +35,7 @@ ARPING_DEFAULT_DEVICE= # nettle library for ipv6 ping [yes|no|static] -USE_NETTLE=yes +USE_NETTLE=no # libgcrypt library for ipv6 ping [no|yes|static] USE_GCRYPT=no # Crypto library for ping6 [shared|static|no] diff -Naur iputils-s20150815.orig/doc/arping.8 iputils-s20150815/doc/arping.8 --- iputils-s20150815.orig/doc/arping.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/arping.8 2015-08-24 00:27:12.254377152 +0000 @@ -0,0 +1,109 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "ARPING" "8" "24 August 2015" "iputils-140519" "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, instead wait for +\fIcount\fR ARP REPLY packets, or 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. +.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 +. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SECURITY" +.PP +\fBarping\fR requires CAP_NET_RAW 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. diff -Naur iputils-s20150815.orig/doc/clockdiff.8 iputils-s20150815/doc/clockdiff.8 --- iputils-s20150815.orig/doc/clockdiff.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/clockdiff.8 2015-08-24 00:27:12.387701056 +0000 @@ -0,0 +1,81 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "CLOCKDIFF" "8" "24 August 2015" "iputils-140519" "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 +. It was based on code borrowed +from BSD \fBtimed\fR daemon. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SECURITY" +.PP +\fBclockdiff\fR requires CAP_NET_RAW 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. diff -Naur iputils-s20150815.orig/doc/ninfod.8 iputils-s20150815/doc/ninfod.8 --- iputils-s20150815.orig/doc/ninfod.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/ninfod.8 2015-08-24 00:27:12.524358055 +0000 @@ -0,0 +1,72 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "NINFOD" "8" "24 August 2015" "iputils-140519" "System Manager's Manual: iputils" +.SH NAME +ninfod \- Respond to IPv6 Node Information Queries +.SH SYNOPSIS + +\fBninfod\fR [\fB-dhv\fR] [\fB-p \fIpidfile\fB\fR] [\fB-u \fIuser\fB\fR] + +.SH "DESCRIPTION" +.PP +Responds to IPv6 Node Information Queries (RFC4620) from clients. +Queries can be sent by various implementations of \fBping6\fR command. +.SH "OPTIONS" +.TP +\fB-a\fR +Debug mode. Do not go background. +.TP +\fB-h\fR +Show help. +.TP +\fB-v\fR +Verbose mode. +.TP +\fB-u \fIuser\fB\fR +Run as another user. +\fIuser\fR can either be username or user ID. +.TP +\fB-p \fIpidfile\fB\fR +File for process-id storage. +\fIuser\fR is required to be able to create the file. +.SH "SEE ALSO" +.PP +\fBping\fR(8). +.SH "AUTHOR" +.PP +\fBninfod\fR was written by USAGI/WIDE Project. +.SH "COPYING" +.PP + +.nf +Copyright (C) 2012 YOSHIFUJI Hideaki. +Copyright (C) 2002 USAGI/WIDE Project. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. +3. Neither the name of the project nor the names of its contributors + may be used to endorse or promote products derived from this software + without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +SUCH DAMAGE. +.fi diff -Naur iputils-s20150815.orig/doc/pg3.8 iputils-s20150815/doc/pg3.8 --- iputils-s20150815.orig/doc/pg3.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/pg3.8 2015-08-24 00:27:12.657681956 +0000 @@ -0,0 +1,86 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "PG3" "8" "24 August 2015" "iputils-140519" "System Manager's Manual: iputils" +.SH NAME +pg3, ipg, pgset \- send stream of UDP packets +.SH SYNOPSIS + +\fBsource ipg\fR + + +\fBpg\fR + + +\fBpgset\fR \fB\fICOMMAND\fB\fR + +.SH "DESCRIPTION" +.PP +\fBipg\fR is not a program, it is script which should be sourced +to \fBbash\fR. When sourced it loads module \fIpg3\fR and +exports a few of functions accessible from parent shell. These macros +are \fBpg\fR to start packet injection and to get the results of run; +and \fBpgset\fR to setup packet generator. +.PP +\fBpgset\fR can send the following commands to module \fIpg3\fR: +.SH "COMMAND" +.TP +\fBodev \fIDEVICE\fB\fR +Name of Ethernet device to test. See +warning below. +.TP +\fBpkt_size \fIBYTES\fB\fR +Size of packet to generate. The size includes all the headers: UDP, IP, +MAC, but does not account for overhead internal to medium, i.e. FCS +and various paddings. +.TP +\fBfrags \fINUMBER\fB\fR +Each packet will contain \fINUMBER\fR of fragments. +Maximal amount for linux-2.4 is 6. Far not all the devices support +fragmented buffers. +.TP +\fBcount \fINUMBER\fB\fR +Send stream of \fINUMBER\fR of packets and stop after this. +.TP +\fBipg \fITIME\fB\fR +Introduce artificial delay between packets of \fITIME\fR +microseconds. +.TP +\fBdst \fIIP_ADDRESS\fB\fR +Select IP destination where the stream is sent to. +Beware, never set this address at random. \fBpg3\fR is not a toy, +it creates really tough stream. Default value is 0.0.0.0. +.TP +\fBdst \fIMAC_ADDRESS\fB\fR +Select MAC destination where the stream is sent to. +Default value is 00:00:00:00:00:00 in hope that this will not be received +by any node on LAN. +.TP +\fBstop\fR +Abort packet injection. +.SH "WARNING" +.PP +When output device is set to some random device different +of hardware Ethernet device, \fBpg3\fR will crash kernel. +.PP +Do not use it on VLAN, ethertap, VTUN and other devices, +which emulate Ethernet not being real Ethernet in fact. +.SH "AUTHOR" +.PP +\fBpg3\fR was written by Robert Olsson . +.SH "SECURITY" +.PP +This can be used only by superuser. +.PP +This tool creates floods of packets which is unlikely to be handled +even by high-end machines. For example, it saturates gigabit link with +60 byte packets when used with Intel's e1000. In face of such stream +switches, routers and end hosts may deadlock, crash, explode. +Use only in test lab environment. +.SH "AVAILABILITY" +.PP +\fBpg3\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 iputils-s20150815.orig/doc/ping.8 iputils-s20150815/doc/ping.8 --- iputils-s20150815.orig/doc/ping.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/ping.8 2015-08-24 00:27:12.861000903 +0000 @@ -0,0 +1,433 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "PING" "8" "24 August 2015" "iputils-140519" "System Manager's Manual: iputils" +.SH NAME +ping, ping6 \- send ICMP ECHO_REQUEST to network hosts +.SH SYNOPSIS + +\fBping\fR [\fB-aAbBdDfhLnOqrRUvV6\fR] [\fB-c \fIcount\fB\fR] [\fB-F \fIflowlabel\fB\fR] [\fB-i \fIinterval\fB\fR] [\fB-I \fIinterface\fB\fR] [\fB-l \fIpreload\fB\fR] [\fB-m \fImark\fB\fR] [\fB-M \fIpmtudisc_option\fB\fR] [\fB-N \fInodeinfo_option\fB\fR] [\fB-w \fIdeadline\fB\fR] [\fB-W \fItimeout\fB\fR] [\fB-p \fIpattern\fB\fR] [\fB-Q \fItos\fB\fR] [\fB-s \fIpacketsize\fB\fR] [\fB-S \fIsndbuf\fB\fR] [\fB-t \fIttl\fB\fR] [\fB-T \fItimestamp option\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 is IPv6 version of \fBping\fR, and can also send Node Information Queries (RFC4620). +Intermediate \fIhop\fRs may not be allowed, because IPv6 source routing was deprecated (RFC5095). +.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 probe +is 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-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-D\fR +Print timestamp (unix time + microseconds as in gettimeofday) before +each line. +.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-F \fIflow label\fB\fR +\fBping6\fR only. +Allocate and set 20 bit flow label (in hex) on echo request packets. +If value is zero, kernel allocates random flow label. +.TP +\fB-h\fR +Show help. +.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\fB\fR +\fIinterface\fR is either an address, or an interface name. +If \fIinterface\fR is an address, it sets source address +to specified interface address. +If \fIinterface\fR in an interface name, it sets +source interface to specified interface. +For \fBping6\fR, when doing ping to a link-local scope +address, link specification (by the '%'-notation in +\fIdestination\fR, or by 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-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-M \fIpmtudisc_opt\fB\fR +Select Path MTU Discovery strategy. +\fIpmtudisc_option\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-N \fInodeinfo_option\fB\fR +\fBping6\fR only. +Send ICMPv6 Node Information Queries (RFC4620), instead of Echo Request. +CAP_NET_RAW capability is required. +.RS +.TP +\fBhelp\fR +Show help for NI support. +.RE +.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-O\fR +Report outstanding ICMP ECHO reply before sending next packet. +This is useful together with the timestamp \fB-D\fR to +log output to a diagnostic file and search for missing answers. +.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-q\fR +Quiet output. +Nothing is displayed except the summary lines at startup time and +when finished. +.TP +\fB-Q \fItos\fB\fR +Set Quality of Service -related bits in ICMP datagrams. +\fItos\fR can be decimal (\fBping\fR only) or hex number. + +In RFC2474, these fields are interpreted as 8-bit Differentiated +Services (DS), consisting of: bits 0-1 (2 lowest bits) of separate +data, and bits 2-7 (highest 6 bits) of Differentiated Services +Codepoint (DSCP). In RFC2481 and RFC3168, bits 0-1 are used for ECN. + +Historically (RFC1349, obsoleted by RFC2474), these were interpreted +as: bit 0 (lowest bit) for reserved (currently being redefined as +congestion control), 1-4 for Type of Service and bits 5-7 +(highest bits) for Precedence. +.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-R\fR +\fBping\fR only. +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-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 +\fBping\fR only. +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-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 absence 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 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_RAW capability +to be executed 1) if the program is used for non-echo queries +(See \fB-N\fR option), or 2) if kernel does not +support non-raw ICMP sockets, or 3) if the user is not allowed +to create an ICMP echo socket. The program 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. diff -Naur iputils-s20150815.orig/doc/rarpd.8 iputils-s20150815/doc/rarpd.8 --- iputils-s20150815.orig/doc/rarpd.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/rarpd.8 2015-08-24 00:27:12.994324803 +0000 @@ -0,0 +1,84 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "RARPD" "8" "24 August 2015" "iputils-140519" "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 +. +It is now maintained by +YOSHIFUJI Hideaki +. +.SH "SECURITY" +.PP +\fBrarpd\fR requires CAP_NET_RAW 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 iputils-s20150815.orig/doc/rdisc.8 iputils-s20150815/doc/rdisc.8 --- iputils-s20150815.orig/doc/rdisc.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/rdisc.8 2015-08-24 00:27:13.124315607 +0000 @@ -0,0 +1,122 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "RDISC" "8" "24 August 2015" "iputils-140519" "System Manager's Manual: iputils" +.SH NAME +rdisc \- network router discovery daemon +.SH SYNOPSIS + +\fBrdisc\fR [\fB-abdfrstvV\fR] [\fB-p \fIpreference\fB\fR] [\fB-T \fImax_interval\fB\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. +Or, \fBrdisc\fR can act as responder, if compiled with -DRDISC_SERVER. +.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-r\fR +Responder mode, available only if compiled with -DRDISC_SERVER. +.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-p \fIpreference\fB\fR +Set preference in advertisement. +Available only with -r option. +.TP +\fB-T \fImax_interval\fB\fR +Set maximum advertisement interval in seconds. Default is 600 secs. +Available only with -r 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 +. +It is now maintained by +YOSHIFUJI Hideaki +. +.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_RAW 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. diff -Naur iputils-s20150815.orig/doc/tftpd.8 iputils-s20150815/doc/tftpd.8 --- iputils-s20150815.orig/doc/tftpd.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/tftpd.8 2015-08-24 00:27:13.260972607 +0000 @@ -0,0 +1,85 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "TFTPD" "8" "24 August 2015" "iputils-140519" "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 iputils-s20150815.orig/doc/tracepath.8 iputils-s20150815/doc/tracepath.8 --- iputils-s20150815.orig/doc/tracepath.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/tracepath.8 2015-08-24 00:27:13.394296509 +0000 @@ -0,0 +1,104 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "TRACEPATH" "8" "24 August 2015" "iputils-140519" "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-m \fImax_hops\fB\fR] [\fB-p \fIport\fB\fR] \fB\fIdestination\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 +65535 for \fBtracepath\fR or 128000 for \fBtracepath6\fR. +.TP +\fB-m\fR +Set maximum hops (or maximum TTLs) to \fImax_hops\fR +instead of 30. +.TP +\fB-p\fR +Sets the initial destination port to use. +.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 network 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 +. +.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 iputils-s20150815.orig/doc/traceroute6.8 iputils-s20150815/doc/traceroute6.8 --- iputils-s20150815.orig/doc/traceroute6.8 1970-01-01 00:00:00.000000000 +0000 +++ iputils-s20150815/doc/traceroute6.8 2015-08-24 00:27:13.527620409 +0000 @@ -0,0 +1,42 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "TRACEROUTE6" "8" "24 August 2015" "iputils-140519" "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 +. And eventually entered +\fBiputils\fR package. +.SH "SECURITY" +.PP +\fBtracepath6\fR requires CAP_NET_RAW 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.