Fri Nov 4 23:14:51 UTC 2011

3 files changed, 1124 insertions, 0 deletions

diff --git a/testing/iputils/PKGBUILD b/testing/iputils/PKGBUILD
new file mode 100644
index 000000000..265d84d29
--- /dev/null
+++ b/testing/iputils/PKGBUILD
@@ -0,0 +1,65 @@
+# $Id: PKGBUILD 141976 2011-11-03 20:08:42Z tpowa $
+# Maintainer: Tobias Powalowski <tpowa@archlinux.org>
+# Contributor: Aaron Griffin <aaron@archlinux.org>
+
+pkgname=iputils
+pkgver=20101006
+_traceroutever=1.4a12
+pkgrel=2
+pkgdesc="IP Configuration Utilities (and Ping)"
+arch=('i686' 'x86_64')
+license=('GPL')
+url="http://www.linuxfoundation.org/en/Net:Iputils"
+groups=('base')
+depends=('glibc' 'openssl' 'sysfsutils')
+conflicts=('netkit-base' 'arping' 'netkit-tftpd' 'traceroute')
+replaces=('netkit-base' 'traceroute')
+source=(http://www.skbuff.net/${pkgname}/${pkgname}-s${pkgver}.tar.bz2
+        ftp://ftp.ee.lbl.gov/traceroute-${_traceroutever}.tar.gz
+        'permission-fix.patch'
+        'iputils-s20101006-manpages.patch')
+options=('!makeflags')
+md5sums=('a36c25e9ec17e48be514dc0485e7376c'
+         '964d599ef696efccdeebe7721cd4828d'
+         '66109966cad06e425bb12a78bab85b70'
+         'd02dffac6f16e841921a9fc73bd2d3bd')
+
+build() {
+  #build iptuils
+  cd "${srcdir}/${pkgname}-s${pkgver}"
+  
+  # Doc fails to build (see FS#20251)
+  # As a temporary workaround, we use these man pages from Fedora & LFS
+  patch -Np1 -i ../iputils-s20101006-manpages.patch
+  make
+
+  # build traceroute
+  # this is combined in this package because it's awkward as a separate package
+  cd "${srcdir}/traceroute-${_traceroutever}"
+  patch -Np1 -i ../permission-fix.patch
+  ./configure --prefix=/usr \
+              --sbindir=/bin \
+              --mandir=/usr/share/man
+  make CFLAGS="${CFLAGS} -Ilinux-include/"
+}
+
+package() {
+  cd "${srcdir}/${pkgname}-s${pkgver}"
+  for i in arping clockdiff rarpd rdisc tftpd tracepath tracepath6; do
+    install -D -m755 $i "${pkgdir}/usr/sbin/$i"
+  done
+  for i in ping ping6 traceroute6; do
+    install -D -m4755 $i "${pkgdir}/bin/$i"
+  done
+ 
+  install -dm755 "${pkgdir}/usr/share/man/man8"
+  install -m644 doc/{arping,clockdiff,ping,rarpd,rdisc,tftpd,tracepath,traceroute6}.8 \
+    "${pkgdir}/usr/share/man/man8/"
+
+  cd "${pkgdir}/usr/share/man/man8"
+  ln -sf ping.8.gz  ping6.8.gz
+  ln -sf tracepath.8.gz tracepath6.8.gz
+
+  cd "${srcdir}/traceroute-${_traceroutever}"
+  make DESTDIR="${pkgdir}" install install-man
+}
diff --git a/testing/iputils/iputils-s20101006-manpages.patch b/testing/iputils/iputils-s20101006-manpages.patch
new file mode 100644
index 000000000..764d0d36d
--- /dev/null
+++ b/testing/iputils/iputils-s20101006-manpages.patch
@@ -0,0 +1,1044 @@
+--- /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.
diff --git a/testing/iputils/permission-fix.patch b/testing/iputils/permission-fix.patch
new file mode 100644
index 000000000..c47636f84
--- /dev/null
+++ b/testing/iputils/permission-fix.patch
@@ -0,0 +1,15 @@
+--- traceroute-1.4a12/Makefile.in.old	2000-11-23 21:05:29.000000000 +0100
++++ traceroute-1.4a12/Makefile.in	2008-09-27 20:04:30.000000000 +0200
+@@ -90,10 +90,10 @@
+ 	sed -e 's/.*/char version[] = "&";/' $(srcdir)/VERSION > $@
+ 
+ install: force
+-	$(INSTALL) -m 4555 -o root -g bin traceroute $(DESTDIR)$(BINDEST)
++	$(INSTALL) -m 4555 -o root -g root traceroute $(DESTDIR)$(BINDEST)
+ 
+ install-man: force
+-	$(INSTALL) -m 444 -o bin -g bin traceroute.8 $(DESTDIR)$(MANDEST)/man8
++	$(INSTALL) -m 644 -o root -g root traceroute.8 $(DESTDIR)$(MANDEST)/man8
+ 
+ lint: $(GENSRC) force
+ 	lint -hbxn $(SRC) | \