Next | Previous | Index


6. Trouble Shooting And Diagnostics

Errors may occur during different stages of WANPIPE initialization. If this happens, the error message will be displayed on system console and/or logged into /var/log/wanpipe file.

WANPIPE initialization errors can be classified as follows:

6.1. Kernel Module Load Errors

WANPIPE initialization scripts use Linux insmod utility to load WANPIPE modules (drivers). If insmod fails, you will see a message identifying the problem. In most cases this is due to incorrect kernel version. WANPIPE modules were compiled against Linux kernel version 1.2.8 and if your kernel version is different, you will have to recompile the modules. Normally, WANPIPE installation script detects this situation and prompts you to recompile modules when you install this product. If you skipped this step or upgraded your Linux kernel, log in as a superuser (root), go to directory /usr/lib/wanpipe and run WANPIPE build script:

./build

If insmod displays messages saying ' undefined', then your kernel was compiled with CONFIG_MODVERSIONS option set to YES. To correct the situation you will have to recompile the kernel and answer NO when asked if you want CONFIG_MODVERSIONS. Refer to /usr/src/linux/README file or any other documentation included with your kernel distribution on how to recompile and configure the Linux kernel.

Note: When recompiling the kernel, make sure you answer YES when asked if you want IP forwarding enabled!

6.2. Hardware Initialization Errors

WANPIPE initialization script uses sdlald utility located in /usr/sbin directory to configure SDLA card (set shared memory window, IRQ vector, etc.), load SDLA firmware onto adapter and bind it to a protocol-specific module. If sdlald fails, it outputs an error message in the following format:

sdlald error X: error message text

Errors fall into one of three groups:

System error are most frequently caused by a failed file operation such as an attempt to open non-existent file, file read error or wrong permissions. They all have error code 1 followed by standard system error message. Refer to your system documentation for more details.

SDLA driver errors occur when driver control function can not be carried out. Driver errors have error code 10 and can be as follows:

Driver also prints its own diagnostic messages using printk() routine. Its output usually goes to /var/log/messages file. Check it out.

Miscellaneous errors include invalid sdlald command line syntax or unrecognized command line option, attempt to acces non-SDLA device, etc.

6.3. Protocol-Specific Configuration Errors

This type of errors occurs when protocol-specific initialization script attempts to configure links and create network interfaces. Most protocol- specific modules use configuration utilities in /usr/sbin directory to configure links, create network interfaces, etc. These utilities are: If configuration utility fails, it outputs an error message in the following format:

xxxxcfg error X: error message text

All configuration errors fall into one of three categories:

System error are most frequently caused by a failed file operation such as an attempt to open non-existent file, file read error or wrong permissions. They all have error code 1 followed by a standard system error message. Refer to your system documentation for more details.

Driver errors occur when driver control function requested by the utility can not be carried out. These errors have error code 10 and can be as follows:

The rest is miscellaneous errors, most of them are self-explanatory. Some of them are:

6.4. Trouble Shooting WAN Connections

When WANPIPE initialization is complete, all network interfaces you defined during link-level configuration should appear in 'cat /proc/net/dev' command output. If not, verify configuration and check WANPIPE log file for error messages.

Make sure, interface flags displayed by 'ifconfig {name}' command include RUNNING and UP. If not, verify TCP/IP-level configuration and correct it if necessary. Then view routing table by executing 'route' command and make sure all network and host addresses are correct. Consult Linux Network Administration Guide by Olaf Kirch if you have any problems.

If all the above looks ok, you should be able to ping remote host. If not, do the following (we assume you are using frame relay interface named flip0 associated with DLCI 16 on SDLA card 0):

1) Make sure your link level is up by viewing link-level status. To obtain frame relay link-level statistics use the following command:

flipcfg s N

where N is a SDLA card number this interface is bound to.

This command will print miscellaneous status and statistical information. The first line (Link status) should read "DCD UP : CTS UP : LINK UP". If either CTS or DCD is DOWN verify connection to your modem or CSU/DSU (cable, pinout, interface type). If both of them up but LINK is DOWN verify your link-level configuration (baud rate, clocking, etc.).

Check list of active DLCIs. Your DLCI should be listed there. If not, verify DLCI number and contact your service provider, if necessary.

2) Verify network interface configuration by typing ifconfig flip0. You should see something like this:

flip0   Link encap:UNSPEC       HWaddr blah-blah-blah (whatever)
        inet addr: Your_IP_addr P-t-p: Other_IP_addr Mask: ..
        UP POINTOPOINT RUNNING NOARP    MTU:1500        Metric:1
        Rx packets:0    errors:0        dropped:0       overruns:0
        Tx packets:0    errors:0        dropped:0       overruns:0
        Interrupt:0 Base address:0x0
Make sure Your_IP_addr and Other_IP_addr are correct and interface flags UP, POINTOPOINT and RUNNING are set.

3). Verify routing table by typing 'route'. You should see an entry in the routing table for Other_IP_addr as follows:

Destination     Gateway Genmask         Flags   MSS     Window  Use     Iface
Other_IP_addr   *       255.255.255.0   UH      1436    0       0       flip0
4) Start pinging remote system and take a look at interface statistics reported by ifconfig flip0 command.

If 'Tx packets' count goes up, then your network interface and routing table are set up correctly and you can proceed to step 5.

If 'Tx packets' remains 0, but 'Tx errors' and/or 'Tx dropped' grow, then check /var/log/messages file (see Driver Error Log later in this chapter).

If neither of these statistics changes, return to step 1 and verify interface configuration and routing table.

5) If you are connected to DSU/CSU which has LEDs on it, the transmit LED should flicker approximately once a second while you are pinging. If it does not then check your connection to DSU/CSU (cable).

6) If you see transmit LED flicker, but not receive LED, then remote system is not responding. Make sure your destination IP address is correct and remote system is up and running.

7) If both transmit and receive LEDs flicker approximately once a second, take a look at interface statistics reported by 'ifconfig flip0' command again.

If neither 'Rx packets' nor 'Rx errors' counts change, check SDLA interrupt count by looking at the output of 'cat /proc/interrupts' command. If it is 0 then chances are that IRQ settings on the board and in SDLA driver configuration do not match. Verify IRQ jumper settings.

If 'Rx packets' remains 0, but any of the receive error counts grows, then check /var/log/messages file (see Driver Error Log later in this chapter).

It may be useful to look at TCP/IP-level statistics on both ends. To obtain these statistics under Linux use 'cat /proc/net/snmp'. The output is not formatted, but it is fairly easy to interprete. Treat it as a table consisting of four two-line entries (long lines are wrapped). Each entry consists of two lines starting with the protocol name (Ip:, Icmp:, Tcp: and Udp:). The first line is the list of statistics names, the second one is their values. Note that these are global statistics, i.e. they are not associated with any particular interface. So if you have several network interfaces (e.g. Ethernet) they will all contribute to these statistics.

Driver Error Log

FLIP driver calls on firmware running on the adapter to send and receive data, set adapter configuration, etc. If firmware command fails for one reason or another, the driver logs an error message into the /var/log/messages file. The error messages have the following format:

flip: command XXX returned YYY on port ZZZ

where

Firmware command and error codes are defined in /usr/src/sangoma/fr502.h header file. Some of the firmware commands are: And some of the firmware error codes are: For example, a message

flip: command 0x01 returned 0x03 on port 0

means that adapter /dev/sdla0 could not transmit a frame because DLCI was inactive. In this case you have to verify that you specified correct DLCI number when configuring the interface.


Next | Previous | Index