Diagnostic Flowcharts

Series 800: Self-test fail; Ring Op; Signal Detect. During normal operation when the adapter is connected in an operational FDDI ring, the self-test should be off and the other LEDs should be glowing (Dual Attach FDDI has two signal detect LEDs). During power up or while using fddiinit, self-test will turn on briefly and the Ring Op will turn off, then self-test will turn off and Ring Op will turn on. If signal detect is off, the cables are not connected properly or the card failed completely. If Ring Op is off, either the card has not downloaded properly, or the FDDI ring is not operating. Go to B.

Verify: MIC connectors solidly connected. Without powering down the system, make sure the MIC connectors on your fiber-optics cable match the keyed connectors on the adapter and concentrator (or wall plug) and are solidly connected. Go to C.

Verify: Connection to concentrator "M" port and concentrator is UP. If using a concentrator, make sure that your FDDI cable is fully connected to the concentrator M port and that the concentrator state is UP. Follow the instructions in your concentrator manual to check the concentrator state.Go to D.

Execute: fddinet <dev file>. Execute fddinet on the device file of your FDDI adapter to display all the active stations on the FDDI ring. For example, if /dev/lan1 is the device file corresponding to your FDDI adapter, enter:

fddinet /dev/lan1

If the MAC address of the destination station is not listed, it is not attached to the FDDI network. If so, inform your network administrator about the problem with the destination station.

If an error message is displayed on the screen instead of the logical ring map, proceed to Flowchart 2. For detailed information on the fddinet command, refer to the manpage. Go to E.

Problem solved? Check that you are reconnected to the FDDI network and can communicate with a remote host by executing the ping diagnostic or one of the other verification tools described in "Verifying the Installation." If so, stop. If this is not the case, proceed to Flowchart 2.

Execute: lanscan. Enter the lanscan command to display information about LAN adapters that are successfully bound to the system. For example, enter /etc/lanscan. For more information, see the lanscan manpage. Go to B.

Is your interface displayed? lanscan shows information about every LAN adapter in the system backplane. The Hardware Path of one of the entries should correspond to your FDDI adapter. If the FDDI interface is displayed, go to C; if not, go to F.

Series 800: For example, hardware path 8 corresponds to slot 2 HP-PB bus.

Hardware up? The hardware state is operational if up is displayed for the FDDI adapter under the Hardware State heading. If so, go to D. If it is not, go to Flowchart 3.

Execute: fddistat <dev file>. Execute fddistat on the device file you wish to test. For example, if /dev/lan1 is the device file corresponding to your FDDI adapter, enter fddistat /dev/lan1. Go to E.

RMT: Ring_Op and CF state: Wrap_S? If the fddistat screen display indicates that the ring is operational, Ring_Op, and the line state of the station connection is WRAP_S, proceed to Flowchart 4. If not, proceed to Flowchart 3.

Is your system a Series 800 or Integrated FDDI? This version of HP FDDI/9000 supports only Series 800 systems; go to step G if your system is a Series 800.

Run ioscan. ioscan will scan the system hardware and list the results. If you execute ioscan -f, output similar to the following will be displayed:

Is driver in kernel? If yes, go to J. If no, the driver has not been generated into the kernel and the ioscan -f output will look like the following. Go to I.

Regen kernel with driver. See your system's System Administration Tasks manual for instructions on how to create a new kernel. Then go to L.

Is device adapter displayed? If the device adapter is broken, no entry for the hardware path in which the adapter is inserted will be displayed. Go to L.

Check hardware. Verify that the network adapter is seated correctly and that it is operational. Go to L.

Problem fixed? If you have found and corrected the FDDI adapter problem, stop. If not, start again with Flowchart 2. If the problem still exists after two iterations, call your HP representative.

Execute: fddiinit <dev file>. Reset the adapter and download the adapter firmware by executing fddiinit. For example, if /dev/lan1 is the device file corresponding to your FDDI adapter, enter /usr/sbin/fddiinit /dev/lan1. For Integrated FDDI Model 735, use lan0; for Integrated FDDI Model 755, use lan1.

Error messages? If fddiinit is not successful, and an error message appears, proceed to the appropriate error message (C or E). If there are no messages, go to Flowchart 4.

Can't open /dev file. If this message is displayed, no device file exists. Go to D.

Make /dev entries using mknod command. Create a new device file using the HP-UX mknod command for Models 735 and 755, or the mksf or mknod commands for Series 800. Start over with Flowchart 1.

Self-test failed. If this message is displayed, the hardware adapter may not be operational.

Execute diagnostic (self-test). Run the self-test of the FDDI hardware diagnostics to ensure that the adapter is good.

Self test failed? If the test did not fail, the problem may be that you are not connected to the FDDI network. Go to H. If the test failed, call your HP representative for help.

Execute diagnostic (external loopback). Execute the external loopback test of the hardware diagnostics to verify network connectivity.

External loopback failed? If the diagnostic is successful, proceed to Flowchart 4. If not, return to Flowchart 1 to recheck your FDDI hardware connections.

Execute: ifconfig <interface>. Execute ifconfig without the up parameter on the interface you want to test, to check the flag setting for the up parameter. For example, to check FDDI interface lan1, type:

/usr/sbin/ifconfig lan1

Is ifconfig up? Check the results of the ifconfig command to see if the interface is up. If it is, go to G. If not, go to C.

Execute: ifconfig <interface> <IP address> up. Check to see if ifconfig is up. If not, execute ifconfig on the interface you want to test. For example, to check FDDI interface lan1, enter:

/usr/sbin/ifconfig lan1 ip_address up

Type ifconfig <interface> again to see if the interface is up, then go to D.

ifconfig successful? ifconfig is successful if the output shows the correct Internet address and the flags: <UP, BROADCAST, ROUTE, NOTRAILERS, RUNNING>. Note: Make sure the UP flag is displayed. Also, ROUTE may or may not be present. If yes, go to G. If not, go to E.

Any error message returned? If ifconfig is not successful, and an error message appears, go to Flowchart 5. Flowchart 5 shows common error messages and what to do for each. If no error messages appear, go to F.

Correct ifconfig flag settings. If ifconfig returns an incorrect flag setting, re-execute the command with the proper setting. Go to Flowchart 6.

Check configuration in SAM. Check that the FDDI in SAM is correct. See chapter 3 for the configuration steps.

Is SAM configuration correct? If yes, the problem is outside your domain. If not, correct the configuration in SAM and start over with Flowchart 1.

/usr/sbin/ifconfig not found. The command has been relocated on the system or deleted. Go to E.

Bad system call; core dumped. Networking is not configured into the HP-UX kernel. Go to F.

No such interface name. The interface name passed to ifconfig does not exist on the system. Check spelling and names of interfaces on the system using netstat -i.

If you have more than one FDDI adapter, make sure the number of FDDI adapters has been configured into the kernel and that an ifconfig command has been executed for each. Go to G.

Any other error message. If you received an error message not listed on this flowchart, interpret the message and take the appropriate action. See "Contacting Your HP Representative" and call HP.

Restore /usr/sbin/ifconfig from tape and reconfigure kernel. You can restore ifconfig from the last good backup tape or your install/update tape. Go to H.

Reconfigure HP-UX kernel to include HP FDDI/9000 software. See the Installing and AdministeringLAN/9000 manual for information on how to create a new kernel. Go to Flowchart 2.

More than 1 FDDI adapter installed? If you installed more than one FDDI adapter, go to Flowchart 10. If not, go to I.

Problem resolved? If so, stop. If not, re-install the entire HP FDDI/9000 software product. Start again with Flowchart 2, as necessary.

Find correct interface name. Using the correct interface name, start again with Flowchart 2.

Reinstall HP FDDI/9000 software. Re-install the entire HP FDDI/9000 software product. If necessary, start again with Flowchart 2.

Execute: ping to remote host. Using ping(1M), send a message to the remote host you are having problems connecting to. For example:

/usr/sbin/ping bunny

ping successful? If packets are being returned, your system has network level connectivity to the remote host. Note what percentage of the total packets are lost, if any. Losing ten percent or more may indicate the network or remote host is extremely busy. Also note the round-trip transmission times. Periodically high transmission times may indicate that the network or remote host is extremely busy. Consistently high transmission times may indicate the local host is extremely busy. Go to Flowchart 8.

Network unreachable? If so, check the status of the local FDDI interface first. Go to D. If network is reachable, go to E.

Local FDDI interface up? If yes, call HP. If no, go to F.

Command hangs? If a message is not returned after executing ping, go to Flowchart 7.

Configure interface up. If you find the local interface is not up, execute ifconfig with the appropriate flags set. Start again with Flowchart 6.

Unknown host? If you received an unknown host error, go to H. If not, go to I.

Correct BIND, YP or /etc/hosts configuration. Add the missing host name and start again with Flowchart 6.

No route to host? If you received a "No route to host" error, go to J; otherwise, see "Contacting Your HP Representative" and call HP.

Add route table entry. Using /usr/sbin/route, add a route table entry for that host.

Host entry in ARP cache? Using arp, check that an entry exists for the remote host in your system's ARP cache. For example: /usr/sbin/arp bunny

If the host entry is not in the ARP cache, go to B; otherwise, go to F.

Remote host up? If yes, go to C. If no, the remote host has not broadcast an ARP message, and that likely is why there is no entry in the ARP cache. Go to E.

FDDI adapter okay? If yes, call HP. If no, use the FDDI hardware diagnostics to ensure the FDDI adapter is operational. go to D.

Replace or reset FDDI adapter. When the FDDI adapter is operational, use fddiinit(1M) to reset. Go to Flowchart 3.

Bring-up remote host. Have the node manager of the remote host bring that system up. Go to Flowchart 6.

Entry complete? If yes, go to H. If not, perhaps there is an ARP cache entry, but it is wrong or not complete. Go to G.

Use arp to complete entry. Using arp, enter the correct Station Address. For more information, refer to the arp(1M) manual page. Go to Flowchart 6.

ping local host. Using ping, do an internal loopback on your own system. In other words, ping your own system.

ping successful? If the internal loopback is successful, your system is operating properly to the Network Layer (OSI Layer 3). In addition, you know an ARP cache entry for the remote host exists on your system. If this is true, the network interface or software on the remote host is suspect. Start again with Flowchart 6, but this time ping from the remote host to your system. If the ping in Step H was not successful, call HP.

Execute: telnet to remote host. Try to establish a telnet connection to the remote host.

Successful? If your telnet attempt was successful, the connection has been made through the Transport Layer (OSI Layer 4). Go to Flowchart 9.

Execute: ftp to remote host. Unlike telnet, ftp does not go through a pseudoterminal driver (pty) on your system. This step tests to see if the pty is why telnet failed.

Successful? If ftp is successful, you likely have a problem with a pty on your system. Contact your HP representative. If not, go to E

TCP configured on local or remote host? Neither telnet nor ftp will work if TCP is not configured on either side of the connection. Check the /etc/protocols file on both hosts to be sure TCP is installed and configured. If it is not, go to F. If yes, go to G.

Configure TCP. If necessary, install TCP on either or both hosts. Start over with Flowchart 1.

Network congested? If TCP is installed on both hosts, do a file transfer to another remote host on the network. Use netstat to check for lost packets.

If 10 percent or more packets are lost, the network is extremely busy. If you cannot determine the cause, contact your HP representative for help.

If network congestion is not the cause, more detailed diagnostics are required. Again, contact your HP representative.

Execute: linkloop to remote host. Enter the link level address (station address) of the remote host in hexadecimal form (preceded by "0x"). Execute lanscan (1M) to find the link level address (station address) on the remote host or obtain it from your network map.

linkloop successful? If the test was successful, network connectivity is okay through the Link Layer (OSI Layer 2). Go to Flowchart 10. If it failed, note which error was returned and continue with this flowchart. NOTE: Make sure the remote host is an HP 9000 Series 700/800 and try again.

Loopback FAILED; Address has bad format. The link level address is not correct. Go to F.

Loopback FAILED; Not an individual address. The link level address is not correct. The second hexadecimal digit is odd. This means it is a multicast or broadcast address, which is not allowed. The address must be unique to one remote host. Go to F.

Loopback FAILED. The remote host did not respond. Go to G.

Correct the link address parameter. Change the link level address to an allowed value and start again with Flowchart 9.

Choose a different host; re-execute linkloop. Restart this flowchart using a different remote host.

linkloop successful? If the test was successful, go to Flowchart 10. Network connectivity is okay through the Link Layer (OSI Layer 2). If not successful, go to I.

Check remote host's connectivity to FDDI. Contact the node manager of the remote host. Check that the host is configured correctly and that its network interface is up. If necessary, use Flowchart 8 to verify configuration of the remote host.

Execute netstat -i. Check that the network interface exists. At the system prompt, type:

netstat -i

Interface present? Check that the network interface exists. If it does, but with a network interface name you do not expect, go to C to reassign the network interface. If the network interface does not exist, proceed to step D.

Expected interface? If it exists but with a network interface name you do not expect, go to E to reassign the network interface. If it has the expected interface, go to Flowchart 11.

Re-edit /stand/system. Add entries for an extra FDDI adapter. Go to F.

Redo ifconfig(1M). Specify the network interface returned in step A. Start again with Flowchart 4.

Generate new kernel. Generate a new kernel and go to G.

Shutdown system. Shutdown the system and go to H.

Bring-up system with new kernel. Bring up the system and start again with Flowchart 2.

Execute: ping from known good host through gateway to known remote host. This will test gateway connectivity to the remote network.

Successful? If ping was successful, the problem may exist in the routing table for the problem host. Go to C. If not, go to D.

Check route table on problem host and all hosts between. Execute netstat -r to examine a route table. Go to E.

Examine gateway. If the gateway is an HP 9000, go to G. If it is not, go to F.

Correct route tables. Ensure that the proper IP addresses are assigned in the Destination and Gateway fields. If you are using subnetting, make sure that the destination is what you expect: a network or a host. Go to Flowchart 6.

If other HP or other vendors, refer to networking documentation. Refer to the documentation that came with the gateway for additional diagnostics.

If HP 9000, execute: ifconfig on gateway host. Execute ifconfig for all network interfaces on the gateway.

Network interface up? If the output from ifconfig does not include the UP parameter, the network interface is down. Execute netstat -i to check the status of the network interfaces. An asterisk (*) indicates that the interface is down. If the network interface is down, go to I. If the network interfaces are UP, go to Flowchart 2. Test all network interfaces on the gateway. Running is always displayed. It indicates only that there is OS support for the interface.

Configure interface up. Execute ifconfig on each interface to bring it up. Start again with Flowchart 6. Test all network interfaces on the gateway.