InformIT: Mac OS X Unleashed > Testing Network Settings

Table of Contents

Testing Network Settings

Being inherently networked operating systems from the original design, Unix-based operating systems have a rather complete suite of network diagnostic software that comes with the basic operating system by default. We'll cover interaction with the command-line versions of these tools in several chapters to come. Apple has also provided a convenient GUI tool that functions as a front end to many of the diagnostics that the command-line tools can perform. Although it doesn't provide access to the complete range of options for each of the commands, the Network Utility application (path: /Applications/Network Utility) is convenient for those who don't care to remember the syntax of command-line tools. The drawback is, it tends to be considerably slower than the underlying commands that it invokes (30-plus seconds in the GUI, compared to less than a second at the command line). The Network Utility application provides access to the following network diagnostics:

Info

The Interface Information (command-line command ifconfig) diagnostic gives you configuration information about your network interface. Shown in Figure 9.20, this diagnostic provides information regarding the traffic and error rate of the interface, as well as speed, hardware address, and vendor information.

Figure 9.20 The Info pane of the Network utility provides information regarding the network inter- face and its performance.

Netstat

The Network statistics (command-line command netstat) diagnostic gives you statistical information regarding your network. It can provide three types of network information—routing tables, by-protocol comprehensive statistics, and multicast statistics. The information that's provided is extremely terse and dense, but with experience, it can prove invaluable in diagnosing network problems. The routing information display is shown in Figure 9.21.

Figure 9.21 Click the Netstat button to look up connection information, but don't be surprised if you have to wait a while.

To get this information takes the GUI client some time, and you might have to wait for several minutes before the utility responds. The routing information specifies what your computer knows about how to get information to remote locations. The information displayed in Figure 9.21 indicates that the machine knows how to send information to two machines (spider.columbus.rr.com and 192.168.1.103) directly, to an entire (192.168.1) by one route, and to all other locations (default), by going through spider.columbus.rr.com, which is this machine's default router. The comprehensive network statistics display includes considerably more information than fits in the display in Figure 9.22. Included is a fairly complete listing of every type of network connection and traffic that your machine has engaged in, and any problems or abnormalities that have been observed with the data transmissions for that traffic.

Figure 9.22 A portion of the comprehensive network statistics display of the Network Utility.

The multicast information display provides information regarding multicast broadcast network information. If you are using your machine to stream QuickTime video, or for other multicast applications, this display might provide you with useful information. Otherwise, you should expect it to remain essentially empty, as shown in Figure 9.23.

Figure 9.23 The multicast information display of the Network Utility. If you do not use multicast services, expect this display to remain essentially empty.

Ping

The Ping panel, provides network connection/traffic testing (command-line program ping), as shown in Figure 9.24. It enables you to ping a remote machine to determine whether it, and the network between your machine and it, is alive. The ping program injects packets destined for a remote machine into the network, destined for a mandatory service that echoes the ping back to the originating machine. Usually, 10 packets are injected into the network at one-second intervals, and the round-trip time, as well as information regarding any packets that don't complete the trip is reported back. You have the option of continuously sending packets to the remote host, but unless you have permission and a good reason to do so, this is usually considered, at the minimum, to be rude. The icmp_seq value increases by one for every packet sent, so if you see a gap in the values displayed, you know that one (or more) packets did not complete their round-trips. Also displayed is a TTL (Time To Live) value, which starts at 255, and decreases for every machine that reroutes the packet. Usually, all these values will be the same, but if network trouble causes packets to take alternative routes between the machines, differing TTL values might be reflected. To keep errant packets from circling the Internet forever, each packet is restricted to a finite number of machines—usually 255—that can touch it before it dies. Packets that get lost in routing loops and never make it to their destination quickly run out of TTL counts and are discarded. Finally, the time each packet took to traverse the network is displayed in milliseconds (thousandths of a second).

Figure 9.24 The Ping panel of the Network Utility allows you to determine whether a remote host can be reached, and how the network between the machines is performing.

Lookup

The Lookup (command-line command nslookup or dig) diagnostic enables you to query the DNS (Domain Name Service) information for a machine. This includes information that maps the fully qualified domain name (like www.killernuts.org) to an IP address, and considerable additional information as well. The default operation of the diagnostic is to look up IP addresses for an FQDN, as shown in Figure 9.25.

Figure 9.25 The results of a default search for www.killernuts.org with the Lookup tool of the Network Utility application….

The diagnostic can also look up other types of information out of the DNS, such as what machine handles the e-mail for a host, and the canonical names (aliases) by which it might be known. Figure 9.26 shows the range of options for the lookup diagnostic. We recommend the use of the dig version because nslookup is deprecated, and can't be guaranteed to return complete information in the future.

Figure 9.26 The Lookup type options for the Lookup tool of the Network Utility application set the amount of data that will be queried from the remote server.

The information that the Lookup tool can provide include

Default Information— The default information returned by the DNS server in response to a query. Typically, the IP address to hostname mapping, the Start of Authority (SOA) record holders for the domain name, and the authoritative DNS servers for the domain.
Internet Address— The IP address associated with a host name.
Canonical Name— An IP address can have both a proper name, and potentially multiple alias names that point to it. The canonical name lookup provides information on the proper name that is equivalent to an alias.
CPU/OS Type— Attempts to get operating system and CPU information for a remote host, but this is not a mandatory item for the host to provide to the world.
Mailbox Information— Mailbox or mailing list information. There is no requirement that this information be maintained correctly on the DNS host, so the results of a query for this information should not be considered definitive.
Mailbox Exchange— MX (Mail Exchanger) record information. It is frequently impractical to have every host in a domain manage its own incoming e-mail. For this reason, a DNS record might specify that mail appearing to be destined for one particular host be routed instead to an alternative destination. This allows, for example, mail to ray@calvin.biosci.ohio-state.edu, ray@suzie.biosci.ohio-state.edu, and ray@waashu.biosci.ohio-state.edu to all be routed to, and received by the mail server machine ryoko.biosci.ohio-state.edu.
Name Server— Returns the list of authoritative name servers for a domain.
Host Name for Address— Reverse lookup of an FQDN for a particular IP address.
Start-of-Authority— A particular DNS server must be specified as the authoritative server for a particular IP-to-domain name mapping. There is an additional piece of information, known as the Start of Authority (SOA) record, that specifies a host that is authoritative for other information, such as contact information for problems with the domain. Frequently these are the same, but it is possible that DNS information may be delegated to servers that do not have all the same information stored as the SOA records. For example, when DNS information is maintained internally by a domain but a parent organization keeps administrative control. In this case, the SOA records should be consulted for all information other than IP-to-hostname mapping.
Text Information— Any optionally registered textual information regarding the queried host. Few domains register anything interesting in this field.
Well Known Services— Return information regarding well-known service types that the host might be providing. This is intended to give information regarding such things as whether the host is running FTP services, or HTTPD services, and so on. This is not a required piece of information for a host to provide to its DNS server, so few bother to provide correct or interesting information here.
Any/All Information— Investigate and return all known information regarding the host. The actual information returned depends on the configuration of the server queried and the information it contains. Typically, a query for All information returns something similar to the default information.

Traceroute

The Traceroute diagnostic provides information on the route that a packet must travel between your machine and a remote machine. When the network is working properly, this information will usually be of little interest to you. If you can't reach a remote machine, however, it is sometimes useful to see to be able to tell whether the problem is with only a segment of the network, or if it's with the remote machine itself. Figure 9.27 shows the result of a successful traceroute to the host www.tcp.com. Each line of the output indicates a machine through which the traffic to www.tcp.com had to be routed, and the time it took for that particular router to respond. The trace ends at the host www.tcp.com, indicating that the network is successful at transmitting data between the querying host, and www.tcp.com.

Figure 9.27 The Traceroute output includes diagnostic information regarding each router that the packet needed to traverse to reach the remote host.

Figure 9.28 shows the result of an attempt to trace the route to a host that is down, on the same subnet as www.tcp.com. The traffic in this case manages to make it almost all the way to its final destination, but cannot reach the requested final host. If we know that the host is not, in fact, the next machine along the network, we can infer that the problem is actually a network problem. Therefore, the routing of traffic between your machine and the remote machine is currently defective.

Figure 9.28 The output from a Traceroute showing an unsuccessful attempt to reach a remote host on the same subnet as www.tcp.com.

If a transient failure were occurring in the Internet and the trace stopped well before reaching the target host's subnet, we could determine that the problem reaching the host was because of something other than the host itself being down.

Whois

The Whois (command-line program whois) program actually has a more flexible use than is presented by this tool. It is designed to talk to remote servers that provide a sort of phone directory function. Apple has pointed the Whois tool of the Network Utility application to a subset of whois servers that provide directory information regarding the ownership and management of hostnames and domains. Figure 9.29 shows the results of trying to use the Whois tool to look up www.killernuts.org. The whois.internic.net machine knows only that another server, whois.networksolutions.com, should know the complete information for this host.

Figure 9.29 The output from whois for www.killernuts.org at whois.internic.net.

The information shown in Figure 9.29 indicates that the whois server selected, whois.internic.net, knows only that the complete information should be available from another server, whois.networksolutions.com. Figure 9.30 shows a portion of the results of selecting whois.networksolutions.com and reissuing the whois query for www.killernuts.org.

Figure 9.30 The output from whois for www.killernuts.org at whois.networksolutions.com. This server knows considerably more about the host.

If you're willing to ignore the sample text in Apple's dialog box, you can also use the Whois tool from the Network Utility application to query other whois servers. For example, if you point the host at ohio-state.edu, you can find out everyone who has ray in their name by searching for ray in the domain address box. Figure 9.31 shows a portion of the results of this search. This particular Whois server will also enable you to get more specific information regarding the people identified, and gives instructions at the bottom of the listing of names. Other whois servers can be contacted similarly, and can be used to obtain a range of types of information.

Figure 9.31 The output from a misuse of the Whois tool of the Network Utility application to query a whois server that doesn't provide domain name information.

Finger

The Finger (command-line program finger) tool of the Network Utility application gives you the ability to query the finger server of a host. This server, if enabled, will provide information regarding who a user is (full name, and so on), and when the user was most recently logged in. It is generally considered to be a minor security risk to run the finger server, because it lets crackers know whether it's safe to break into a system. But, if you know of a machine that has the service enabled, you can use this tool to access it. Figure 9.32 shows the results of using the finger tool to finger ray@rosalyn.biosci.ohio-state.edu. Notice that the server returns information about all known users with ray in their names. Different finger servers will return different information about users. This one is rather sparse, leaving out most of the users' personal information, but still indicates whether the users are logged in or not.

Figure 9.32 The output of a Finger tool lookup of ray@rosalyn.biosci.ohio-state.edu.

Port Scan (various command-line programs) establishes connections between logical constructs, known as ports, that are created by the networking software of each machine. These ports can be thought of as analogous to a series of numbered sockets into which a network connection can be plugged. The network connection must be plugged into one socket on each communicating machine; hence, it has an originating port and a destination port. Some network services always exist at particular fixed ports, and are connected to by existing at these known locations. Other applications attempt to generate a small level of security by opening a randomly numbered port and not advertising its presence. Connections then require that a connecting machine know where to look to find them. This isn't a particularly useful way of establishing security, but it does turn out to be a reasonably decent way for a cracker to hide the fact that he or she has broken into your machine. Once compromised, many crackers will install a backdoor on an unknown port, so they can come and go undetected, instead of connecting to the normal known ports, and thereby incurring a noticeable connection to a known service.

The Port Scan tool of the Network Utility application causes your machine to examine all the ports on a remote machine, and tell you which of them appear to have software listening to them. If the monitored ports don't correspond to known services, it's possible that there's been a network break in. Unfortunately, the Port Scan tool in 10.0.2 does not appear to give complete and reliable information. The machine shown in Figure 9.33 is running Sendmail, an FTP server, and an HTTPD server that exists on known ports 21, 25, and 80. None of these show up in the scan, and only some of the ports that do can be accounted for with known processes. All in all, we're not too happy about the current performance of the Port Scan tool. There are better ways of examining your own machine (netstat, at the command line for one), and it doesn't appear that the Port Scan tool provides reliable information. Additionally, it is considered to be excruciatingly bad form to portscan someone else's computer. This is exactly the methodology that crackers use to examine a machine for known vulnerabilities. We'd go so far as to say that it is a bit irresponsible of Apple to have put this tool in a user-level GUI application, and we recommend that you not use it, except on your own devices. Scanning a host without permission can be considered an attempted break-in, and could result in legal action against you.

Figure 9.33 The (incorrect in this case) output of the Port Scan tool of the Network Utility application.

Summary | Next Section

Previous Section