The traceroute Command Host Connectivity

21.2.2 The traceroute Command

The traceroute command is available to track routing−related problems in the network. As the command name says, it displays the route of the probe packets sent toward the destination host. Tracking the route that packets follow or finding the miscreant gateway thats discarding the packets can be difficult. traceroute utilizes the IP protocol TTL field time−to−live and attempts to elicit an ICMP response from each gateway along the path to the destination host. traceroute attempts to trace the route an IP packet would follow to the destination host by launching UDP probe packets with a small TTL time−to−live, and then listening for an ICMP time exceeded reply from a gateway. It starts the probes with a TTL of one 1 and increases by one until it gets an ICMP port unreachable which means it reached the host or hits a max the default is 30 hops. Three probes are sent at each TTL setting and a line is displayed showing the TTL, IP address of the gateway, and round trip time of each probe. If the probe answers come from different gateways, the address of each responding system will be displayed. If there is no response within a 5 second timeout interval, an asterisk is displayed for that probe. To prevent the destination host from processing the UDP probe packets, the destination port is set to an unlikely value. traceroute has the format: traceroute [options] hostname [packetlength] where the only mandatory parameter is the name of the destination host hostname; other parameters are optional. The default packet length is 40 bytes. A partial list of options includes: Option Meaning −f first_ttl Set the initial time−to−live used in the first outgoing probe packet. −g gateway Specify a loose source route gateway 8 maximum. −i interface Specify a network interface to obtain the source IP address for outgoing probe packets. This is normally only useful on a multihomed host. −m max_ttl Set the maximum time−to−live maximum number of hops used in outgoing probe packets. The default is 30 hops the same default used for TCP connections. −p port Set the base UDP port number used in probes default is 33434. It is assumed that nothing is listening on the UDP ports ranging from base to base + nhops − 1 at the destination host so an ICMP PORT_UNREACHABLE message will be returned to terminate the route tracing. If something is listening on a port in the default range, this option can be used to pick an unused port range. −s src_addr Use the following IP address usually given as an IP address, not a hostname as the source address in outgoing probe packets. On multihomed hosts with multiple interfaces, this option can be used to force the source address to be something other than the IP address of the interface the probe packet is sent on. If the IP address is not one of this machines interface addresses, an error is returned and nothing is sent. −t tos Set the type−of−service TOS in probe packets to the following value the default is zero. The value must be a decimal integer between 0 and 255. This option can be used 511 −w waittime Set the time in seconds to wait for a response to a probe the default is 5 seconds. −d Enable socket level debugging. −i Use ICMP ECHO instead of UDP datagrams. −n Display hop addresses numerically. −r Bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly attached network, an error is returned. −v Verbose output, ensures that all received ICMP packets are listed. −x Toggle checksums. Normally, this prevents traceroute from calculating checksums. An example follows: traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu 18.26.0.115, 30 hops max 1 helios.ee.lbl.gov 128.3.112.1 0 ms 0 ms 0 ms 2 lilac−dmc.Berkeley.EDU 128.32.216.1 19 ms 19 ms 19 ms 3 lilac−dmc.Berkeley.EDU 128.32.216.1 39 ms 19 ms 19 ms 4 ccngw−ner−cc.Berkeley.EDU 128.32.136.23 19 ms 39 ms 39 ms 5 ccn−nerif22.Berkeley.EDU 128.32.168.22 20 ms 39 ms 39 ms 6 128.32.197.4 128.32.197.4 59 ms 119 ms 39 ms 7 131.119.2.5 131.119.2.5 59 ms 59 ms 39 ms 8 129.140.70.13 129.140.70.13 80 ms 79 ms 99 ms 9 129.140.71.6 129.140.71.6 139 ms 139 ms 159 ms 10 129.140.81.7 129.140.81.7 199 ms 180 ms 300 ms 11 129.140.72.17 129.140.72.17 300 ms 239 ms 239 ms 12 13 128.121.54.72 128.121.54.72 259 ms 499 ms 279 ms 14 15 16 17 18 ALLSPICE.LCS.MIT.EDU 18.26.0.115 339 ms 279 ms 279 ms Note that gateways 12, 14, 15, 16, and 17 have reached timeout limits, and either do not send ICMP time exceeded messages or send them with a TTL too small to reach the originated host. There could be many different reasons for this; in this specific case it is known that gateways 14–17 are running the MIT C Gateway code that does not send time exceeded messages. 512 Section III: Supplemental UNIX Topics Chapter List Chapter 22: X Window System Chapter 23: Kernel Reconfiguration Chapter 24: Modems and UUCP Chapter 25: Intranet 513

Chapter 22: X Window System

22.1 An Introduction to the X Window System

X Window System is a network−based software package that provides the users friendly graphical interface. We will refer to X Window System shortly as X, or X11. X is based on the clientserver model, in which the X client application program does not directly access the display; instead it communicates with the X server the corresponding display program with the single task to control displaying. X was developed at MIT and is maintained by a not−for−profit consortium of vendors and universities, first known as MIT X Consortium, succeeded by X Consortium from 1993. It is a relatively highly standardized package that runs on almost every platform; X appeared relatively late, so it presents a compromise between needs of many vendors. The best known release is X11R6, although version X11R5 is also widely in use. All efforts to standardize X11 culminated in the introduction of Common Desktop Environment CDE, which had offered the best of X11. Today, CDE is the standard part of most UNIX installations, usually accompanied by a vendor−specific flavor of X11. CDE related X components are easy to recognize, they always do have dt prefix in their names stands for DeskTop. X11 presents a highly flexible and configurable package; correspondingly, an adequate administrative effort must be made to optimize X11 for the local site. Nevertheless, X11 can run with its default settings, which is sufficient for most of the implementations. We will discuss those issues in the first part of this Chapter. Although, every clientserver model does have two sides, studying X11 practically means to study the client side; X configuration and customization is always provided on the client host. Today, users are very familiar with the windows environment; almost every PC provides some version of the Microsoft Windows system. Although, MS Windows does not belong to X11, the similarities in the use are obvious; however, the rest is quite different. Nevertheless, credit for a broader introduction of windows as a graphic, user−friendly interface and environment actually should go to Macintosh for its contribution in this arena in the early 1970s.

22.1.1 The Design of X11

We mentioned already that X is based on the clientserver model. One important feature of the clientserver model is that client and server programs can communicate remotely, although, they can also reside at the very same system. An X client and an X server communicate using the X Protocol, which is supported by domain sockets internally and TCPIP externally. Many implementations consist of X servers and X clients running on independent remote machines, mutually connected by fast links. Links could be any kind of distant connections within a wide area network WAN, or mid−speed modem, or, what is the most common, a local area network LAN. This fact makes X ideal in a distributed computing environment — users can open a number of windows on a number of server machines, dealing simultaneously with a number of tasks running on a number of remote client machines. When an X client and an X server are running on distant machines, each of them provides its part of the common task. The X server is a part of the users local display machine; this machine could be very simple, even a single−tasking DOS−based PC. A complex part of the common task is happening at the client side, which is usually, a powerfull, multiuser system capable of running sophistiacted graphic applications. This feature has led to an intensive development of low−cost X terminals, designed especially for running X server. Using X terminals, multiple users can run graphics−intensive programs without a need to possess their own expensive powerful machines. 514