Submitted By: Joe Ciccone Date: 2011-01-08 Initial Package Version: s20100418 Upstream Status: Unknown Origin: Unknown Description: Contains Pregenerated Documentation diff -Naur iputils-s20101006.orig/doc/arping.8 iputils-s20101006/doc/arping.8 --- iputils-s20101006.orig/doc/arping.8 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/arping.8 2011-01-08 20:09:50.402928174 -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" "08 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. diff -Naur iputils-s20101006.orig/doc/clockdiff.8 iputils-s20101006/doc/clockdiff.8 --- iputils-s20101006.orig/doc/clockdiff.8 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/clockdiff.8 2011-01-08 20:09:50.611280874 -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" "08 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. diff -Naur iputils-s20101006.orig/doc/index.html iputils-s20101006/doc/index.html --- iputils-s20101006.orig/doc/index.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/index.html 2011-01-08 20:09:49.631531431 -0500 @@ -0,0 +1,170 @@ + +System Manager's Manual: iputils

I. System Manager's Manual: iputils

Table of Contents
ping -- send ICMP ECHO_REQUEST to network hosts
arping -- send ARP REQUEST to a neighbour host
clockdiff -- measure clock difference between hosts
rarpd -- answer RARP REQUESTs
tracepath -- traces path to a network host discovering MTU along this path
traceroute6 -- traces path to a network host
tftpd -- Trivial File Transfer Protocol server
rdisc -- network router discovery daemon
pg3 -- send stream of UDP packets
  Next
  ping
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/iputils.html iputils-s20101006/doc/iputils.html --- iputils-s20101006.orig/doc/iputils.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/iputils.html 2011-01-08 20:09:50.282802377 -0500 @@ -0,0 +1,491 @@ + +iputils: documentation directory

2. Historical notes

This package appeared as a desperate attempt to bring some life +to state of basic networking applets: ping, traceroute +etc. Though it was known that port of BSD ping to Linux +was basically broken, neither maintainers of well known (and superb) +Linux net-tools package nor maintainers of Linux distributions +worried about fixing well known bugs, which were reported in linux-kernel +and linux-net mail lists for ages, were identified and nevertheless +not repaired. So, one day 1001th resuming of the subject happened +to be the last straw to break camel's back, I just parsed my hard disks +and collected a set of utilities, which shared the following properties:

  • Small +

  • Useful despite of this +

  • I never seen it was made right +

  • Not quite trivial +

  • Demonstrating some important feature of Linux +

  • The last but not the least, I use it more or less regularly +

This utility set was not supposed to be a reference set or something like +that. Most of them were cloned from some originals: +

pingcloned of an ancient NetTools-B-xx
ping6cloned of a very old Pedro's utility set
traceroute6cloned of NRL Sep 96 distribution
rdisccloned of SUN in.rdisc
clockdiffbroken out of some BSD timed
tftpdit is clone of some ancient NetKit package

Also I added some utilities written from scratch, namely +tracepath, arping and later rarpd +(the last one does not satisfy all the criteria, I used it two or three +times).

Hesitated a bit I overcame temptation to add traceroute. +The variant released by LBNL to that time was mostly sane and bugs +in it were mostly not specific to Linux, but main reason was that +the latest version of LBNL traceroute was not +small, it consisted of several files, +used a wicked (and failing with Linux :-)) autoconfiguration etc. +So, instead I assembled to iputils a simplistic tracepath utility +and IPv6 version of traceroute, and published my + patches. +to LBNL traceroute separately.[1]

3. Installation notes

make to compile utilities. make html to prepare +html documentation, make man if you prefer man pages. +Nothing fancy, provided you have DocBook package installed.

make install installs only HTML documentation +to /usr/doc/iputils. It even does not try +to install binaries and man pages. If you read historical +notes above, the reason should be evident. Most of utilities +intersect with utilities distributed in another packages, and +making such target rewriting existing installation would be a crime +from my side. The decision what variant of ping is preferred, +how to resolve the conflicts etc. is left to you or to person who +assembled an rpm. I vote for variant from iputils of course.

Anyway, select utilities which you like and install them to the places +which you prefer together with their man pages.

It is possible that compilation will fail, if you use some +funny Linux distribution mangling header files in some unexpected ways +(expected ones are the ways of redhat of course :-)). +I validate iputils against asplinux +distribution, which is inevitably followed by validity with respect +to redhat. +If your distribution is one of widely known ones, suse or debian, +it also will compile provided snapshot is elder than month or so and +someone reported all the problems, if they took place at all.

Anyway, please, do not abuse me complaining about some compilation problems +in any distribution different of asplinux or redhat. +If you have a fix, please, send it to +me, +I will check that it does not break distributions mentioned above +and apply it. But I am not going to undertake any investigations, +bare reports are deemed to be routed to /dev/null.

4. Availability

The collection of documents is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

5. Copying

Different files are copyrighted by different persons and organizations +and distributed under different licenses. For details look into corresponding +source files.

Notes

[1]

This was mistake. +Due to this traceroute was in a sad state until recently. +Good news, redhat-7.2 seems to add these patches to their traceroute +rpm eventually. So, I think I will refrain of suicide for awhile.

\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/pg3.8 iputils-s20101006/doc/pg3.8 --- iputils-s20101006.orig/doc/pg3.8 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/pg3.8 2011-01-08 20:09:50.890656148 -0500 @@ -0,0 +1,86 @@ +.\" This manpage has been automatically generated by docbook2man +.\" from a DocBook document. This tool can be found at: +.\" +.\" Please send any bug reports, improvements, comments, patches, +.\" etc. to Steve Cheng . +.TH "PG3" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils" +.SH NAME +pg3, ipg, pgset \- send stream of UDP packets +.SH SYNOPSIS + +\fBsource ipg\fR + + +\fBpg\fR + + +\fBpgset\fR \fB\fICOMMAND\fB\fR + +.SH "DESCRIPTION" +.PP +\fBipg\fR is not a program, it is script which should be sourced +to \fBbash\fR. When sourced it loads module \fIpg3\fR and +exports a few of functions accessible from parent shell. These macros +are \fBpg\fR to start packet injection and to get the results of run; +and \fBpgset\fR to setup packet generator. +.PP +\fBpgset\fR can send the following commands to module \fIpg3\fR: +.SH "COMMAND" +.TP +\fBodev \fIDEVICE\fB\fR +Name of Ethernet device to test. See +warning below. +.TP +\fBpkt_size \fIBYTES\fB\fR +Size of packet to generate. The size includes all the headers: UDP, IP, +MAC, but does not account for overhead internal to medium, i.e. FCS +and various paddings. +.TP +\fBfrags \fINUMBER\fB\fR +Each packet will contain \fINUMBER\fR of fragments. +Maximal amount for linux-2.4 is 6. Far not all the devices support +fragmented buffers. +.TP +\fBcount \fINUMBER\fB\fR +Send stream of \fINUMBER\fR of packets and stop after this. +.TP +\fBipg \fITIME\fB\fR +Introduce artificial delay between packets of \fITIME\fR +microseconds. +.TP +\fBdst \fIIP_ADDRESS\fB\fR +Select IP destination where the stream is sent to. +Beware, never set this address at random. \fBpg3\fR is not a toy, +it creates really tough stream. Default value is 0.0.0.0. +.TP +\fBdst \fIMAC_ADDRESS\fB\fR +Select MAC destination where the stream is sent to. +Default value is 00:00:00:00:00:00 in hope that this will not be received +by any node on LAN. +.TP +\fBstop\fR +Abort packet injection. +.SH "WARNING" +.PP +When output device is set to some random device different +of hardware Ethernet device, \fBpg3\fR will crash kernel. +.PP +Do not use it on VLAN, ethertap, VTUN and other devices, +which emulate Ethernet not being real Ethernet in fact. +.SH "AUTHOR" +.PP +\fBpg3\fR was written by Robert Olsson . +.SH "SECURITY" +.PP +This can be used only by superuser. +.PP +This tool creates floods of packets which is unlikely to be handled +even by high-end machines. For example, it saturates gigabit link with +60 byte packets when used with Intel's e1000. In face of such stream +switches, routers and end hosts may deadlock, crash, explode. +Use only in test lab environment. +.SH "AVAILABILITY" +.PP +\fBpg3\fR is part of \fIiputils\fR package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2. diff -Naur iputils-s20101006.orig/doc/ping.8 iputils-s20101006/doc/ping.8 --- iputils-s20101006.orig/doc/ping.8 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/ping.8 2011-01-08 20:09:50.986782167 -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" "08 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. diff -Naur iputils-s20101006.orig/doc/r1022.html iputils-s20101006/doc/r1022.html --- iputils-s20101006.orig/doc/r1022.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r1022.html 2011-01-08 20:09:49.623373190 -0500 @@ -0,0 +1,511 @@ + +rdisc
System Manager's Manual: iputils
PrevNext

rdisc

Name

rdisc -- network router discovery daemon

Synopsis

rdisc [-abdfstvV] [send_address] [receive_address]

DESCRIPTION

rdisc implements client side of the ICMP router discover protocol. +rdisc is invoked at boot time to populate the network +routing tables with default routes.

rdisc listens on the ALL_HOSTS (224.0.0.1) multicast address +(or receive_address 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.

Optionally, rdisc 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 send_address provided it is given) +when it is started.

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 +advertise message is received from the router. +The address will also be excluded from consideration if the host receives an +advertise +message with the preference being maximally negative.

Server side of router discovery protocol is supported by Cisco IOS +and by any more or less complete UNIX routing daemon, f.e gated.

OPTIONS

-a

Accept all routers independently of the preference they have in their +advertise messages. +Normally rdisc only accepts (and enters in the kernel routing +tables) the router or routers with the highest preference. +

-b

Opposite to -a, i.e. install only router with the best +preference value. It is default behaviour. +

-d

Send debugging messages to syslog. +

-f

Run rdisc forever even if no routers are found. +Normally rdisc gives up if it has not received any +advertise message after after soliciting three times, +in which case it exits with a non-zero exit code. +If -f is not specified in the first form then +-s must be specified. +

-s

Send three solicitation messages initially to quickly discover +the routers when the system is booted. +When -s is specified rdisc +exits with a non-zero exit code if it can not find any routers. +This can be overridden with the -f option. +

-t

Test mode. Do not go to background. +

-v

Be verbose i.e. send lots of debugging messages to syslog. +

-V

Print version and exit. +

HISTORY

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>.

SEE ALSO

icmp(7), +inet(7), +ping(8).

REFERENCES

Deering, S.E.,ed "ICMP Router Discovery Messages", +RFC1256, Network Information Center, SRI International, +Menlo Park, Calif., September 1991.

SECURITY

rdisc requires CAP_NET_RAWIO to listen +and send ICMP messages and capability CAP_NET_ADMIN +to update routing tables.

AVAILABILITY

rdisc is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
tftpd pg3
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r1144.html iputils-s20101006/doc/r1144.html --- iputils-s20101006.orig/doc/r1144.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r1144.html 2011-01-08 20:09:49.631531431 -0500 @@ -0,0 +1,428 @@ + +pg3
System Manager's Manual: iputils
Prev 

pg3

Name

pg3, ipg, pgset -- send stream of UDP packets

Synopsis

source ipg

pg

pgset {COMMAND}

DESCRIPTION

ipg is not a program, it is script which should be sourced +to bash. When sourced it loads module pg3 and +exports a few of functions accessible from parent shell. These macros +are pg to start packet injection and to get the results of run; +and pgset to setup packet generator.

pgset can send the following commands to module pg3:

COMMAND

odev DEVICE

Name of Ethernet device to test. See +warning below. +

pkt_size BYTES

Size of packet to generate. The size includes all the headers: UDP, IP, +MAC, but does not account for overhead internal to medium, i.e. FCS +and various paddings. +

frags NUMBER

Each packet will contain NUMBER of fragments. +Maximal amount for linux-2.4 is 6. Far not all the devices support +fragmented buffers. +

count NUMBER

Send stream of NUMBER of packets and stop after this. +

ipg TIME

Introduce artificial delay between packets of TIME +microseconds. +

dst IP_ADDRESS

Select IP destination where the stream is sent to. +Beware, never set this address at random. pg3 is not a toy, +it creates really tough stream. Default value is 0.0.0.0. +

dst MAC_ADDRESS

Select MAC destination where the stream is sent to. +Default value is 00:00:00:00:00:00 in hope that this will not be received +by any node on LAN. +

stop

Abort packet injection. +

WARNING

When output device is set to some random device different +of hardware Ethernet device, pg3 will crash kernel.

Do not use it on VLAN, ethertap, VTUN and other devices, +which emulate Ethernet not being real Ethernet in fact.

AUTHOR

pg3 was written by Robert Olsson <robert.olsson@its.uu.se>.

SECURITY

This can be used only by superuser.

This tool creates floods of packets which is unlikely to be handled +even by high-end machines. For example, it saturates gigabit link with +60 byte packets when used with Intel's e1000. In face of such stream +switches, routers and end hosts may deadlock, crash, explode. +Use only in test lab environment.

AVAILABILITY

pg3 is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHome 
rdisc  
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r3.html iputils-s20101006/doc/r3.html --- iputils-s20101006.orig/doc/r3.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r3.html 2011-01-08 20:09:49.558814956 -0500 @@ -0,0 +1,1494 @@ + +ping
System Manager's Manual: iputils
PrevNext

ping

Name

ping, ping6 -- send ICMP ECHO_REQUEST to network hosts

Synopsis

ping [-LRUbdfnqrvVaAB] [-c count] [-m mark] [-i interval] [-l preload] [-p pattern] [-s packetsize] [-t ttl] [-w deadline] [-F flowlabel] [-I interface] [-M hint] [-N nioption] [-Q tos] [-S sndbuf] [-T timestamp option] [-W timeout] [hop...] {destination}

DESCRIPTION

ping 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.

ping6 can also send Node Information Queries (RFC4620).

OPTIONS

-a

Audible ping. +

-A

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. +

-b

Allow pinging a broadcast address. +

-B

Do not allow ping to change source address of probes. +The address is bound to one selected when ping starts. +

-m mark

use mark 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. +

-c count

Stop after sending count ECHO_REQUEST +packets. With +deadline +option, ping waits for +count ECHO_REPLY packets, until the timeout expires. +

-d

Set the SO_DEBUG option on the socket being used. +Essentially, this socket option is not used by Linux kernel. +

-F flow label

Allocate and set 20 bit flow label on echo request packets. +(Only ping6). If value is zero, kernel allocates random flow label. +

-f

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. +

-i interval

Wait interval 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. +

-I interface address

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. +

-l preload

If preload is specified, +ping sends that many packets not waiting for reply. +Only the super-user may select preload more than 3. +

-L

Suppress loopback of multicast packets. This flag only applies if the ping +destination is a multicast address. +

-N nioption

Send ICMPv6 Node Information Queries (RFC4620), instead of Echo Request. +

name

Queries for Node Names.

+

ipv6

Queries for IPv6 Addresses. There are several IPv6 specific flags. +

ipv6-global

Request IPv6 global-scope addresses.

+

ipv6-sitelocal

Request IPv6 site-local addresses.

+

ipv6-linklocal

Request IPv6 link-local addresses.

+

ipv6-all

Request IPv6 addresses on other interfaces.

+

+

ipv4

Queries for IPv4 Addresses. There is one IPv4 specific flag. +

ipv4-all

Request IPv4 addresses on other interfaces.

+

+

subject-ipv6=ipv6addr

IPv6 subject address.

+

subject-ipv4=ipv4addr

IPv4 subject address.

+

subject-name=nodename

Subject name. If it contains more than one dot, + fully-qualified domain name is assumed.

+

subject-fqdn=nodename

Subject name. Fully-qualified domain name is + always assumed.

+

-n

Numeric output only. +No attempt will be made to lookup symbolic names for host addresses. +

-p pattern

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, -p ff will cause the sent packet +to be filled with all ones. +

-D

Print timestamp (unix time + microseconds as in gettimeofday) before +each line. +

-Q tos

Set Quality of Service -related bits in ICMP datagrams. +tos 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). +

-q

Quiet output. +Nothing is displayed except the summary lines at startup time and +when finished. +

-R

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. +

-r

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 -I is also +used. +

-s packetsize

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. +

-S sndbuf

Set socket sndbuf. If not specified, it is selected to buffer +not more than one packet. +

-t ttl

Set the IP Time to Live. +

-T timestamp option

Set special IP timestamp options. +timestamp option may be either +tsonly (only timestamps), +tsandaddr (timestamps and addresses) or +tsprespec host1 [host2 [host3 [host4]]] +(timestamp prespecified hops). +

-M hint

Select Path MTU Discovery strategy. +hint may be either do +(prohibit fragmentation, even local one), +want (do PMTU discovery, fragment locally when packet size +is large), or dont (do not set DF flag). +

-U

Print full user-to-user latency (the old behaviour). Normally +ping +prints network round trip time, which can be different +f.e. due to DNS failures. +

-v

Verbose output. +

-V

Show version and exit. +

-w deadline

Specify a timeout, in seconds, before +ping +exits regardless of how many +packets have been sent or received. In this case +ping +does not stop after +count +packet are sent, it waits either for +deadline +expire or until +count +probes are answered or for some error notification from network. +

-W timeout

Time to wait for a response, in seconds. The option affects only timeout +in absense of any responses, otherwise ping waits for two RTTs. +

When using ping 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.

If ping does not receive any reply packets at all it will +exit with code 1. If a packet +count +and +deadline +are both specified, and fewer than +count +packets are received by the time the +deadline +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.

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 +ping during normal operations or from automated scripts.

ICMP PACKET DETAILS

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 packetsize 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).

If the data space is at least of size of struct timeval +ping 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.

DUPLICATE AND DAMAGED PACKETS

ping 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.

Damaged packets are obviously serious cause for alarm and often +indicate broken hardware somewhere in the +ping packet's path (in the network or in the hosts).

TRYING DIFFERENT DATA PATTERNS

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.

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 -p option of ping.

TTL DETAILS

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.

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).

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 +telnet(1) +or +ftp(1).

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:

  • 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. +

  • 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 from +the remote system to the pinging host. +

  • 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. +

BUGS

  • Many Hosts and Gateways ignore the RECORD_ROUTE option. +

  • 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. +

  • Flood pinging is not recommended in general, and flood pinging the +broadcast address should only be done under very controlled conditions. +

SEE ALSO

netstat(1), +ifconfig(8).

HISTORY

The ping command appeared in 4.3BSD.

The version described here is its descendant specific to Linux.

SECURITY

ping requires CAP_NET_RAWIO capability +to be executed. It may be used as set-uid root.

AVAILABILITY

ping is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
System Manager's Manual: iputils arping
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r437.html iputils-s20101006/doc/r437.html --- iputils-s20101006.orig/doc/r437.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r437.html 2011-01-08 20:09:49.571531343 -0500 @@ -0,0 +1,598 @@ + +arping
System Manager's Manual: iputils
PrevNext

arping

Name

arping -- send ARP REQUEST to a neighbour host

Synopsis

arping [-AbDfhqUV] [-c count] [-w deadline] [-s source] {-I interface} {destination}

DESCRIPTION

Ping destination on device interface by ARP packets, +using source address source.

OPTIONS

-A

The same as -U, but ARP REPLY packets used instead +of ARP REQUEST. +

-b

Send only MAC level broadcasts. Normally arping starts +from sending broadcast, and switch to unicast after reply received. +

-c count

Stop after sending count ARP REQUEST +packets. With +deadline +option, arping waits for +count ARP REPLY packets, until the timeout expires. +

-D

Duplicate address detection mode (DAD). See +RFC2131, 4.4.1. +Returns 0, if DAD succeeded i.e. no replies are received +

-f

Finish after the first reply confirming that target is alive. +

-I interface

Name of network device where to send ARP REQUEST packets. This option +is required. +

-h

Print help page and exit. +

-q

Quiet output. Nothing is displayed. +

-s source

IP source address to use in ARP packets. +If this option is absent, source address is: +

  • In DAD mode (with option -D) set to 0.0.0.0. +

  • In Unsolicited ARP mode (with options -U or -A) +set to destination. +

  • Otherwise, it is calculated from routing tables. +

+

-U

Unsolicited ARP mode to update neighbours' ARP caches. +No replies are expected. +

-V

Print version of the program and exit. +

-w deadline

Specify a timeout, in seconds, before +arping +exits regardless of how many +packets have been sent or received. In this case +arping +does not stop after +count +packet are sent, it waits either for +deadline +expire or until +count +probes are answered. +

AUTHOR

arping was written by +Alexey Kuznetsov +<kuznet@ms2.inr.ac.ru>. +It is now maintained by +YOSHIFUJI Hideaki +<yoshfuji@skbuff.net>.

SECURITY

arping 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.

AVAILABILITY

arping is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
ping clockdiff
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r596.html iputils-s20101006/doc/r596.html --- iputils-s20101006.orig/doc/r596.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r596.html 2011-01-08 20:09:49.582999920 -0500 @@ -0,0 +1,428 @@ + +clockdiff
System Manager's Manual: iputils
PrevNext

clockdiff

Name

clockdiff -- measure clock difference between hosts

Synopsis

clockdiff [-o] [-o1] {destination}

DESCRIPTION

clockdiff Measures clock difference between us and +destination with 1 msec resolution using ICMP TIMESTAMP +[2] +packets or, optionally, IP TIMESTAMP option +[3] +option added to ICMP ECHO. +[1]

OPTIONS

-o

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). +

-o1

Slightly different form of -o, 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, +-o is better for Linux. +

WARNINGS

  • Some nodes (Cisco) use non-standard timestamps, which is allowed +by RFC, but makes timestamps mostly useless. +

  • Some nodes generate messed timestamps (Solaris>2.4), when +run xntpd. 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. +

  • clockdiff shows difference in time modulo 24 days. +

REFERENCES

[1] ICMP ECHO, +RFC0792, page 14.

[2] ICMP TIMESTAMP, +RFC0792, page 16.

[3] IP TIMESTAMP option, +RFC0791, 3.1, page 16.

AUTHOR

clockdiff was compiled by +Alexey Kuznetsov +<kuznet@ms2.inr.ac.ru>. It was based on code borrowed +from BSD timed daemon. +It is now maintained by +YOSHIFUJI Hideaki +<yoshfuji@skbuff.net>.

SECURITY

clockdiff requires CAP_NET_RAWIO capability +to be executed. It is safe to be used as set-uid root.

AVAILABILITY

clockdiff is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
arping rarpd
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r691.html iputils-s20101006/doc/r691.html --- iputils-s20101006.orig/doc/r691.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r691.html 2011-01-08 20:09:49.590918871 -0500 @@ -0,0 +1,431 @@ + +rarpd
System Manager's Manual: iputils
PrevNext

rarpd

Name

rarpd -- answer RARP REQUESTs

Synopsis

arping [-aAvde] [-b bootdir] [interface]

DESCRIPTION

Listens +RARP +requests from clients. Provided MAC address of client +is found in /etc/ethers database and +obtained host name is resolvable to an IP address appropriate +for attached network, rarpd answers to client with RARPD +reply carrying an IP address.

To allow multiple boot servers on the network rarpd +optionally checks for presence Sun-like bootable image in TFTP directory. +It should have form Hexadecimal_IP.ARCH, f.e. to load +sparc 193.233.7.98 C1E90762.SUN4M is linked to +an image appropriate for SUM4M in directory /etc/tftpboot.

WARNING

This facility is deeply obsoleted by +BOOTP +and later +DHCP protocols. +However, some clients really still need this to boot.

OPTIONS

-a

Listen on all the interfaces. Currently it is an internal +option, its function is overridden with interface +argument. It should not be used. +

-A

Listen not only RARP but also ARP messages, some rare clients +use ARP by some unknown reason. +

-v

Be verbose. +

-d

Debug mode. Do not go to background. +

-e

Do not check for presence of a boot image, reply if MAC address +resolves to a valid IP address using /etc/ethers +database and DNS. +

-b bootdir

TFTP boot directory. Default is /etc/tftpboot +

SEE ALSO

arping(8), +tftpd(8).

AUTHOR

rarpd was written by +Alexey Kuznetsov +<kuznet@ms2.inr.ac.ru>. +It is now maintained by +YOSHIFUJI Hideaki +<yoshfuji@skbuff.net>.

SECURITY

rarpd 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.

AVAILABILITY

rarpd is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
clockdiff tracepath
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r790.html iputils-s20101006/doc/r790.html --- iputils-s20101006.orig/doc/r790.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r790.html 2011-01-08 20:09:49.602668583 -0500 @@ -0,0 +1,426 @@ + +tracepath
System Manager's Manual: iputils
PrevNext

tracepath

Name

tracepath, tracepath6 -- traces path to a network host discovering MTU along this path

Synopsis

tracepath [-n] [-b] [-l pktlen] {destination} [port]

DESCRIPTION

It traces path to destination discovering MTU along this path. +It uses UDP port port or some random port. +It is similar to traceroute, only does not require superuser +privileges and has no fancy options.

tracepath6 is good replacement for traceroute6 +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.

OPTIONS

-n

Print primarily IP addresses numerically. +

-b

Print both of host names and IP addresses. +

-l

Sets the initial packet length to pktlen instead of +65536 for tracepath or 128000 for tracepath6. +

OUTPUT

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

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 ?.

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.

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.

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.

SEE ALSO

traceroute(8), +traceroute6(8), +ping(8).

AUTHOR

tracepath was written by +Alexey Kuznetsov +<kuznet@ms2.inr.ac.ru>.

SECURITY

No security issues.

This lapidary deserves to be elaborated. +tracepath is not a privileged program, unlike +traceroute, ping and other beasts of this kind. +tracepath may be executed by everyone who has some access +to network, enough to send UDP datagrams to investigated destination +using given port.

AVAILABILITY

tracepath is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
rarpd traceroute6
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r884.html iputils-s20101006/doc/r884.html --- iputils-s20101006.orig/doc/r884.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r884.html 2011-01-08 20:09:49.606677412 -0500 @@ -0,0 +1,315 @@ + +traceroute6
System Manager's Manual: iputils
PrevNext

traceroute6

Name

traceroute6 -- traces path to a network host

Synopsis

traceroute6 [-dnrvV] [-i interface] [-m max_ttl] [-p port] [-q max_probes] [-s source] [-w wait time] {destination} [size]

DESCRIPTION

Description can be found in +traceroute(8), +all the references to IP replaced to IPv6. It is needless to copy +the description from there.

SEE ALSO

traceroute(8), +tracepath(8), +ping(8).

HISTORY

This program has long history. Author of traceroute +is Van Jacobson and it first appeared in 1988. This clone is +based on a port of traceroute 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 +iputils package.

SECURITY

tracepath6 requires CAP_NET_RAWIO capability +to be executed. It is safe to be used as set-uid root.

AVAILABILITY

traceroute6 is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
tracepath tftpd
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/r949.html iputils-s20101006/doc/r949.html --- iputils-s20101006.orig/doc/r949.html 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/r949.html 2011-01-08 20:09:49.614834740 -0500 @@ -0,0 +1,376 @@ + +tftpd
System Manager's Manual: iputils
PrevNext

tftpd

Name

tftpd -- Trivial File Transfer Protocol server

Synopsis

tftpd {directory}

DESCRIPTION

tftpd is a server which supports the DARPA +Trivial File Transfer Protocol +(RFC1350). +The TFTP server is started +by inetd(8).

directory is required argument; if it is not given +tftpd aborts. This path is prepended to any file name requested +via TFTP protocol, effectively chrooting tftpd to this directory. +File names are validated not to escape out of this directory, however +administrator may configure such escape using symbolic links.

It is in difference of variants of tftpd 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.

In the case when tftpd is used together with +rarpd(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 +rarpd(8) +for more details.

SECURITY

TFTP protocol does not provide any authentication. +Due to this capital flaw tftpd 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.

Impact is evident, directory exported via TFTP must not +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 +unencrypted passwords and may contain some information +about the network, which you were not going to make public.

The tftpd server should be executed by inetd +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, tftpd 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.

SEE ALSO

rarpd(8), +tftp(1), +inetd(8).

HISTORY

The tftpd command appeared in 4.2BSD. The source in iputils +is cleaned up both syntactically (ANSIized) and semantically (UDP socket IO).

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.

AVAILABILITY

tftpd is part of iputils package +and the latest versions are available in source form at +http://www.skbuff.net/iputils/iputils-current.tar.bz2.

PrevHomeNext
traceroute6 rdisc
\ No newline at end of file diff -Naur iputils-s20101006.orig/doc/rarpd.8 iputils-s20101006/doc/rarpd.8 --- iputils-s20101006.orig/doc/rarpd.8 1969-12-31 19:00:00.000000000 -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 iputils-s20101006.orig/doc/rdisc.8 iputils-s20101006/doc/rdisc.8 --- iputils-s20101006.orig/doc/rdisc.8 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/rdisc.8 2011-01-08 20:09:51.527155543 -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" "08 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. diff -Naur iputils-s20101006.orig/doc/tftpd.8 iputils-s20101006/doc/tftpd.8 --- iputils-s20101006.orig/doc/tftpd.8 1969-12-31 19:00:00.000000000 -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 iputils-s20101006.orig/doc/tracepath.8 iputils-s20101006/doc/tracepath.8 --- iputils-s20101006.orig/doc/tracepath.8 1969-12-31 19:00:00.000000000 -0500 +++ iputils-s20101006/doc/tracepath.8 2011-01-08 20:09:52.154780955 -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" "08 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 iputils-s20101006.orig/doc/traceroute6.8 iputils-s20101006/doc/traceroute6.8 --- iputils-s20101006.orig/doc/traceroute6.8 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.