diff options
Diffstat (limited to 'core/iputils')
| -rw-r--r-- | core/iputils/iputils-20101006-ping-integer-overflow.patch | 11 | ||||
| -rw-r--r-- | core/iputils/iputils-20121011-flood.patch | 22 | ||||
| -rw-r--r-- | core/iputils/iputils-20121114-free-unintialized.patch | 36 | ||||
| -rw-r--r-- | core/iputils/iputils-s20101006-manpages.patch | 1044 | ||||
| -rw-r--r-- | core/iputils/permission-fix.patch | 15 |
5 files changed, 0 insertions, 1128 deletions
diff --git a/core/iputils/iputils-20101006-ping-integer-overflow.patch b/core/iputils/iputils-20101006-ping-integer-overflow.patch deleted file mode 100644 index 720e5e888..000000000 --- a/core/iputils/iputils-20101006-ping-integer-overflow.patch +++ /dev/null @@ -1,11 +0,0 @@ ---- iputils-s20101006/ping_common.c 2010-10-06 13:59:20.000000000 +0200 -+++ iputils-s20101006-patched/ping_common.c 2012-03-09 16:42:46.878151032 +0100 -@@ -590,7 +590,7 @@ - - /* If we are here, recvmsg() is unable to wait for - * required timeout. */ -- if (1000*next <= 1000000/(int)HZ) { -+ if (((uint64_t)1000*next) <= (uint64_t)1000000/(int)HZ) { - /* Very short timeout... So, if we wait for - * something, we sleep for MININTERVAL. - * Otherwise, spin! */ diff --git a/core/iputils/iputils-20121011-flood.patch b/core/iputils/iputils-20121011-flood.patch deleted file mode 100644 index 5ced2d115..000000000 --- a/core/iputils/iputils-20121011-flood.patch +++ /dev/null @@ -1,22 +0,0 @@ ---- iputils-s20121011/ping_common.h 2012-11-05 10:07:40.065281888 +0100 -+++ iputils-s20121011-new/ping_common.h 2012-11-05 10:07:22.001268362 +0100 -@@ -141,7 +141,7 @@ static inline void write_stdout(const ch - do { - cc = write(STDOUT_FILENO, str + o, len - o); - o += cc; -- } while (len >= o || cc < 0); -+ } while (len > o || cc < 0); - } - - /* ---- iputils-s20121011/ping_common.c 2012-11-05 10:07:40.066281889 +0100 -+++ iputils-s20121011-new/ping_common.c 2012-11-05 10:07:22.007268368 +0100 -@@ -776,7 +776,7 @@ restamp: - if (!csfailed) - write_stdout("\b \b", 3); - else -- write_stdout("\bC", 1); -+ write_stdout("\bC", 2); - } else { - int i; - __u8 *cp, *dp; diff --git a/core/iputils/iputils-20121114-free-unintialized.patch b/core/iputils/iputils-20121114-free-unintialized.patch deleted file mode 100644 index 524b640ea..000000000 --- a/core/iputils/iputils-20121114-free-unintialized.patch +++ /dev/null @@ -1,36 +0,0 @@ -From: Jan Synacek <jsynacek@redhat.com> -Date: Wed, 14 Nov 2012 12:57:16 +0000 (+0100) -Subject: ping: Don't free an unintialized value. -X-Git-Url: http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot%2Fiputils.git;a=commitdiff_plain;h=44c6c9a8d3f3fc65fc52e5957bfd4cc4634f0006 - -ping: Don't free an unintialized value. - -Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> ---- - -diff --git a/ping.c b/ping.c -index fe9ff8a..9de3d08 100644 ---- a/ping.c -+++ b/ping.c -@@ -122,7 +122,7 @@ main(int argc, char **argv) - u_char *packet; - char *target; - #ifdef USE_IDN -- char *hnamebuf; -+ char *hnamebuf = NULL; - #else - char hnamebuf[MAX_HOSTNAMELEN]; - #endif -@@ -263,8 +263,10 @@ main(int argc, char **argv) - #ifdef USE_IDN - int rc; - -- free(hnamebuf); -- hnamebuf = NULL; -+ if (hnamebuf) { -+ free(hnamebuf); -+ hnamebuf = NULL; -+ } - - rc = idna_to_ascii_lz(target, &idn, 0); - if (rc != IDNA_SUCCESS) { diff --git a/core/iputils/iputils-s20101006-manpages.patch b/core/iputils/iputils-s20101006-manpages.patch deleted file mode 100644 index 764d0d36d..000000000 --- a/core/iputils/iputils-s20101006-manpages.patch +++ /dev/null @@ -1,1044 +0,0 @@ ---- /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/core/iputils/permission-fix.patch b/core/iputils/permission-fix.patch deleted file mode 100644 index c47636f84..000000000 --- a/core/iputils/permission-fix.patch +++ /dev/null @@ -1,15 +0,0 @@ ---- 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) | \ |