DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Troubleshooting TCP/IP

Troubleshooting TCP/IP

From time to time, you will encounter problems using your TCP/IP network. The general procedures in this section can help solve most problems.

In addition, the following sections contain information on troubleshooting PPP, routing problems and various TCP/IP protocols:

Checking for software problems

If there is trouble on the network, here are some actions you can take to diagnose and fix software-related problems.

  1. Determine the status of the network and the network interfaces, as described in:

  2. Check the accuracy of the lines defining the network interfaces in the /etc/confnet.d/inet/interface file. See the interface(4tcp) manual page for the format of an entry in the interface file. In particular, check whether incorrect values have been defined for the netmask and broadcast addresses of the system's network adapters. If necessary, use the Network Configuration Manager to change the TCP/IP configuration for a network adapter. See ``Adjusting your netmask to correct routing problems'' for more information.

  3. Check whether you can send network packets to yourself as described in ``Verifying local network connectivity''.

  4. Check whether you can send network packets to other systems as described in ``Verifying remote network connectivity''.

  5. Check the /etc/hosts file to make sure that the entries are correct and up to date. See hosts(4tcp) for a description of the format of this file.

  6. If your system uses DNS to resolve host names to IP addresses, check the /etc/resolv.conf file to make sure that the entries are correct. See resolv.conf(4tcp) for a description of the format of this file. Use the ping(1Mtcp) command (as described in ``Verifying remote network connectivity'') to verify that you can access the name servers that are listed in this file.

  7. If your system will provide services such as file transfer (in.ftpd), remote login (in.rlogind and in.telnetd), and remote shell execution (in.rshd), make sure the network daemon inetd is running by entering the command:

    ps -ef | grep inetd

    The resulting display should resemble the following if the inetd daemon is running:

    root 21038   359   TS  80  0   Oct 15 ?      0:01 /usr/sbin/inetd
    root 16155 16100   TS  85  0 12:37:10 pts/3  0:00 grep inetd
    
    If inetd is not running, restart it by entering:

    sacadm -s -p inetd

    or by shutting down and rebooting the machine.


    NOTE: The ``Improved'' and ``High'' system security profiles disable some services that are listed in /etc/inetd.conf. See ``Security profiles'' for more information.

  8. Turn on logging by the various TCP/IP server daemons as described in ``Logging troubleshooting information''.

Listing entries in the netdrivers file

You can use the netinfo command to see the network devices that are configured on a host.

To list all the devices for the network adapters that are installed in your machine, enter:

netinfo -l dev

To show which devices are mapped to the Internet protocol suite (inet), enter:

netinfo -p inet


NOTE: netinfo does not display any information for the loopback device.

See also ``Verifying the configuration of network interfaces''.

Verifying the configuration of network interfaces

The ifconfig(1Mtcp) command displays information about the configuration for a named network interface. To find out the configuration for all network devices that are currently installed, enter:

ifconfig -a

This command will display output similar to the following. The exact format will depend on the network interfaces that are configured on your system.

en0: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 150.162.7.7 netmask ffffff00 broadcast 150.162.7.255
        perf. params: recv size: 4096; send size: 8192; full-size frames: 1
        ether 00:20:af:f2:91:19
        (alias) inet 150.162.7.52 netmask ffffff00 broadcast 150.162.7.255
        (alias) inet 150.162.7.54 netmask ffffff00 broadcast 150.162.7.255
lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
        inet 127.0.0.1 netmask ff000000
        perf. params: recv size: 4096; send size: 8192; full-size frames: 1
        (alias) inet 127.0.0.1 netmask ff000000
From this output, several things can be deduced about the en0 interface:

The lo0 entry is for the loopback interface. This is used for communication using the Internet protocols on the host itself.

Verifying the presence of TCP/IP interfaces

Additionally, you can use the netstat -i command to see which interfaces are currently configured. You should see the loopback interface, plus one interface for each networking card or serial line protocol (SLIP or PPP) on your system.

If you do not see a networking card or serial line protocol that you know exists on your system, reconfigure it using the Network Configuration Manager.

Displaying activity on a network interface

You can use the -I option to netstat to display the number of packets sent and received on an interface in a given time interval. For example, the following command displays activity on the en0 network interface every 5 seconds:

netstat -I en0 5

The output appears similar to the following:

input  (en0)   output                 input  (Total)  output
packets  errs  packets   errs  colls  packets   errs  packets   errs  colls
5533475   276  4615973    460  14899  6063429    276  5145927    460  14899
      2     0        1      0      0        2      0       1       0      0
      5     0        3      0      0        5      0       3       0      0
     21     0       21      0      0       21      0      21       0      0
...
The first row of figures shows the cumulative totals since TCP/IP was last started. Subsequent rows show statistics collected in the previous five seconds. The first five columns show numbers of input and output packets, errors and collisions for the en0 interface. The remaining columns show the totals for all interfaces including the loopback interface. Errors indicate packets lost due to hardware problems such as breaks in the network or faulty adapter hardware. Collisions on an Ethernet are caused by two or more hosts trying to broadcast at the same time. This is not normally a problem unless the ratio of collisions to output packets rises above 10%.

Displaying per-protocol statistics

The -s option to netstat displays per-protocol statistics for the Internet Control Message Protocol (ICMP), the Internet Group Management Protocol (IGMP), the Internet Protocol (IP), the Transmission Control Protocol (TCP), and the User Datagram Protocol (UDP). To display statistics for all protocols, enter:

netstat -s

To display statistics for a particular protocol, enter:

netstat -s -p protocol

The name of the protocol must be entered in lowercase letters. For example, to display statistics for IP, enter:

netstat -s -p ip

This produces statistics similar to the following:

ip:
   	376003 total packets received
	0 bad header checksums
	0 with size smaller than minimum
	0 with data size < data length
	0 with header length < data size
	0 with data length < header length
	0 with unknown protocol
	0 fragments received
	0 fragments dropped (dup or out of space)
	0 fragments dropped after timeout
	0 packets reassembled
	0 packets forwarded
	4588 packets not forwardable
	2 no routes
	0 redirects sent
	0 system errors during input
	371415 packets delivered
	7750 total packets sent
	0 system errors during output
	0 packets fragmented
	0 packets not fragmentable
	0 fragments created
The statistical information can show areas where a protocol is having problems.

Verifying local network connectivity

The ping(1Mtcp) command sends TCP/IP packets to the desired destination and, if successful, returns packets to the sender. With ping, you can verify that the TCP/IP stack is configured correctly on the local host and that your system can reach others via configured interfaces. To verify connectivity:

  1. Enter ping -n 127.0.0.1. This routes packets through the loopback mechanism, and should always succeed regardless of the state of your networking hardware or cabling. If it fails, use the Network Configuration Manager to reconfigure TCP/IP.

  2. Verify your network connections by using ping to try to contact one or more hosts on the local network that you know are running TCP/IP. For example, you might enter ping -n 192.168.1.57 or ping don.


    NOTE: If you know the IP address (IP_addr) of the system to be pinged, use the ping -n IP_addr form of the command rather than ping domain_name as this will avoid the system having to resolve the name (which may itself be a source of problems).

When you ping a remote host, the following results are possible:

Verifying remote network connectivity

If you can ping hosts on the local network, try to ping one that is remotely connected via a gateway or router:

Flushing phantom connections

Use the netstat -a command to display active connections and sockets. Look for phantom connections in the output from this command -- there may still be active sockets for processes that terminated abnormally. If many appear, your network may run slowly. Stop and restart TCP/IP to flush the connections.

Troubleshooting packet errors

The netstat -i command displays active interfaces (network card and serial interfaces) as well as statistics on:


Ipkts
input packets per interface

Ierrs
input errors per interface

Opkts
output packets per interface

Oerrs
output errors per interface

Coll
packet collisions detected
Here is a sample output:
   Name  Mtu    Network       Address     Ipkts  Ierrs Opkts   Oerrs Coll
   en0   1500   172.16.118    don         1348   12    1854    23    65
   lo0   8232   loopback      localhost   4058   0     4058    0     0
In using netstat -i, you should verify that the card is receiving and sending packets (that Ipkts and Opkts are nonzero), and that input and output errors as well as collisions are a small percentage of the packet total.

If both Ipkts and Ierrs are zero, the connection to the network may be bad, the network card may be bad, or there may be an interrupt vector conflict. Verify network cabling, then check for interrupt conflicts by running hwconfig or vectorsinuse. If a conflict exists, use the Network Configuration Manager to reconfigure your card. If the cable and interrupt vectors check out, run any diagnostic tools supplied by the manufacturer of the networking card.

If Ipkts is zero, but Ierrs is nonzero, the network, cabling, or card may be bad, another host on the network may be generating bad packets, or the network may be incorrectly terminated.

If Opkts is zero and Oerrs is nonzero, there may be a conflict of I/O addresses on the system. If both are zero, the conflict may be in shared memory addresses. Verify the I/O and shared memory addresses of each card on your system, and reconfigure your networking card with other supported addresses if conflicts exist.

If Coll is high (greater than 1-2 percent of the Opkts total), your network is very busy. Consider breaking the network into multiple separate networks.

Logging troubleshooting information

Most of the server daemons started by /etc/inetd.conf accept a -d option to force all sockets to be created with debugging turned on. Their activity is logged by default in /var/adm/log/osmlog. To enable logging:

  1. Edit /etc/inetd.conf to add the -d option to each daemon whose activity you want to log.

  2. Force inetd to re-read /etc/inetd.conf by sending it a SIGHUP signal:

    kill -HUP `cat /etc/saf/inetd/_pid`

    or by stopping and restarting it:

    sacadm -k -p inetd
    sacadm -s -p inetd

If you enable logging for all server daemons, take care to monitor the size of logs such as /var/adm/syslog and /var/adm/log/osmlog, as the size of these files may grow quickly.

To turn off logging:

  1. Re-edit /etc/inetd.conf to remove the debug flags.

  2. Make inetd re-read /etc/inetd.conf as shown in step 2 above.

© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004