From 66076835decfa878f5bd6a926d7ebb885f81fffd Mon Sep 17 00:00:00 2001 From: Juan RP Date: Tue, 1 Feb 2011 02:05:09 +0100 Subject: [PATCH] iputils: update to 20101006. --- srcpkgs/iputils/patches/fix_install.diff | 9 +- srcpkgs/iputils/patches/fix_rdisc.c.diff | 16 - .../patches/iputils-s20101006-manpages.patch | 1044 +++++++++++++++++ srcpkgs/iputils/template | 25 +- 4 files changed, 1068 insertions(+), 26 deletions(-) delete mode 100644 srcpkgs/iputils/patches/fix_rdisc.c.diff create mode 100644 srcpkgs/iputils/patches/iputils-s20101006-manpages.patch diff --git a/srcpkgs/iputils/patches/fix_install.diff b/srcpkgs/iputils/patches/fix_install.diff index 2218360d53..2becc24407 100644 --- a/srcpkgs/iputils/patches/fix_install.diff +++ b/srcpkgs/iputils/patches/fix_install.diff @@ -1,6 +1,6 @@ ---- Makefile.orig 2009-03-06 09:03:41.189028082 +0100 -+++ Makefile 2009-03-06 09:08:37.087015943 +0100 -@@ -25,6 +25,14 @@ TAG:=`date +s%Y%m%d` +--- a/Makefile.orig 2010-10-06 13:59:20.000000000 +0200 ++++ b/Makefile 2011-02-01 01:58:43.338899085 +0100 +@@ -25,6 +25,15 @@ TAG:=`date +s%Y%m%d` all: $(TARGETS) @@ -11,7 +11,8 @@ + else \ + install -D -m755 $$f $(DESTDIR)/sbin/$$f; \ + fi; \ ++ \ + done tftpd: tftpd.o tftpsubs.o - ping: ping.o ping_common.o + arping: arping.o -lsysfs diff --git a/srcpkgs/iputils/patches/fix_rdisc.c.diff b/srcpkgs/iputils/patches/fix_rdisc.c.diff deleted file mode 100644 index e60807772e..0000000000 --- a/srcpkgs/iputils/patches/fix_rdisc.c.diff +++ /dev/null @@ -1,16 +0,0 @@ -the OPEN_MAX define has been removed in newer kernel headers so use the -proper method of getting the value dynamically - -http://bugs.gentoo.org/195861 - ---- rdisc.c -+++ rdisc.c -@@ -247,7 +247,7 @@ void do_fork(void) - if ((pid=fork()) != 0) - exit(0); - -- for (t = 0; t < OPEN_MAX; t++) -+ for (t = 0; t < sysconf(_SC_OPEN_MAX); t++) - if (t != s) - close(t); - diff --git a/srcpkgs/iputils/patches/iputils-s20101006-manpages.patch b/srcpkgs/iputils/patches/iputils-s20101006-manpages.patch new file mode 100644 index 0000000000..764d0d36dd --- /dev/null +++ b/srcpkgs/iputils/patches/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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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 ++. ++It is now maintained by ++YOSHIFUJI Hideaki ++. ++.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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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 ++. 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_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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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 ++. ++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_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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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 ++. ++.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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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 ++. ++It is now maintained by ++YOSHIFUJI Hideaki ++. ++.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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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: ++.\" ++.\" Please send any bug reports, improvements, comments, patches, ++.\" etc. to Steve Cheng . ++.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 ++. 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/srcpkgs/iputils/template b/srcpkgs/iputils/template index a851fc73ef..a0d204f582 100644 --- a/srcpkgs/iputils/template +++ b/srcpkgs/iputils/template @@ -1,15 +1,28 @@ # Template file for 'iputils' pkgname=iputils -version=20071127 -distver=s${version} -wrksrc="$pkgname-$distver" -distfiles="http://www.linuxgrill.com/anonymous/iproute2/$pkgname-$distver.tar.bz2" +version=20101006 +patch_args="-Np1" +wrksrc="${pkgname}-s${version}" +distfiles="http://www.skbuff.net/${pkgname}/${pkgname}-s${version}.tar.bz2" build_style=gnu_makefile -short_desc="IP Configuration Utilities (and Ping)" +short_desc="IP Configuration Utilities (and ping)" maintainer="Juan RP " -checksum=dbbd87554d66e438245487ac31aa4a542a1c6c1ec8273cfacbbfeda09eb44a93 +checksum=fd3af46c80ebb99607c2ca1f2a3608b6fe828e25bbec6e54f2afd25f6ddb6ee7 long_desc=" The iputils package is set of small useful utilities for Linux networking. It was originally maintained by Alexey Kuznetsov." Add_dependency run glibc +Add_dependency run libssl +Add_dependency run libsysfs +Add_dependency build libsysfs-devel +Add_dependency build openssl-devel + +post_install() +{ + install -d ${DESTDIR}/usr/share/man/man8 + install -m644 ${wrksrc}/doc/*.8 ${DESTDIR}/usr/share/man/man8 + cd ${DESTDIR}/usr/share/man/man8 + ln -sf ping.8 ping6.8 + ln -sf tracepath.8 tracepath6.8 +}