Next | ||
ping |
ping, ping6. -+
arping. -+
clockdiff. -+
rarpd. -+
traceroute6. -+
rdisc. -+
tftpd. -+
pg3, ipg, pgset. -+
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: -+
ping | cloned of an ancient NetTools-B-xx |
ping6 | cloned of a very old Pedro's utility set |
traceroute6 | cloned of NRL Sep 96 distribution |
rdisc | cloned of SUN in.rdisc |
clockdiff | broken out of some BSD timed |
tftpd | it 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]
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.
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.
Different files are copyrighted by different persons and organizations -+and distributed under different licenses. For details look into corresponding -+source files.
[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. |
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.
-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. -+
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>.
Deering, S.E.,ed "ICMP Router Discovery Messages", -+RFC1256, Network Information Center, SRI International, -+Menlo Park, Calif., September 1991.
rdisc requires CAP_NET_RAWIO
to listen
-+and send ICMP messages and capability CAP_NET_ADMIN
-+to update routing tables.
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.
System Manager's Manual: iputils | ||
---|---|---|
Prev |
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:
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. -+
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.
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.
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.
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}
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).
-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.
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.
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).
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.
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. -+
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. -+
The ping command appeared in 4.3BSD.
The version described here is its descendant specific to Linux.
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.
-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. -+
arping was written by -+Alexey Kuznetsov -+<kuznet@ms2.inr.ac.ru>. -+It is now maintained by -+YOSHIFUJI Hideaki -+<yoshfuji@skbuff.net>.
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.
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.
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]
-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.
-+
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. -+
[1] ICMP ECHO, -+RFC0792, page 14.
[2] ICMP TIMESTAMP, -+RFC0792, page 16.
[3] IP TIMESTAMP option, -+RFC0791, 3.1, page 16.
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>.
clockdiff requires CAP_NET_RAWIO
capability
-+to be executed. It is safe to be used as set-uid root.
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.
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.
This facility is deeply obsoleted by -+BOOTP -+and later -+DHCP protocols. -+However, some clients really still need this to boot.
-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 -+
rarpd was written by -+Alexey Kuznetsov -+<kuznet@ms2.inr.ac.ru>. -+It is now maintained by -+YOSHIFUJI Hideaki -+<yoshfuji@skbuff.net>.
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.
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.
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 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.
-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. -+
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 -+folloing 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.
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.
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.
traceroute6 [-dnrvV
] [-i interface] [-m max_ttl] [-p port] [-q max_probes] [-s source] [-w wait time] {destination} [size]
Description can be found in -+traceroute(8), -+all the references to IP replaced to IPv6. It is needless to copy -+the description from there.
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.
tracepath6 requires CAP_NET_RAWIO
capability
-+to be executed. It is safe to be used as set-uid root.
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.
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.
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.
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.
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.
Next | ||
ping |
ping, ping6. ++
arping. ++
clockdiff. ++
rarpd. ++
traceroute6. ++
rdisc. ++
tftpd. ++
pg3, ipg, pgset. ++
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: ++
ping | cloned of an ancient NetTools-B-xx |
ping6 | cloned of a very old Pedro's utility set |
traceroute6 | cloned of NRL Sep 96 distribution |
rdisc | cloned of SUN in.rdisc |
clockdiff | broken out of some BSD timed |
tftpd | it 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]
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.
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.
Different files are copyrighted by different persons and organizations ++and distributed under different licenses. For details look into corresponding ++source files.
[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. |
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.
-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. ++
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>.
Deering, S.E.,ed "ICMP Router Discovery Messages", ++RFC1256, Network Information Center, SRI International, ++Menlo Park, Calif., September 1991.
rdisc requires CAP_NET_RAWIO
to listen
++and send ICMP messages and capability CAP_NET_ADMIN
++to update routing tables.
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.
System Manager's Manual: iputils | ||
---|---|---|
Prev |
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:
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. ++
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.
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.
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.
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}
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).
-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.
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.
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).
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.
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. ++
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. ++
The ping command appeared in 4.3BSD.
The version described here is its descendant specific to Linux.
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.
-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. ++
arping was written by ++Alexey Kuznetsov ++<kuznet@ms2.inr.ac.ru>. ++It is now maintained by ++YOSHIFUJI Hideaki ++<yoshfuji@skbuff.net>.
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.
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.
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]
-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.
++
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. ++
[1] ICMP ECHO, ++RFC0792, page 14.
[2] ICMP TIMESTAMP, ++RFC0792, page 16.
[3] IP TIMESTAMP option, ++RFC0791, 3.1, page 16.
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>.
clockdiff requires CAP_NET_RAWIO
capability
++to be executed. It is safe to be used as set-uid root.
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.
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.
This facility is deeply obsoleted by ++BOOTP ++and later ++DHCP protocols. ++However, some clients really still need this to boot.
-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 ++
rarpd was written by ++Alexey Kuznetsov ++<kuznet@ms2.inr.ac.ru>. ++It is now maintained by ++YOSHIFUJI Hideaki ++<yoshfuji@skbuff.net>.
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.
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.
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.
-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. ++
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.
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.
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.
traceroute6 [-dnrvV
] [-i interface] [-m max_ttl] [-p port] [-q max_probes] [-s source] [-w wait time] {destination} [size]
Description can be found in ++traceroute(8), ++all the references to IP replaced to IPv6. It is needless to copy ++the description from there.
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.
tracepath6 requires CAP_NET_RAWIO
capability
++to be executed. It is safe to be used as set-uid root.
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.
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.
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.
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.
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.