14    Using the Problem Solving Tools

To help you resolve problems with network hardware, the network itself, and various network services, the Tru64 UNIX system provides problem solving tools to help you do the following tasks:

• Test access to network hosts on the Internet network

• Display and modify the Internet to Ethernet translation tables

• Display a datagram's route to a network host

• Display headers of packets on the network

• Test a uucp remote connection

• Monitor a uucp file transfer

• Display the error log file

• Display the syslogd daemon message files

14.1    Testing Reachability of Network Hosts on the Internet Network

You test your system's ability to reach a host on the Internet network by using the ping command. The ping command has the following syntax:

/usr/sbin/ping [options... ] hostname

Table 14-1 shows some of the ping command options.

Table 14-1:  Options to the ping Command

The ping command sends an Internet Control Message Protocol (ICMP) echo request to the host name specified. When the request is successful, the remote host sends the data back to the local host. If the remote host does not respond to the request, the ping command displays the following message:

unknown host hostname

See ping(8) for more information on this command.

To terminate the ping command output, press Ctrl/C. When terminated, the ping command displays statistics on packets sent, packets received, the percentage of packets lost, and the minimum, average, and maximum round-trip packet times.

You can use the output from the ping command to help determine the cause of direct and indirect routing problems such as an unreachable host, a timed-out connection, or an unreachable network.

When using the ping command to isolate faults, you should first test the local host to verify that it is running. If the local host returns the data correctly, use the ping command to test remote hosts farther and farther away from the local host.

If you do not specify command options, the ping command displays the results of each ICMP request in sequence, the number of bytes received from the remote host, and the round-trip time on a per-request basis.

The following example shows the output from a ping command to a host named host1:

% ping host1
PING host1.corp.com (16.20.32.2): 56 data bytes
64 bytes from 16.20.32.2: icmp_seq=0 ttl=255 time=11 ms
64 bytes from 16.20.32.2: icmp_seq=1 ttl=255 time=3 ms
64 bytes from 16.20.32.2: icmp_seq=2 ttl=255 time=7 ms
64 bytes from 16.20.32.2: icmp_seq=3 ttl=255 time=3 ms
64 bytes from 16.20.32.2: icmp_seq=4 ttl=255 time=7 ms
64 bytes from 16.20.32.2: icmp_seq=5 ttl=255 time=3 ms
[Ctrl/C]
----host1.corp.com PING Statistics---
6 packets transmitted, 6 packets received, 0% packet loss
roundtrip (ms) min/avg/max = 3/5/11 ms

14.2    Displaying and Modifying the Internet to Ethernet Translation Tables

You can display and modify the Internet to Ethernet translation tables used by the Address Resolution Protocol (ARP) to help solve direct routing problems resulting from the following circumstances:

• A source host has incorrect Ethernet address information for a destination host

• Two hosts have the same host name

  Although you can modify the translation tables and change the name, you should resolve the name conflict permanently by changing one host name.

To display the entries in the Internet to Ethernet address translation tables, use the arp command with the following syntax to translate an Internet address to an Ethernet address:

/usr/sbin/arp hostname

To modify the entries in the Internet to Ethernet address translation tables, do the following:

1. Log in as root.

2. Use the arp command and options as follows:

   /usr/sbin/arp [options ] hostname

Use the arp command to solve direct routing problems on an Ethernet.

See arp(8) for more information on this command.

The following example shows the Ethernet address for an Internet host named host1. The system response tells you that the Ethernet address for host1 is aa-00-04-00-8f-11.

# /usr/sbin/arp host1
host1 (16.20.32.2) at aa:0:4:0:8f:11 permanent trailers

The following example shows how to temporarily add host9 to the system translation tables:

# /usr/sbin/arp -s host9 0:dd:0:a:85:0 temp

The following example shows how to remove host8 from the system translation tables:

# /usr/sbin/arp -d host8

14.3    Displaying a Datagrams's Route to a Network Host

You can display a datagram's route to a network host to manually test, measure, and manage the network.

To display a datagram's route, use the traceroute command with the following syntax:

traceroute [options...] hostname [packetsize]

Table 14-2 lists some of the traceroute command options.

Table 14-2:  Options to the traceroute Command

The traceroute command sends UDP packets (known as probe packets) to an unused port on the remote host, and listens for ICMP replies from IP routers. The probe packets are sent with a small ttl parameter, which specifies the maximum number of hops a packet can take to reach its destination.

You might see the time exceeded and port unreachable ICMP messages when using the traceroute command. The ICMP time exceeded message means that the IP router that received the probe packet cannot forward it any further due to the ttl value. The ICMP port unreachable message means that the host that received the probe packet cannot access the port intended for the probe packet.

In displaying a routing path, the traceroute command starts by specifying a ttl value of one hop, and increasing the ttl value by one for each probe packet it sends. The time exceeded message tells you which IP routers are processing the packets. The port unreachable message tells you that the probe packet reached its intended destination, but could not access the intended port.

The traceroute command sends three probe datagrams for each ttl setting, and displays a line showing the following:

• ttl

• Address of the IP router

• Round-trip time of each probe datagram

If multiple IP routers respond to the probe, the traceroute command displays the address of each IP router. If the traceroute command does not elicit a response in 3 seconds (the default wait time), the command displays an asterisk (*) for the probe.

The following example shows a successful traceroute command to host2:

% traceroute host2
traceroute to host2 (555.55.5.5), 30 hops max, 40 byte packets
 1  host3 (555.55.5.1) 2 ms 2 ms 2 ms
 2  host5 (555.55.5.2) 5 ms 6 ms 4 ms
 3  host7 (555.55.5.3) 7 ms 7 ms 6 ms
 4  host2 (555.55.5.5) 12 ms 8 ms 8 ms

14.4    Displaying Headers of Packets on the Network

You display packet headers on the network any time you want to monitor the network traffic associated with a particular network service. This is usually done to determine whether requests are being received or acknowledged, or to determine the source of network requests, in the case of slow network performance.

To display packet headers for a network interface, use the tcpdump command with the following syntax:

tcpdump [options...]

The tcpdump command options enable you to specify the interface on which to listen, the direction of the packet transfer, the type of protocol traffic to display. In addition, it enables you to identify the source of the packet. See tcpdump(8) for more information.

Note

In order to use the tcpdump command, the packetfilter option must be configured into the kernel and the system rebooted.

14.5    Testing a UUCP Remote Connection

You test a uucp remote connection to solve problems; for example, to determine why there is a backlog of transfer requests in the queue.

To test a remote connection, do the following:

1. Log in as root.

2. Change to the /usr/lib/uucp directory by using the cd command.

3. Test the remote connection by using the uutry command, using the following syntax:

   uutry system_name

   The system_name variable names the remote system to contact.

4. Examine the debugging output; the last line contains the status of the transaction. If your local system succeeds in establishing a connection to the remote system, the debugging output will contain a good deal of information. You can press Ctrl/C to stop the uutry shell script.

The uutry command has the following characteristics:

• It is a shell script stored in the /usr/lib/uucp directory.

• It contacts a remote system with debugging turned on. If you are using the uucp scheduler, uusched, to start uucico automatically at specified intervals, the uutry command overrides the retry time interval specified in the /usr/spool/uucp/.Status/system_name file.

  If you use the uutry command frequently, you can put the pathname to the command in the PATH entry in your .profile file.

• It directs debugging information to a file named /tmp/system_name, where system_name is the name of the local system. The uutry command then executes a tail -f command to display the file's contents.

If your local system cannot contact the remote system, do the following:

1. Check the physical connections between the local and remote systems. At both systems, check that the computer is turned on, that all the cables are properly connected, that the ports are enabled, and the modems (if being used) are working. If the remote system is not at your physical location, contact the system administrator for the remote system.

2. Check all configuration files on both systems. Verify that all entries in the Devices, Systems, and Permissions files are correct. If you are using a modem, verify all entries in the Dialers and Dialcodes files.

   If you are using a TCP/IP connection, verify that configuration files contain the correct TCP entries. Verify that the inetd daemon can start the uucpd daemon. Edit the /etc/inetd.conf file and delete the comment character (#) from the beginning of the line containing the uucp entry. Restart the inetd daemon by using the following command:

   
   # /sbin/init.d/inetd start
   

Always save the debugging output produced by the uutry command until you are certain that the problem is resolved.

The following example shows a successful test of a remote connection to system host6:

# /usr/lib/uucp/uutry host6
   
.
.
.
Conversation Complete: Status SUCCEEDED

The following example shows an unsuccessful test of a remote connection to system host6:

# /usr/lib/uucp/uutry host6
   
.
.
.
mchFind called (host6)
conn (host6)
getto ret -1
Call Failed: CAN'T ACCESS DEVICE
exit code 101
Conversation Complete: Status FAILED

14.6    Monitoring a File Transfer

Monitoring a file transfer enables you to solve other UUCP problems, especially if you can already establish a remote UUCP connection.

To monitor a file transfer, do the following:

1. Check the status of the files in the spooling directory on your local system by using the uustat -q command.

2. Verify that the local system can contact the remote system by using the uutry system_name command.

3. If the debugging output indicates that the connection was not successful, follow the steps described in Section 14.5.

4. Prepare a file for transfer by using the uucp -r command. The -r option instructs uucp to place the file in the queue without starting the uucico daemon.

   Start the file transfer by using the uutry command.

See uutry(1) for additional information on the uutry command.

The following example sends the test1 file to the system host6:

# uucp -r test1 host6! ~/test1
# /usr/lib/uucp/uutry host6

14.7    Viewing the Error Log File

You can view the binary error log file, /var/adm/binary.errlog, to see the contents of system events recorded there. The error log file is a data file that is read with the uerf command.

The events recorded in the /var/adm/binary.errlog file include error messages relating to the system hardware and the software kernel, as well as information about system status, startup, and diagnostics.

The uerf command has the following syntax:

/usr/sbin/uerf [options...]

The uerf command runs the error report formatter and displays the contents of the /var/adm/binary.errlog file.

You can use the uerf command to diagnose kernel and hardware errors.

See System Administration and uerf(8) for a complete description of this command.

14.8    Viewing the syslogd Daemon Message Files

The syslogd daemon records system messages into a set of files. The syslogd daemon starts running from the /etc/rc.config file when you boot the system, and whenever it receives a hangup signal. Before the syslogd daemon starts logging system messages, it scans the /etc/syslog.conf file to determine its configuration information. The configuration information determines the files into which the syslogd daemon logs system messages.

System messages can contain a priority code indicating the type and severity of the message. For example, system messages can indicate error conditions and warnings.

The syslogd daemon is available to the entire system, including binary kernel errors. See syslogd(8) for a complete description of the syslogd daemon.

To review the syslogd daemon log files, do the following:

1. Change your current directory to the /etc directory by using the cd command.

2. Display the contents of the syslog.conf file, which tells you where the syslogd files are kept on your system, using the cat command:

   
   # cat syslog.conf
      #
      # syslogd config file
      #
      # facilities: kern user mail daemon auth syslog lpr binary
      # priorities: emerg alert crit err warning notice info debug
      kern.debug   /var/adm/syslog.dated/kern.log
      user.debug   /var/adm/syslog.dated/user.log
      mail.debug   /var/adm/syslog.dated/mail.log
      daemon.debug	/var/adm/syslog.dated/daemon.log
      auth.debug   /var/adm/syslog.dated/auth.log
      syslog.debug	/var/adm/syslog.dated/syslog.log
      lpr.debug    /var/adm/syslog.dated/lpr.log
      binary.err   /var/adm/binary.errlog
      msgbuf.err   /var/adm/crash/msgbuf.savecore
      kern.debug   /var/adm/messages
      kern.debug   /dev/console
      *.emerg      *
   

3. Change your current directory to the logging directory specified in the syslog.conf file. In the following example, the logging directory is /var/adm/syslog.dated/28-Oct-12:49

   # cd /var/adm/syslog.dated/28-Oct-12:49
   

4. Display the list of available log files by using the ls command.

5. Display the contents of the log file you want to see by using the cat command. In the following example, the file is daemon.log:

   # cat daemon.log
   

You can use the syslogd daemon to help solve session layer problems such as access control problems for the Internet Protocol (IP).