8    Solving Network and Network Services Problems

Solving UUCP Problems section in Network Administration: Services.

Section 8.7, if using a SLIP connection

Section 8.8, if using a PPP connection

Section 8.3

Section 8.4

Section 8.5

Section 8.5.1, if using Classical IP

Section 8.5.2, if using LANE

Section 8.5.3, if using IP switching

Section 8.3

Section 8.4

Section 8.6

Section 8.3

Section 8.4

Solving NTP Problems section in Network Administration: Services.

Solving DNS Client Problems section in Network Administration: Services, if you are using DNS/BIND.

Solving NIS Client Problems section in Network Administration: Services, if you are using NIS.

Solving NFS Client Problems section in Network Administration: Services, if you are using NFS.

Section 8.3

Section 8.4

Solving Mail Problems section in Network Administration: Services.

Solving POP/IMAP Problems section in Network Administration: Services, if you are using POP or IMAP mail.

Turn on the power to your system. See the system manual for your system's startup procedure and any problem solving information.

If you are running Network Information Service (NIS) and your system hangs after the NIS daemons are started and before it mounts remote file systems, no NIS server is available to respond to the ypbind request. If you know there is an NIS server for your domain, wait until the server responds; the boot procedure will continue.

If there is a Local Area Transport (LAT) problem, the following message is displayed:

getty: cannot open "/dev/ttyxx"

See the steps for solving LAT problems in Section 8.9.

If your system is a Network File System (NFS) client and it hangs while mounting a remote file system or directory, complete the following steps:

1. Inspect the cable and connection between your system and the network.

2. Wait until all the servers listed in the /etc/fstab file are available on the network; your system will then continue booting.

3. If you want your system to continue booting even if an NFS server is down, do the following:

   1. Halt the system.

   2. Boot the system to single-user mode and run the fsck command on the local file systems.

   3. Edit the /etc/fstab file and add the bg (background) option to the server entries. See fstab(4) and mount(8) for more information.

   4. Reboot the system with the following command:

      # /sbin/reboot
      

      If the bg option is specified in the fstab file entry, the remote file system or directory is automatically mounted when the server is running and begins functioning as an NFS server.

Follow these steps to see if your network is configured:

1. If your system is new to this environment and you recently configured it for use on a network, verify that the network adapter mode is set correctly at the console level. For example, if you have a 10base2 Ethernet network and your system is configured to use 10baseT Ethernet, your system fails to see the network until you set the appropriate console variable. See the prerequisite tasks for a full installation in the Installation Guide for more information.

2. Use the rcmgr utility to display the value of the NUM_NETCONFIG entry in the /etc/rc.config file:

   # rcmgr get NUM_NETCONFIG
   

   If the value is 0, run the SysMan Menu utility to configure your network. See Section 2.3 for more information.

Verify that the network daemon (inetd) is running. Enter the following command:

# ps -e | grep inetd

If no inetd daemon is running, start it, using the following command:

# /sbin/init.d/inetd start

If a remote host's network is not reachable, the following message is displayed:

network is unreachable

Complete the following steps:

1. Ensure that the network devices are configured properly on the local host, using the netstat -i command. See Section 2.3 for information on configuring network devices.

2. Verify that the routing tables on the local host are correct, using the netstat -r command.

3. Trace the path looking at each Internet Protocol (IP) router's routing tables to find an entry for the remote host's network. Repair the incorrect IP router's routing tables. (This step requires a thorough knowledge of your topology.)

4. Verify that the local host's address-to-name translation for the remote host is correct. See the solutions for [Host known?].

5. Inspect the routers along the path to the remote host to determine whether they have security features enabled that prevent you from reaching the remote host.

If a remote host is not known, the following message is displayed:

unknown host

Complete the following steps:

1. Verify that the user is trying to reach the remote host using a valid host name.

2. Verify that the remote host is in another name domain and that the user specified the full domain name.

3. If your site uses the Domain Name System (DNS) for name-to-address translation, look in the /etc/svc.conf file to see if bind is specified as a service for the hosts database entry. If it is not, edit the file and add it. Also, verify that the DNS service has information about the remote host. See the steps for solving DNS/BIND client problems in Network Administration: Services.

4. If your site uses NIS name service for name-to-address translation, look in the /etc/svc.conf file to see if yp (NIS) is specified as a service for the hosts database entry. If it is not, edit the file and add it. Also, verify if the NIS service has information about the remote host. See the steps for solving NIS client problems in Network Administration: Services.

5. If your /etc/svc.conf file lists local as the only name-to-address translation mechanism, the /etc/hosts file does not have information on the remote host. See System Administration for more information.

If a remote host is not reachable, the following message is displayed:

host is unreachable

Complete the following steps:

1. Inspect the cabling between the local host and the network.

2. Verify that the remote host is running, using the ping command.

3. Make sure that the network devices are configured properly on the local host, using the netstat -i command. See Section 2.3 for information on configuring network devices.

4. Verify that the routing tables on the local host are correct, using the netstat -r command. Use the ping command to determine whether the IP router is reachable.

5. Verify that the local host's address-to-name translation for the remote host is correct. See the solutions for [Host known?].

6. Inspect the routers along the path to the remote host to determine whether they have security features enabled that prevent you from reaching the remote host.

If a file cannot be accessed using the rcp or rsh commands, the following message is displayed:

permission denied

Complete the following steps:

1. Verify that the user is intended to have access to the remote host. The remote host might be intentionally preventing remote access.

2. Verify that the correct host and user definitions exist in the user's .rhosts file on the remote host.

3. Verify that the /etc/hosts.equiv file is set up correctly.

4. Verify that the directory and file protection on the files to be copied or the .rhosts file on the remote system are correct.

If you are using NFS, see Network Administration: Services for NFS troubleshooting information.

Problem still exists? Report it to your service representative. See Chapter 10.

If the connection is broken, the following message is displayed:

connection timed out

Complete the following steps:

1. Test the network to determine whether the problem is on the local host, remote host, or a host on the path between the two. See Chapter 9 for more information on testing the network.

2. After you identify the host with the problem, do the following:

   1. Confirm that the network device is properly configured. Verify that the broadcast address and address mask for the local host are correct. See Section 2.3 for information on configuring network devices.

   2. Make sure the local host's /etc/hosts file has the correct IP address for the local host.

   3. Make sure the cabling from the local host to the network is intact and properly connected.

   4. If connected over a local area network (LAN), verify that the Address Resolution Protocol (ARP) entries are correct and that the system is properly connected to the LAN.

   5. If connected over a wide area network (WAN), verify that the system is properly connected to the WAN and that the modems are working properly.

Turn on the power to your system. See the system manual for your system's startup procedure and any problem solving information.

If network-related errors or warnings are displayed during boot, complete the following steps:

1. Disable IPv6 during system boot by issuing the following command:

   # rcmgr set IPV6 "no"
   

2. Reboot the system. If the problems persist, go to Section 8.3.

3. Start IPv6 by issuing the following command:

   # /usr/sbin/rcinet inet6
   

   If the problems reappear, look in the /etc/rc.config, /etc/ip6rtrd.conf, and /etc/routes files for possible errors.

Verify that the IPv6 support you want is configured in the kernel. Enter the following command:

# sysconfig -s ipv6 | grep configured

If nothing is displayed, the IPv6 option is not configured in the kernel. Reconfigure the kernel by using the doconfig command. See Section 3.5.1 for more information.

If you want to use configured tunnels, verify that the IP tunneling support is configured in the kernel. Enter the following command:

# sysconfig -s iptunnel |  grep configured

If nothing is displayed, the IPTUNNEL option is not configured in the kernel. Reconfigure the kernel by using the doconfig command. See Section 3.5.1 for more information.

Verify that IPv6 is configured to start on system boot by issuing the rcmgr get IPV6 command. If IPv6 is configured, the word yes is displayed.

If IPv6 is not configured, use the ip6_setup utility. See Section 3.6 for information on setting up an IPv6 host or router.

Go to Section 8.4.1 for IPv6 host problems or Section 8.4.2 for IPv6 router problems.

Verify that IPv6 was started by issuing the following command:

# ping ::1

If the host is unreachable message is displayed, start IPv6 by issuing the following command:

# /usr/sbin/rcinet start inet6

This creates and brings up the IPv6 interfaces, and starts the IPv6 daemons.

Verify that the nd6hostd daemon is running by issuing the following command:

# ps ax | grep nd6hostd

If the daemon is not running, verify that your system is configured as an IPv6 host by issuing the following command:

# rcmgr get ND6HOSTD

If the word yes is not displayed, run the ip6_setup utility and configure your system as an IPv6 host. Then, restart IPv6 with the following command:

# /usr/sbin/rcinet restart inet6

If the word yes is displayed, enable debugging for the nd6hostd daemon with the following command:

# rcmgr set ND6HOSTD_FLAGS "-d -l /usr/tmp/nd6hostd.log"

Then, restart IPv6.

If a remote node is not known, the following message is displayed:

unknown host

Complete the following steps:

1. Verify that the user is using a valid node name to reach the remote node.

2. Verify that the remote node is in another name domain and that the user specified the full domain name.

3. If your site uses the DNS/BIND name service for name-to-address translation, look in the /etc/svc.conf file to see if bind is specified as a service for the hosts database entry. If it is not, configure your system as a DNS/BIND client. See Network Administration: Services for more information.

   Verify that your system is running IPv4. If it is not, use the local /etc/ipnodes file for name-to-address translations.

   Also, verify that the DNS/BIND service has information about the remote node. See the steps for solving DNS/BIND client problems in Network Administration: Services.

4. If your site uses only NIS name service for name-to-address translation, you need to use another service for node names because NIS does not support IPv6 addresses.

   Edit the /etc/svc.conf file and add either bind (DNS/BIND) or local (/etc/ipnodes file) as the service for the hosts database, depending on which service has the information about the remote node.

5. If your /etc/svc.conf file lists local as the only name-to-address translation mechanism, edit the /etc/ipnodes file and verify that the node name and address are present and accurate. Make any necessary additions or corrections.

   Also, verify that there are no formatting errors in previous lines in the file. Beginning with the first entry, issue the ping command to each node to locate any formatting errors.

If an on-link node is unreachable, one of the following messages is displayed:

host is unreachable
network is unreachable
timeout

Verify that an on-link host or router, if one exists, is reachable by using the ping command. If the command fails or if there are frequently dropped packets, complete the following steps:

1. If the node is attached to a LAN, look at the datalink counters by using the netstat -I device -s command. The counters to examine and possible problems are as follows:

   • Zero blocks sent or received can indicate a network hardware failure or wiring problem.

   • High collision rates can indicate an improperly wired network or a node sending excessive message traffic.

   • Data overrun and buffer unavailable errors indicate your system is misconfigured.

2. Look at the IPv6 and ICMPv6 counters with the netstat -p ipv6 and netstat -p ipv6-icmp commands, respectively. The counters and their possible causes:

   • Packets discarded due to error or errors generated due to ICMP errors indicate another node generating invalid messages. Other counters show more specific information.

   • Allocation errors can indicate excessive message traffic, a misconfigured system, or a program that repeatedly allocates memory without freeing it.

3. Verify that IPv6 network interfaces exist, are running, and have inet6 addresses by using the ifconfig -a command. If they do not, verify that the configuration variables in the /etc/rc.config file are correct. Run the ip6_setup utility to correct any errors.

   Also, look for nd6hostd errors in the /var/adm/syslog.dated/current/daemon.log file. See Section 9.8 for more information.

   If your interface does not have a global or site-local address, contact your network administrator to verify that your local router is advertising a prefix on the link. If there is no local router, you can define a prefix by using the ifconfig command (see Section 3.7.5).

4. Contact the administrator of the on-link system and verify that the on-link system is up and running, that it is configured for IPv6 correctly, and that the address you are using is enabled on the node's interface.

5. Issue the ping command to the on-link node's IPv4 address, if IPv4 is configured on both systems. If this succeeds, verify the IPv6 configuration on both systems. If the command fails, see the steps for solving IPv4 network problems in Section 8.3.

6. Issue the ping command to other nodes on the link to determine whether the failure is confined to just one node or multiple nodes. Partial connectivity might indicate a faulty network device or cable on the link.

7. If the link is a configured tunnel, do the following:

   1. Verify the tunnel source and destination addresses by using the ifconfig -a command. Contact the administrator of the tunnel destination node and verify that your source and destination addresses match the destination and source addresses on that node.

   2. Issue the ping command to the tunnel destination address. If the command fails, see the steps for solving IPv4 network problems in Section 8.3.

If an off-link node is not reachable, one of the following messages is displayed:

host is unreachable
network is unreachable
timeout

Verify that an off-link node is reachable by issuing the ping command. If there is 100% packet loss, complete the following steps:

1. Verify connectivity between your system and an on-link router by using the ping command. If the command fails or shows frequently dropped packets, follow the steps for [On-link node reachable?]. If you do not know the address to a router, issue the following command:

   # ping -I interface ff02::2
   

2. Verify that the interface over which you are sending messages has a global or site-local unicast address enabled by using the ifconfig -a command. If it does not, contact your network administrator to verify that your local router is advertising a prefix on the link.

   If the link is a configured tunnel and the router is not advertising an address prefix, manually define one for the tunnel by using the ip6_setup utility. See Section 3.6.1 for more information.

3. Contact the remote system's administrator to verify that the system is up and running, that it is configured for IPv6, and that the IPv6 address on its interface is the same one you are using. If the address is different, look in your system's /etc/ipnodes file or have the remote system administrator verify that the DNS entry is correct.

4. Verify that there is a default route (with U and G flags set) to a router on the network by issuing the netstat -rf inet6 command. If there is not, contact the router administrator to verify that the router is advertising itself as a default router.

   Also, look at other routers to see if your messages are being directed on the wrong path.

5. Trace the path to the off-link node by using the traceroute command. See Section 9.5 and traceroute(8) for more information.

If there are frequently dropped packets, the problem might be network congestion or an intermittent routing problem. Do the following:

1. Verify connectivity between your system and an on-link router by using the ping command.

2. Trace the path to the off-link node by using the traceroute command. See Section 9.5 and traceroute(8) for more information.

If someone reports a problem reaching your node from another node, complete the following steps:

1. Verify that their node is reachable by issuing the ping command. If the command fails, follow the steps for [On-link node reachable?] or [Off-link-node reachable?], depending on the location of the node.

2. If they are using a name from the DNS database, verify that the address for your node in the DNS database matches one of the addresses configured on your system's interfaces. Use the nslookup -type=AAAA node-name command to retrieve the address from DNS and the ifconfig -a command to display addresses for your system.

3. If they are using an address defined in their local /etc/ipnodes file, compare that address with the addresses configured on your system's interfaces. Use the ifconfig -a command.

If a remote node is not configured to accept a connection from your application, the following message might be displayed:

connection refused

Contact the administrator of the remote node and ask if the correct socket-based service definitions are defined in the /etc/services and /etc/inetd.conf files. They might be missing or commented out.

Verify that the service in the local /etc/inetd.conf file has either tcp6 or udp6 in the protocol field.

Problem still exists? Report it to your service representative. See Chapter 10.

If the connection terminates abnormally or a network application appears to hang, complete the following steps:

1. Verify that there is network connectivity to the remote node by using the ping command immediately after the failure.

   If the ping command fails or shows a high rate of packet loss, follow the steps for either [On-link node reachable?] or [Off-link node reachable?], depending on the location of the remote node.

2. If your application transfers a large amount of data over the network, verify if large or fragmented messages are being handled correctly by using the ping -s 2000 nodename command.

   If the ping command fails, trace the path to the remote node with 1200-byte packets by using the traceroute nodename 1200 command. All IPv6 links must support message sizes of at least 1280 bytes. This command might show the location of the problem in the network. See Section 9.5 and traceroute(8) for more information.

3. Run the application with different client and server nodes located on different links in the network.

Verify that the ip6rtrd daemon is running by issuing the following command:

# ps ax | grep ip6rtrd

If the daemon is not running, verify that your system is configured as an IPv6 router by issuing the following command:

# rcmgr get IP6RTRD

If the word yes is not displayed, run the ip6_setup utility and configure your system as an IPv6 router. Then, restart IPv6 with the following command:

# /usr/sbin/rcinet restart inet6

If the word yes is displayed, enable debugging for the ip6rtrd daemon with the following command:

# rcmgr set IP6RTRD_FLAGS "-d -l /usr/tmp/ip6rtrd.log /etc/ip6rtrd.conf"

Then, restart IPv6.

If a remote node is not known, the following message is displayed:

unknown host

Complete the following steps:

1. Verify that the user is using a valid node name to reach the remote node.

2. Verify that the remote node is in another name domain and that the user specified the full domain name.

3. If your site uses the DNS/BIND name service for name-to-address translation, look in the /etc/svc.conf file to see if bind is specified as a service for the hosts database entry. If it is not, configure your system as a DNS/BIND client. See Network Administration: Services for more information.

   Verify that your system is running IPv4. If it is not, use the /etc/ipnodes file for name-to-address translation.

   Also, verify that the DNS/BIND service has information about the remote node. See the steps for solving DNS/BIND client problems in Network Administration: Services.

4. If your site uses only NIS name service (yp) for name-to-address translation, you need to use another service for node names as NIS does not support IPv6 addresses.

   Edit the /etc/svc.conf file and add either bind (DNS/BIND) or local (/etc/ipnodes file) as the service for the hosts database, depending on which service has the information about the remote node.

   Also, verify that there are no formatting errors in previous lines in the file. Beginning with the first entry, issue the ping command to each node to locate any formatting errors.

5. If your /etc/svc.conf file lists local as the only name-to-address translation mechanism, edit the /etc/ipnodes file and verify that the node name and address are present and accurate. Make any necessary additions or corrections.

If an on-link node is not reachable, one of the following messages is displayed:

host is unreachable
network is unreachable
timeout

Verify that an on-link host or router, if one exists, is reachable by using the ping command. If the command fails or if there are frequently dropped packets, complete the following steps:

1. If the node is attached to a LAN, look at the datalink counters by using the netstat -I device -s command. The counters to examine and possible problems are as follows:

   • Zero blocks sent or received can indicate a network hardware failure or wiring problem.

   • High collision rates can indicate an improperly wired network or a node sending excessive message traffic.

   • Data overrun and buffer unavailable errors indicate your system is misconfigured.

2. Look at the IPv6 and ICMPv6 counters with the netstat -p ipv6 and netstat -p ipv6-icmp commands, respectively. The counters to examine and possible problems are as follows:

   • Packets discarded due to error or errors generated due to ICMP errors indicate another node generating invalid messages. Other counters show more specific information.

   • Allocation errors can indicate excessive message traffic, a misconfigured system, or a program that repeatedly allocates memory without freeing it.

3. Verify that IPv6 network interfaces exist, are running, and have inet6 addresses by using the ifconfig -a command. If they do not, verify that the /etc/rc.config and /etc/ip6rtrd.conf files are correct.

   Also, look for ip6rtrd errors in the /var/adm/syslog.dated/current/daemon.log file. See Section 9.8 for more information.

   Run the ip6_setup utility to correct any errors.

4. Contact the administrator of the on-link system and verify that the on-link system is up and running, that it is configured for IPv6 correctly, and that the address you are using is enabled on the node's interface.

5. Issue the ping command to the on-link node's IPv4 address, if IPv4 is configured on both systems. If this succeeds, verify the IPv6 configuration on both systems. If the command fails, see the steps for solving IPv4 network problems in Section 8.3.

6. Issue the ping command to other nodes on the link to determine whether the failure is confined to just one node or multiple nodes. Partial connectivity might indicate a faulty network device or cable on the link.

7. If the link is a configured tunnel, do the following:

   1. Verify the tunnel source and destination addresses by using the ifconfig -a command. Contact the tunnel destination node's administrator and verify that your source and destination addresses match the destination and source addresses on that node.

   2. Issue the ping command to the tunnel destination address. If the command fails, see the steps for solving IPv4 network problems in Section 8.3.

If an off-link node is not reachable, one of the following messages is displayed:

host is unreachable
network is unreachable
timeout

Verify that an off-link node is reachable by issuing the ping command. If there is 100% packet loss, complete the following steps:

1. Verify connectivity between your system and the next router in the path to the off-link node by using the ping command. If the command fails or shows frequently dropped packets, follow the steps for [On-link node reachable?].

2. Verify that the interface over which you are sending messages has a global or site-local unicast address enabled by using the ifconfig -a command. If it does not, verify that the interface address prefixes defined in the /etc/ip6rtrd.conf file (see ip6rtrd.conf(4)) are correct. Run the ip6_setup utility to correct any prefix errors.

3. Contact the administrator of the remote system to verify that the system is up and running, that it is configured for IPv6, and that the IPv6 address on its interface is the same as the address that you are using. If the address is different, look in the hosts database.

If there are frequently dropped packets, there might be network congestion or an intermittent routing problem. Do the following:

1. Verify connectivity between your system and an on-link router by using the ping command.

2. Trace the path to the off-link node by using the traceroute command. See Section 9.5 and traceroute(8) for more information.

IPv6 hosts generate their global and site-local unicast addresses automatically using address prefixes provided by a router on the link. If an on-link node cannot autoconfigure its addresses, complete the following steps:

1. Verify that the host is reachable from your router by using the ping command and specifying the host's link-local address. If the command fails or shows a high rate of packet loss, follow the steps for [On-link node reachable?].

2. Edit the /etc/ip6rtrd.conf file and verify that the router is configured to advertise the correct prefixes and that the timers are reasonable. See Section 3.7.11 and ip6rtrd.conf(4) for more information.

If another network user reports that message transmission appears to be failing at your router, complete the following steps:

1. Obtain the source and destination addresses of the message that your router is not forwarding. Then, verify that your router can reach each node by using the ping command. If either command fails or shows a high rate of packet loss, follow the steps for [On-link node reachable?] or [Off-link node reachable?], as applicable.

2. If your router is running the RIPng protocol, verify that the IPv6 router daemon is running by issuing the following command:

   # ps ax | grep ip6rtrd
   

   If it is running, edit the /etc/ip6rtrd.conf file and verify that the RIPng protocol is enabled on each IPv6 link. If it is not, your node might not be propagating routes correctly.

3. Make sure that you are not using manual routes on some interfaces and RIPng routes on other interfaces. Manual routes defined in the /etc/routes file do not get propagated to other routers with RIPng.

If someone reports a problem reaching your node from another node, complete the following steps:

1. Verify that their node is reachable by issuing the ping command. If the command fails, follow the steps for [On-link node reachable?] or [Off-link-node reachable?], depending on the location of the node.

2. If they are using a name from the DNS database, verify that the address for your node in the DNS database matches one of the addresses configured on your system's interfaces. Use the nslookup -type=AAAA node-name command to retrieve the address from DNS and the ifconfig -a command to display addresses for your system.

3. If they are using an address defined in their local /etc/ipnodes file, compare that address with the addresses configured on your system's interfaces. Use the ifconfig -a command.

If a remote node is not configured to accept a connection from your application, the following message might be displayed:

connection refused

Contact the administrator of the remote node and ask if the correct socket-based service definitions are defined in the /etc/services and /etc/inetd.conf files. They might be missing or commented out.

Verify that the service in the local /etc/inetd.conf file has either tcp6 or udp6 in the protocol field.

Problem still exists? Report it to your service representative. See Chapter 10.

If the connection terminates abnormally or a network application appears to hang, complete the following steps:

1. Verify that there is network connectivity to the remote node by using the ping command immediately after the failure.

   If the ping command fails or shows a high rate of packet loss, follow the steps for either [On-link node reachable?] or [Off-link node reachable?], depending on the location of the remote node.

2. If your application transfers a large amount of data over the network, verify if large or fragmented messages are being handled correctly by using the ping -s 2000 nodename command.

   If the ping command fails, trace the path to the remote node with 1200-byte packets by using the traceroute nodename 1200 command. All IPv6 links must support message sizes of at least 1280 bytes. This command might show the location of the problem in the network. See Section 9.5 and traceroute(8) for more information.

3. Run the application with different client and server nodes located on different links in the network.

Verify that the ATM subsets are installed. Enter the following command:

# setld -i | grep OSFATM

The following messages are displayed:

OSFATMnnn installed ATM Commands
   (Network-Server/Communications)
OSFATMBINnnn installed ATM Kernel
   Modules (Kernel Build Environment)
OSFATMBINCOMnnn installed ATM Kernel
   Header and Common Files
   (Kernel Build Environment)
OSFATMBINOBJECTnnn installed ATM Kernel
   Objects (Kernel Software Environment)

If the OSFATM, OSFATMBIN, and OSFATMBINCOM subsets are not installed, install them by using the setld command. See the Installation Guide for information on installing the subset.

Verify that the ATM support you want is configured in the kernel. Enter the following command:

# sysconfig -q atm

If nothing is displayed, ATM is not configured in the kernel. Reconfigure the kernel with the ATM option and additional ATM options as needed. See Section 4.2.2 for a list of ATM kernel options and for information on reconfiguring the kernel.

If ATM is configured in the kernel, use the sysconfig -q command to verify that other ATM kernel options are configured. Reconfigure the kernel with additional options as needed.

Go to Section 8.5.1 for Classical IP, go to Section 8.5.2 for LAN Emulation, or go to Section 8.5.3 for IP switching.

Verify that the driver is configured by using the atmconfig drvlist command. If the driver is configured, information similar to the following is displayed:

Name: lta0      Type: STS-3      State: UP
Driver ID: 1   ESIs: 8   PPAs: 9  VCs: 6

If an entry for the driver does not exist, use the genvmunix kernel to reboot the system and run the doconfig utility to build a kernel with the required driver.

If the driver state is not UP, run the atmsetup utility for the ATM service you want. See Section 4.3.2.4, Section 4.3.3.3, and Section 4.3.4.2 for information on configuring the driver for Classical IP (CLIP), LAN emulation (LANE), and IP switching, respectively.

Verify that signaling is configured. Enter the following command:

# atmsig status driver=driver_name

If the UNI version number is not displayed or the ILMI state is Unknown, run the atmsetup utility and configure signaling. See Section 4.3.2.4 for information.

Verify that the CLIP lis interfaces are created. Enter the following command:

# atmarp -h

If a lis interface is created, the status of all created LISs and data indicating whether the host is an ARP client or ARP server is displayed.

If no LISs are created, run the atmsetup utility and configure CLIP. See Section 4.3.2.4 for more information.

Verify that a lis interface is configured. Enter the following command:

# ifconfig lisx

If a lis interface is configured, information similar to the following is displayed:

lis0: flags=c23<UP,BROADCAST,NOTRAILERS,MULTICAST,SIMPLEX>
    inet 10.140.120.52 netmask ffffff00 broadcast 10.140.120.255
   ipmtu 1500

If a lis interface is not configured, run the netconfig utility to configure one or use the Interfaces application from the SysMan Menu. See Section 4.3.2.5 for more information.

If a remote host is not known, the following message is displayed:

unknown host

Complete the following steps:

1. Verify that the user is using a valid host name to reach the remote host.

2. Verify that the remote host is in another name domain and that the user specified the full domain name.

3. If your site uses DNS for name-to-address translation, look in the /etc/svc.conf file to see if bind is specified as a service for the hosts database entry. If it is not, edit the file and add it.

   Also, verify that DNS has information about the remote host. See the steps for solving DNS/BIND client problems in Network Administration: Services.

4. If your site uses NIS name service for name-to-address translation, look in the /etc/svc.conf file to see if nis is specified as a service for the hosts database entry. If it is not, edit the file and add it.

   Also, verify that the NIS service has information about the remote host. See the steps for solving NIS client problems in Network Administration: Services.

5. If your /etc/svc.conf file lists local as the only name-to-address translation mechanism, the /etc/hosts file does not have information on the remote host. See System Administration for more information.

If a remote host is not reachable, the following message is displayed:

host is unreachable

Complete the following steps:

1. Verify that the cabling between the local host and the switch is properly installed and undamaged.

2. Verify that there is network connectivity to the IP controller on the switch by using the ping command. If the command fails, it might be because the ifconfig command parameters are wrong, or the IP controller is down or has an interface problem. Contact the switch administrator.

3. Verify that there is network connectivity to the target remote host by using the ping command. If the command fails, use the traceroute command to verify the route to the remote host.

Problem still exists? Report it to your service representative. See Chapter 10.

If the connection terminates abnormally, complete the following steps:

1. Test the network to determine whether the problem is on the local host, remote host, or a host on the path between the two. See Section 8.3.

2. After you identify the host with the problem, do the following:

   1. Confirm that the network device is properly configured. Verify that the broadcast address and address mask for the local host are correct. See Section 2.3 for information on configuring network devices.

   2. Make sure the local host's hosts database has the correct IP addresses.

   3. Make sure the cabling from the local host to the network is intact and properly connected.

   4. If connected over a LAN, verify that the ARP entries are correct and that the system is properly connected to the LAN.

Verify that signaling is configured. Enter the following command:

# atmsig status driver=driver_name

If no User-Network Interface (UNI) version number is displayed or the Integrated Layer Management Interface (ILMI) state is Unknown, run the atmsetup utility and configure signaling. See Section 4.3.3.3 for information.

Verify that an elan interface is created. Enter the following command:

# atmelan show

If an elan interface is created, information similar to the following is displayed:

 
.
.
.
control state: S_OPERATIONAL
 
.
.
.

If the control state is not S_OPERATIONAL, do the following:

1. Increase the message logging level for the lane subsystem. See Section 4.4.6 for more information.

2. Verify that the UNI version on the switch matches the UNI version on your system.

3. Verify that the LAN Emulation Server (LES) on the switch is configured correctly.

Verify that an elan interface is configured. Enter the following command:

# ifconfig elanx

If an elan interface is configured, information similar to the following is displayed:

elan0: flags=c23<UP,BROADCAST,NOTRAILERS,MULTICAST,SIMPLEX>
     inet 10.140.120.52 netmask ffffff00 broadcast 10.140.120.255
   ipmtu 1500

If an elan interface is not configured, run the netconfig utility to configure one or use the Interfaces application from the SysMan Menu. See Section 4.3.3.4 for more information.

If a remote host is not known, the following message is displayed:

unknown host

Complete the following steps:

1. Verify that the user is using a valid host name to reach the remote host.

2. Verify that the remote host is in another name domain and that the user specified the full domain name.

3. If your site uses DNS for name-to-address translation, look in the /etc/svc.conf file to see if bind is specified as a service for the hosts database entry. If it is not, edit the file and add it.

   Also, verify that DNS has information about the remote host. See the steps for solving DNS/BIND client problems in Network Administration: Services.

4. If your site uses NIS name service for name-to-address translation, look in the /etc/svc.conf file to see if nis is specified as a service for the hosts database entry. If it is not, edit the file and add it.

   Also, verify that the NIS service has information about the remote host. See the steps for solving NIS client problems in Network Administration: Services.

5. If your /etc/svc.conf file lists local as the only name-to-address translation mechanism, the /etc/hosts file does not have information on the remote host. See System Administration for more information.

If a remote host is not reachable, the following message is displayed:

host is unreachable

Complete the following steps:

1. Verify that the cabling between the local host and the switch is properly installed and undamaged.

2. Verify that the addresses on the link are correct by using the ifconfig elanx command.

3. Verify that there is network connectivity to the target remote host by using the ping command. If the command fails, use the traceroute command to verify the route to the remote host.

Problem still exists? Report it to your service representative. See Chapter 10.

If the connection terminates abnormally, complete the following steps:

1. Test the network to determine whether the problem is on the local host, remote host, or a host on the path between the two. See Section 8.3.

2. After you identify the host with the problem, do the following:

   1. Confirm that the network device is properly configured. Verify that the broadcast address and address mask for the local host are correct. See Section 2.3 for information on configuring network devices.

   2. Make sure the local host's hosts database has the correct IP addresses.

   3. Make sure the cabling from the local host to the network is intact and properly connected.

   4. If connected over a LAN, verify that the ARP entries are correct and that the system is properly connected to the LAN.

Verify that an IP switching ips interface is created. Enter the following command:

# atmifmp showips

If an ips interface is created, information similar to the following is displayed for each created ips interface:

ips0:
         Attached to driver lta0
         Default (SNAP) VC = 32
         IP Traffic VC = 1850 (Unused - peer does
                not support Flow Type 0)
         Min Tx VC = 1
         Max Tx VC = 2048
         Min Rx VC = 1
         Max Rx VC = 2048
         Driver Min Tx VC = 1
         Driver Max Tx VC = 2048
         Driver Min Rx VC = 1
         Driver Max Rx VC = 2048
         Peer does not support Flow Type 0

This example shows that the ips0 interface was created and is attached to driver lta0.

If no ips interfaces are found, create one or more ips interfaces. See Section 4.3.4 for more information.

Verify that an ips interface is configured. Enter the following command:

# ifconfig ipsx

If an ips interface is configured, information similar to the following is displayed:

ips0: flags=4d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
   inet 16.142.128.129 --> 16.142.128.130 netmask fffffffc  ipmtu 1500

The example shows that the interface is up and running and that addresses are configured for each end of the point-to-point link.

If an ips interface is not configured, run the netconfig utility to configure one or use the Interfaces application from the SysMan Menu. See Section 4.3.4.3 for more information.

If a remote host is not known, the following message is displayed:

unknown host

Complete the following steps:

1. Verify that the user is using a valid host name to reach the remote host.

2. Verify that the remote host is in another name domain and that the user specified the full domain name.

3. If your site uses the DNS for name-to-address translation, look in the /etc/svc.conf file to see if bind is specified as a service for the hosts database entry. If it is not, edit the file and add it.

   Also, verify that DNS has information about the remote host. See the steps for solving DNS/BIND client problems in Network Administration: Services.

4. If your site uses NIS name service for name-to-address translation, look in the /etc/svc.conf file to see if nis is specified as a service for the hosts database entry. If it is not, edit the file and add it.

   Also, verify that the NIS service has information about the remote host. See the steps for solving NIS client problems in Network Administration: Services.

5. If your /etc/svc.conf file lists local as the only name-to-address translation mechanism, the /etc/hosts file does not have information on the remote host. See System Administration for more information.

If a remote host is not reachable, the following message is displayed:

host is unreachable

Complete the following steps:

1. Verify that the addresses on the point-to-point link to the switch are correct by using the ifconfig ipsx command.

2. Verify the connection to the IP controller on the switch by using the ping command. If the command fails, the local host's ifconfig command parameters might be incorrect. On the switch, the problem might be that the IP controller is down or has an interface problem. Contact the switch administrator.

3. Verify that there is an ips route to the remote host's subnet by using the netstat -r command.

If the ping command fails, complete the following steps:

1. Verify that the cabling between the local host and the switch is properly installed and undamaged.

2. Verify that the default Subnetwork Attachment Point (SNAP) virtual circuit (VC) specified on the local host matches the default SNAP VC on the switch.

3. Contact the administrator of the remote system and verify that the remote system is up and running and that it is configured correctly for IP switching.

4. Verify the route to the remote host by using the traceroute command. If the first hop in the output shows the default network interface and not the IP controller, add a static route to the remote subnet through the IP controller to your routing table. Use the netstat -r command to verify the change.

   If the route reaches the IP controller but goes no further, contact the administrator of the remote system to verify that the system is configured correctly and that the routing tables are correct.

Problem still exists? Report it to your service representative. See Chapter 10.

If the connection terminates abnormally, complete the following steps:

1. Test the network to determine whether the problem is on the local host, remote host, or a host on the path between the two. See Section 8.3.

2. After you identify the host with the problem, do the following:

   1. Confirm that the network device is properly configured. Verify that the broadcast address and address mask for the local host are correct. See Section 2.3 for information on configuring network devices.

   2. Make sure the hosts database on the local host has the correct IP addresses.

   3. Make sure the cabling from the local host to the network is intact and properly connected.

Verify that the Additional Networking Services subset is installed. Enter the following command:

# setld -i | grep OSFINET

If the subset is installed, the following message is displayed:

OSFINETnnn installed Additional Networking Services
  (Network-Server/Communications)

If the subset is not installed, install it by using the setld command. See the Installation Guide for more information on installing the subset.

Complete the following steps to verify that Dynamic Host Configuration Protocol (DHCP) has been configured on both server and client:

1. Use the rcmgr utility to display the value of the JOIND entry in the /etc/rc.config.common file on the DHCP server:

   # rcmgr get JOIND
   

   If nothing is returned, run the SysMan Menu utility to configure your DHCP server. See Section 5.3.7 for more information.

2. Use the rcmgr utility to display the value of the IFCONFIG_n entry in the /etc/rc.config file on the DHCP client. For example:

   # rcmgr get IFCONFIG_0
   

   A value similar to the following is displayed:

   DYNAMIC netmask n.n.n.n
   

   If a similar value is not returned, run the SysMan Menu utility to configure your DHCP client. See Section 2.3 for more information.

Verify that the DHCP server is running and reachable, using the ping command.

Verify that the DHCP daemon (joind) is running on the server. Enter the following command:

# ps -e | grep joind

Alternatively, you can use the SysMan Menu utility to view the status of the DHCP daemon. You can skip directly to the status dialog box by entering the following command:

# /usr/sbin/sysman dmnstatus

If the DHCP daemon is not running, start it by entering the following command:

# /usr/sbin/joind

Problem still exists? Report it to your service representative. See Chapter 10.

If a DHCP client has problems obtaining DHCP information from the server, do the following:

1. Verify the Media Access Control (MAC) address you entered for the client. Users of Microsoft clients specifically must see Section 5.3.5, which explains how these clients modify their MAC addresses before sending them to the DHCP server.

2. Run the joind daemon with the debugging flag by doing the following:

   1. Stop the joind daemon with the kill -HUP command.

      Caution

      Never use the kill -9 command to stop the DHCP server daemon; it can corrupt your database files.

   2. Restart the joind daemon with the debug flag as follows:

      # /usr/sbin/joind -d4
      

      If you are running joind from the /etc/inetd.conf file, do the following:

      1. Edit the /etc/inetd.conf file and add the -d4 flag.

      2. Stop the joind daemon with the kill -HUP command.

      3. Stop the inetd daemon with the inetd -h command. This forces the inetd daemon to reread the /etc/inetd.conf file.

      Alternatively, you can run the SysMan Menu utility to configure your DHCP server with the debug option. See Section 5.3.7 for more information.

3. Review the /var/join/log file for information about the cause of any DHCP client problems.

The following example shows a /var/join/log file message that indicates a DHCP discover message arrived at the server system, but the IP subnetwork address range is not defined:

DHCPDISCOVER from HW address 08:00:2b:96:79:b6 :
 network not administered by server

This problem can also occur if an address range is defined, but the /etc/join/netmasks file is missing the subnetwork mask definition for this IP network. In this case, edit the netmasks file, add an entry for the subnetwork, and restart the DHCP server, /usr/sbin/joind.

Verify that the correct number of Serial Line Internet Protocol (SLIP) pseudodevices are supported in the kernel by using the netstat -in command. If SLIP is supported, information similar to the following is displayed for each interface:

sl0* 296 <Link> 0 0 0 0 0

The sl prefix indicates that SLIP is supported on the system. In this example there is one SLIP interface.

If you need additional SLIP interfaces, specify them by adding the nslip=x attribute under the net: subsystem in the /etc/sysconfigtab file. See System Administration for information on adding more SLIP interfaces.

On systems with 24 MB of memory, SLIP is not configured into the kernel. To add SLIP into the kernel, edit the system configuration file (/usr/sys/confhostname) and add the following entry:

options SL

See System Administration for more information.

Configure the network hardware as follows:

• Verify that you are using the correct hardware. See Section 6.1.2.1 for more information.

• Make sure the modem is configured as follows:

  • Use 8-bit characters with no parity.

  • Software flow control (XON/XOFF) is disabled.

  • For dial-in systems, follow the guidelines in Section 6.1.3.1.

  • For dial-out systems, follow the guidelines in Section 6.1.3.2.

If a remote system cannot dial in to your system successfully, complete the following steps:

1. Check the /usr/spool/locks directory for LCK..ttynn lock files. If any exist for the terminal device you are using for SLIP, remove them.

   When you establish a connection over a terminal device, the system generates a lock file to prevent the connection from being disrupted by another application. If the connection terminates abnormally, the lock file might persist, preventing you from establishing new connections.

2. Edit the /etc/slhosts file and include the debug option in the login entry for the host that cannot log in. See slhosts(4) for more information.

3. Instruct the remote user to dial in again.

4. Look in the /var/adm/syslog.dated/current/daemon.log file for information on SLIP problems on the dial-in system. See Section 9.8 for more information.

If you cannot dial out to the remote system, complete the following steps:

1. Check the /usr/spool/locks directory for LCK..ttynn lock files. If any exist for the terminal device you are using for SLIP, remove them.

   When you establish a connection over a terminal device, the system generates a lock file to prevent the connection from being disrupted by another application. If the connection terminates abnormally, the lock file might persist, preventing you from establishing new connections.

2. Verify that the modem is working correctly.

   Edit the /etc/acucap file and include the db option in your modem's entry. This option displays useful information for debugging a new entry. See acucap(4) for more information.

3. Verify SLIP setup. Do the following:

   1. Edit the startslip dial-out script file and specify the debug subcommand and a debug log file.

   2. Try to dial out again.

   3. Look in the debug log file for information about SLIP dial-out problems.

If you cannot communicate with the remote host and none of the debug messages shows an error, complete the following steps:

1. Verify that the IP addresses and netmasks are correct on both ends of the connection.

2. Examine the following SLIP configuration parameters at each end of the connection:

   • Internet Control Message Protocol (ICMP) traffic suppression -- If enabled at either end of the connection, the ping command will fail.

   • TCP header compression -- If enabled at one end, TCP header compression must be enabled or autoenabled on the other end.

If you can communicate with the remote host but not the network connected to the remote host, complete the following steps:

1. If your local system is using the remote system as a gateway system, issue the netstat -rn command on the local system to verify that the remote SLIP address is the default gateway.

2. On the gateway system (remote system), issue the iprsetup -d command to see if the ipforwarding and ipgateway variables are on. If the variables are off, use the iprsetup -s command to turn them on.

3. On the gateway system, verify that the gated daemon is running. See gated(8) for more information.

Problem still exists? Report it to your service representative. See Chapter 10.

If the startslip command does not complete successfully, complete the following steps:

1. Build your kernel with the PACKETFILTER option.

2. Use the tcpdump command to examine packets sent and received through the SLIP interface. See tcpdump(8) for more information.

Verify that the Point-to-Point Protocol (PPP) is supported in the kernel by using the sysconfig -s | fgrep ppp command. If PPP is supported, information similar to the following is displayed:

ppp: loaded and configured

If PPP is not supported, add options PPP into the /sys/conf/MACHINE system configuration file and rebuild the kernel.

Configure the network hardware as follows:

• Direct connections to remote host -- Use a null modem or modem eliminator cable to connect your system to the remote host.

• Phone line connection to remote host -- Use a cable to connect your system to a modem and another cable to connect your modem to a phone line. The modem you use must be compatible with the modem at the remote host. Make sure the modem is configured as follows:

  • Use 8-bit characters with no parity.

  • All flow control is disabled.

If you are logging messages to the console and the link comes up successfully, the following messages are displayed on the console:

Local IP address: xx.xx.xx.xx
Remote IP address: yy.yy.yy.yy

If the link does not come up, look at the following:

• Check the /usr/spool/locks directory for LCK..ttynn lock files. If any exist for the terminal device you are using for PPP, remove them.

  When you establish a connection over a terminal device, the system generates a lock file to prevent the connection from being disrupted by another application. If the connection terminates abnormally, the lock file might persist, preventing you from establishing new connections.

• Verify that the serial connection is set up successfully. Use the chat -v command to log the characters the chat program sends and receives.

• Verify that the pppd daemon starts on the remote system. Use the chat -v command to log the characters the chat program sends and receives.

• Examine the PPP negotiation between the two peers. Use the pppd command with the debug option to log the contents of all control packets sent and received.

Problem still exists? Report it to your service representative. See Chapter 10.

If network applications do not work successfully, this might indicate a problem with assigning IP addresses or routing. Do the following:

1. Use the netstat -i, netstat -r, ping, and traceroute commands to diagnose the problem.

2. If you can communicate with the peer machine but not with machines beyond that in the network, there is a routing problem. For instances where the local machine is connected to the Internet through the peer, do the following:

   1. Assign the local machine an IP address on the same subnet as the remote machine.

   2. Run the local pppd daemon with the defaultroute option.

   3. Run the remote pppd daemon with the proxyarp option.

   4. On the peer system (remote system), issue the iprsetup -d command to determine if the ipforwarding and ipgateway variables are on. If these variables are off, use the iprsetup -s command to turn them on.

Verify that the Local Area Transport subset is installed. Enter the following command:

# setld -i | grep OSFLAT

If the subset is installed, the following message is displayed:

OSFLATnnn installed Local Area Transport (LAT)
  (General Applications)

If the subset is not installed, install it by using the setld command. See the Installation Guide for information on installing the subset.

Verify that Local Area Transport is configured in the kernel. Enter the following command:

# sysconfig -q lat

If no information is displayed, LAT is not configured in the kernel. Reconfigure the kernel with the LAT option. See System Administration for information on reconfiguring the kernel.

Use the rcmgr utility to display the value of the LAT_SETUP entry in the /etc/rc.config file:

# rcmgr get LAT_SETUP

If 0 is returned, run the latsetup utility. See Section 7.3.1 for more information.

If the latsetup utility fails while creating new LAT ttys, verify that the /usr/sbin directory is included in the search path. Enter the following command:

# echo $PATH

If it is not, include it in your PATH environment variable. Then, create new LAT ttys using the latsetup command.

Verify that LAT has been started. Enter the following command:

# latcp -d

If LAT is running, the following line is displayed:

LAT Protocol is active

If LAT was not started, start it. Enter the following command:

# latcp -s

If LAT starts and messages are continually displayed on the system console, look for the following messages and perform the required steps:

Message 1

getty: cannot open "/dev/lat/xx".
errno: 2

This means a LAT terminal device file (tty) does not exist and the /etc/inittab file contains an entry for this file. The latsetup utility will also report that no LAT entries are available. Do the following:

1. Edit the /etc/inittab file and remove the LAT getty entries.

2. If LAT terminal devices are required, create the LAT terminal device files and corresponding entries in the /etc/inittab file by using the latsetup command. See latsetup(8) for information.

Message 2

getty: cannot open "/dev/lat/xx".
errno: 19

This means the kernel was not configured with the LAT option and the /etc/inittab file contains at least one LAT getty entry. Do either of the following:

• Configure LAT into the kernel. See System Administration for information on configuring LAT into the kernel.

• Remove the LAT getty entries from the /etc/inittab file, either manually or by using the latsetup command.

Message 3

INIT: Command is respawning too rapidly.

The following meanings are possible:

• You are using an optional service name, such as lattelnet, and it is incorrectly defined. Do the following:

  1. Verify that the optional service name defined by the latcp -A command is correct by using the latcp -d command.

  2. Edit the /etc/inittab file and verify that a LAT entry has the optional service name specified correctly.

• An attempt was made to use a nonexistent LAT terminal device (tty). Do the following:

  1. Edit the /etc/inittab file and remove the entry with the nonexistent terminal device name.

  2. If LAT terminal devices are required, create the LAT terminal device files and corresponding entries in the /etc/inittab file by using the latsetup command. See latsetup(8) for more information.

If the user cannot connect to or display a service from a terminal server via LAT, complete the following steps on the system:

1. Verify that the service name is correct by using the latcp -d command. If the service name is incorrect, delete the service with the incorrect name. Enter the following command:

   # latcp -D -aservice_name
   

   Then, add a service with the correct name. Enter the following command:

   # latcp -A -aservice_name
   

   See latcp(8) for more information.

2. Display the group codes for the service to which the user is attempting to connect, using the latcp -d command. Check if any group code matches a group displayed by using the show port command at the terminal server. If no group code matches, do either of the following:

   • Add at least one group displayed by the port to the service. Enter the following command:

     # latcp -glist -aservice_name
     

   • Change the port characteristics at the terminal server by adding a group that matches the service.

   See latcp(8) for more information.

3. Check if LAT is started on the system. If it is not, start it. Enter the following command:

   # latcp -s
   

4. If the problem persists, restart LAT. Enter the following command:

   # latcp -s
   

If problems occur when using an optional service, complete the following steps:

1. Verify that the service was added as an optional service. Enter the following command:

   # latcp -d
   

   Look for the following line:

   Service name: name (Optional)
   

   If Optional is not displayed, the optional service was not defined with the -o option. Delete the service. Enter the following command:

   # latcp -D -aservice_name
   

   Then, add the service with the correct name and the -o option. Enter the following command:

   # latcp -A -aservice_name -o
   

   See latcp(8) for more information.

2. Verify that the optional service name matches the name defined in the /etc/inittab file. If it does not, do either of the following:

   • Edit the /etc/inittab file and specify the optional service name.

   • Delete the service. Enter the following command:

     # latcp -D -aservice_name
     

     Then, add the service with the correct name and the -o option. Enter the following command:

     # latcp -A -aservice_name -o
     

   See latcp(8) for more information.

If the user cannot connect to a host using LAT, the following messages are displayed:

Connection
to node-name not established.
Service in use.

The /etc/inittab file does not contain a sufficient number of getty entries. Create more LAT terminal devices (ttys) and add their corresponding entries into the /etc/inittab file by using the latsetup command. Then, restart LAT to advertise the available services. Enter the following command:

# latcp -s

See Section 7.3.1 for information.

If a host-initiated connection fails, verify that the port, host, and service names are specified correctly. Enter the following command:

# latcp -d -P -L

If these names are not specified correctly, delete the application ports with the incorrect names. Enter the following command:

# latcp -D -pport_name

Then, add the application ports, using correct spelling. To create the application port by specifying the remote port to which the LAT terminal device is to be mapped, use the following command:

# latcp -A -plocal_port -Hnode -Rrem_port

Or, to create the application port by specifying the remote service name to which the LAT terminal device is to be mapped, use the following command:

# latcp -A -plocal_port -Hnode -Vsvc_name

See latcp(8) for information.

Note

When you delete an application port for a LAT printer, any print operations that are currently executing continue until the printer buffer is empty. The print job might not be complete.

If you print a file to a printer attached to a LAT application port, the printer is online, and no printing occurs, look at the status of the print queue. Enter the following command:

# lpc status

The following line might be displayed:

waiting for printer to become ready (offline ?)

If this line is displayed, verify that LAT has been started. Enter the following command:

# latcp -d

If LAT has not been started, start it. Enter the following command:

# latcp -s

If problems are encountered with the LAT/Telnet gateway, look in the /var/adm/syslog.dated/current/daemon.log file for error messages. Use the error messages to diagnose the problem. See Section 9.8 for more information on viewing the daemon.log file.

The lattelnet utility uses the syslog message priority of LOG_INFO. For example, if you edit a LAT terminal entry in the /etc/inittab file, reassign it to lattelnet while a getty process is still active for the terminal, and a user tries to connect to LAT/Telnet, the connection will fail. The following error message is posted in the daemon.log file:

No such file or directory

Terminate the getty process for the terminal port.

Problem still exists? Report it to your service representative. See Chapter 10.

If the LAT connection terminates abnormally, complete the following steps:

1. Examine the LAT terminal device (ttys) files for duplicate minor numbers. Enter the following command:

   # ls -l /dev/lat/*
   

   If any exist, remove the duplicate device files, leaving the original file.

2. Look in the /etc/inittab file for duplicate LAT entries. Remove the duplicate entries, leaving the original entry.