iputils, dosfstools python-lxml in main
This commit is contained in:
Ertuğrul Erata
@@ -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" "24 Mayıs 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.
|
||||
@@ -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" "24 Mayıs 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.
|
||||
@@ -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" "24 Mayıs 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 probe
|
||||
is 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 absence 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.
|
||||
@@ -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" "24 Mayıs 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.
|
||||
@@ -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" "24 Mayıs 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.
|
||||
@@ -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" "24 Mayıs 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 network 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.
|
||||
@@ -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" "24 Mayıs 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.
|
||||
Reference in New Issue
Block a user