| Next | ||
| ping |
ping, ping6. +
arping. +
clockdiff. +
rarpd. +
traceroute6. +
rdisc. +
tftpd. +
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.
-aAccept 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. +
-bOpposite to -a, i.e. install only router with the best
+preference value. It is default behaviour.
+
-dSend debugging messages to syslog. +
-fRun 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.
+
-sSend 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.
+
-tTest mode. Do not go to background. +
-vBe verbose i.e. send lots of debugging messages to syslog. +
-VPrint 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 DEVICEName of Ethernet device to test. See +warning below. +
pkt_size BYTESSize 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 NUMBEREach packet will contain NUMBER of fragments. +Maximal amount for linux-2.4 is 6. Far not all the devices support +fragmented buffers. +
count NUMBERSend stream of NUMBER of packets and stop after this. +
ipg TIMEIntroduce artificial delay between packets of TIME +microseconds. +
dst IP_ADDRESSSelect 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_ADDRESSSelect 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. +
stopAbort 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).
-aAudible ping. +
-AAdaptive 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. +
-bAllow pinging a broadcast address. +
-BDo not allow ping to change source address of probes. +The address is bound to one selected when ping starts. +
-m markuse 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 countStop after sending count ECHO_REQUEST +packets. With +deadline +option, ping waits for +count ECHO_REPLY packets, until the timeout expires. +
-dSet the SO_DEBUG option on the socket being used.
+Essentially, this socket option is not used by Linux kernel.
+
-F flow labelAllocate and set 20 bit flow label on echo request packets. +(Only ping6). If value is zero, kernel allocates random flow label. +
-fFlood 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 intervalWait 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 addressSet 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 preloadIf preload is specified, +ping sends that many packets not waiting for reply. +Only the super-user may select preload more than 3. +
-LSuppress loopback of multicast packets. This flag only applies if the ping +destination is a multicast address. +
-N nioptionSend ICMPv6 Node Information Queries (RFC4620), instead of Echo Request. +
nameQueries for Node Names.
ipv6Queries for IPv6 Addresses. There are several IPv6 specific flags. +
ipv6-globalRequest IPv6 global-scope addresses.
ipv6-sitelocalRequest IPv6 site-local addresses.
ipv6-linklocalRequest IPv6 link-local addresses.
ipv6-allRequest IPv6 addresses on other interfaces.
ipv4Queries for IPv4 Addresses. There is one IPv4 specific flag. +
ipv4-allRequest IPv4 addresses on other interfaces.
subject-ipv6=ipv6addrIPv6 subject address.
subject-ipv4=ipv4addrIPv4 subject address.
subject-name=nodenameSubject name. If it contains more than one dot, + fully-qualified domain name is assumed.
subject-fqdn=nodenameSubject name. Fully-qualified domain name is + always assumed.
-nNumeric output only. +No attempt will be made to lookup symbolic names for host addresses. +
-p patternYou 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.
+
-DPrint timestamp (unix time + microseconds as in gettimeofday) before +each line. +
-Q tosSet 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).
+
-qQuiet output. +Nothing is displayed except the summary lines at startup time and +when finished. +
-RRecord 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. +
-rBypass 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 packetsizeSpecifies 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 sndbufSet socket sndbuf. If not specified, it is selected to buffer +not more than one packet. +
-t ttlSet the IP Time to Live. +
-T timestamp optionSet 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 hintSelect 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). +
-UPrint 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. +
-vVerbose output. +
-VShow version and exit. +
-w deadlineSpecify 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 timeoutTime 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.
-AThe same as -U, but ARP REPLY packets used instead
+of ARP REQUEST.
+
-bSend only MAC level broadcasts. Normally arping starts +from sending broadcast, and switch to unicast after reply received. +
-c countStop after sending count ARP REQUEST +packets. With +deadline +option, arping waits for +count ARP REPLY packets, until the timeout expires. +
-DDuplicate address detection mode (DAD). See +RFC2131, 4.4.1. +Returns 0, if DAD succeeded i.e. no replies are received +
-fFinish after the first reply confirming that target is alive. +
-I interfaceName of network device where to send ARP REQUEST packets. This option +is required. +
-hPrint help page and exit. +
-qQuiet output. Nothing is displayed. +
-s sourceIP 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. +
-UUnsolicited ARP mode to update neighbours' ARP caches. +No replies are expected. +
-VPrint version of the program and exit. +
-w deadlineSpecify 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]
-oUse 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). +
-o1Slightly 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.
-aListen on all the interfaces. Currently it is an internal +option, its function is overridden with interface +argument. It should not be used. +
-AListen not only RARP but also ARP messages, some rare clients +use ARP by some unknown reason. +
-vBe verbose. +
-dDebug mode. Do not go to background. +
-eDo 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 bootdirTFTP 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.
-nPrint primarily IP addresses numerically. +
-bPrint both of host names and IP addresses. +
-lSets 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.