1045 lines
37 KiB
Diff
1045 lines
37 KiB
Diff
|
--- /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.
|