Troubleshooting Your Wireless LAN





Troubleshooting Your Wireless LAN

Linux wireless troubleshooting tools are quite extensive and provide a variety of useful information to help you get your network working. This section covers many important strategies that will complement the use of more conventional procedures such as scanning your /var/log/messages file.

Check the NIC Status

When using WLAN methodology, the iwconfig, iwlist, and iwspy commands can provide useful information about the status of your wireless network. Take a closer look.

The iwconfig Command

In addition to using the regular ifconfig command to check the status of your NIC, you can use the iwconfig command to view the state of your wireless network, just don't specify any parameters. Specifically, you can see such important information as the link quality, WAP MAC address, data rate, and encryption keys, which can be helpful in ensuring the parameters across your network are the same. For example:

     [[email protected] tmp]# iwconfig
     eth0      IEEE 802.11-DS  ESSID:"homenet"  Nickname:"bigboy"
               Mode:Managed  Frequency:2.462GHz  Access Point:
     00:09:5B:C9:19:22
               Bit Rate:11Mb/s   Tx-Power=15 dBm   Sensitivity:1/3
               Retry min limit:8   RTS thr:off   Fragment thr:off
               Encryption key:98D1-26D5-AC   Security mode:restricted
               Power Management:off
               Link Quality:36/92  Signal level:-92 dBm  Noise level:-148
     dBm
               Rx invalid nwid:0  Rx invalid crypt:2  Rx invalid frag:0
               Tx excessive retries:10  Invalid misc:0   Missed beacon:0
     [[email protected] tmp]#

The iwlist Command

The iwlist command can provide further information related to not just the NIC, but the entire network, including the number of available frequency channels, the range of possible data rates, and the signal strength. This example uses the command to verify the encryption key being used by the NIC, which can be very helpful in troubleshooting security related difficulties on your network:

     [[email protected] tmp]# iwlist key
     ...
     ...
     eth0      2 key sizes : 40, 104bits
               4 keys available :
                     [1]: 9671-36DE-AC (40 bits)
                     [2]: off
                     [3]: off
                     [4]: off
               Current Transmit Key: [1]
               Security mode:open
     ...
     ...
     [[email protected] tmp]#

The iwlist command can verify the speed of the NIC being used, 11Mb/s in this case. This can be helpful in determining possible reasons for network slowness, especially as poor signal quality can result in the NIC negotiating a low bit rate with its WAP.

     [[email protected] tmp]# iwlist rate
     ...
     ...
     eth0      4 available bit-rates :
               1Mb/s
               2Mb/s
               5.5Mb/s
               11Mb/s
               Current Bit Rate:11Mb/s
     ...
     ...
     [[email protected] tmp]#

For further information on the iwlist command, consult the man pages.

The iwspy Command

The iwspy command provides statistics on the quality of the link between your NIC and another wireless device on the network. It doesn't run all the time; you have to activate iwspy on your interface first. When not activated, iwspy gives a "no statistics to collect" message:

     [[email protected] root]# iwspy eth0
     eth0      No statistics to collect
     [[email protected] root]#

To activate the command, specify the target IP address and the wireless NIC interface through which it can be found:

     [[email protected] tmp]# iwspy eth0 192.168.1.1

If you use the iwspy command without the IP address, it provides WLAN statistics with a typical/reference value against which it can be compared. In the example that follows the signal is considered fairly strong, with a 64/92 quality value versus a typical 36/92 value, but it could be weak by the historical values on your network. It's good to check this from time to time for fluctuations.

      [[email protected] tmp]# iwspy eth0
     eth0      Statistics collected:
         00:09:5B:C9:19:22 : Quality:0 Signal level:0 Noise level:0
         Link/Cell/AP      : Quality:64/92 Signal level:-51 dBm Noise
     level:-149 dBm (updated)
         Typical/Reference : Quality:36/92 Signal level:-62 dBm Noise
     level:-98 dBm
     [[email protected] tmp]#

To switch off iwspy monitoring, add the off argument:

     [[email protected] root]# iwspy eth0 off

Check for Interrupt Conflicts

Devices slotted into your PCI bus are generally assigned an interrupt value by the system, which the system uses to signal its need to communicate with the device. Multiple devices on the bus can have the same interrupt, but the system will access each one using a different memory address to avoid confusion. Sometimes this automatic allocation of interrupt (IRQ) values and memory locations is flawed and overlaps do occur, causing devices to fail.

Before configuring your WLAN software, you should ensure that the wireless NIC card doesn't have an interrupt that clashes with another device in your computer. Insert the card in an empty slot in your Linux box according to the instructions in its manual, reboot, and inspect your /var/log/messages file again:

     [[email protected] tmp]# tail -300 /var/log/messages

Look carefully for any signs that the card is interfering with existing card IRQs. If there is a conflict, there will usually be a warning or "IRQ also used by..." message. If that is the case, move the card to a different slot or otherwise eliminate the conflict by disabling the conflicting device if you don't really need it.

You should also inspect your /proc/interrupts file for multiple devices having the same interrupt:

     [[email protected] tmp]# cat /proc/interrupts
     11:     4639     XT-PIC     wlan0, eth0        (potentially bad)

     [[email protected] tmp]# cat /proc/interrupts
     11:    4639     XT-PIC      wlan0             (good)

Interrupt conflicts are usually more problematic with old style PC-AT buses; newer PCI-based systems generally handle conflicts better. The prior (potentially bad) /proc/interrupts example came from a functioning PCI-based Linux box. It worked because, although the interrupt was the same, the base memory addresses that Linux used to communicate with the cards were different. You can check both the interrupts and base memory of your NICs by using the ifconfig -a command:

     [[email protected] tmp]# ifconfig a
     eth0 Link encap:Ethernet HWaddr 00:08:C7:10:74:A8
     BROADCAST MULTICAST MTU:1500 Metric:1
     RX packets:0 errors:0 dropped:0 overruns:0 frame:0
     TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:100
     RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
     Interrupt:11 Base address:0x1820

     wlan0 Link encap:Ethernet HWaddr 00:06:25:09:6A:B5
     inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
     RX packets:215233 errors:0 dropped:0 overruns:0 frame:0
     TX packets:447594 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:100
     RX bytes:39394014 (37.5 Mb) TX bytes:126738425 (120.8 Mb)
     Interrupt:11 Memory:c887a000-c887b000
     [[email protected] tmp]#

Kernel Log Errors

When you find p80211 Kernel errors in /var/log/messages, they usually point to an incorrectly configured SSID or may also be caused by a NIC card with an outdated firmware version. For example:

     Nov 13 22:24:54 bigboy kernel: p80211knetdev_hard_start_xmit: Tx
     attempt prior to association, frame dropped.

Can't Ping Default Gateway

If you can't ping the default gateway, first check for kernel log errors.

If there are no errors in /var/log/messages and you can't ping your gateways or obtain an IP address, then check your /etc/sysconfig/network-scripts/ configuration files for a correct IP configuration and your routing table to make sure your routes are OK. You can also check to see if your Linux box is out of range of the WAP using the iwconfig command.

Unknown Device Errors

Look for "unknown device" or "no such device" errors in your log files or on your screen during installation or configuration. These may be caused by:

  • An NIC that hasn't been correctly inserted in the PCI slot.

  • Incompatible hardware.

For example, you might see incompatible hardware errors in /var/log/ messages:

     00:0c.0 Network controller: BROADCOM Corporation: Unknown device 4301
     (rev01)
     Subsystem: Unknown device 1737:4301
     Flags: bus master, fast devsel, latency 64, IRQ 5
     Memory at f4000000 (32-bit, non-prefetchable) [size=3D8K]
     Capabilities: [40] Power Management version 2

Or, you might see errors on the screen:

     Dec 1 01:28:14 bigboy insmod: /lib/modules/2.4.18-14/net/prism2_pci.o:
     init_module: No such device
     Dec 1 01:28:14 bigboy insmod: Hint: insmod errors can be caused by
     incorrect module parameters, including invalid IO or IRQ parameters.
     You may find more information in syslog or the output from dmesg
     Dec 1 01:28:14 bigboy insmod: /lib/modules/2.4.18-14/net/prism2_pci.o:
     insmod wlan0 failed

A Common Problem with Linux-WLAN and Fedora Core 1

In older versions of Fedora Core 1, the operating system will auto-detect Linux-WLAN-compatible NIC cards and enter a line similar to:

     alias     eth2       orinoco_pci

in the /etc/modprobe.conf file. In other words, it detects them as an Ethernet eth device instead of a WLAN wlan device.

This seems to conflict with the WLAN RPMs, and you'll get errors like this when starting Linux-WLAN:

     Starting WLAN Devices: /etc/init.d/wlan: line 119: Error: Device wlan0
     does not seem to be present.: command not found
     /etc/init.d/wlan: line 120: Make sure you've inserted the appropriate:
     command not found
     /etc/init.d/wlan: line 121: modules or that your modules.conf file
     contains: command not found
     /etc/init.d/wlan: line 122: the appropriate aliase(s).: command not
     found

You can fix the problem with the proper steps. This example refers to a compatible Orinoco chipset card:

1.
Remove the orinoco_pci line from the /etc/modprobe.conf file. Do not remove the entry for device wlan0.

2.
Edit your /etc/sysconfig/hwconf file, search for orinoco_pci, and remove the orinoco_pci section that refers to your wireless card. (Each section starts and ends with a single - on a new line.)

3.
Reboot.

4.
The Linux boot process always runs kudzu, the program that detects new hardware. Kudzu detects the wireless card and asks whether you want to configure it. Choose ignore. This will reinsert the wireless card in the /etc/sysconfig/hwconf file, but not in the /etc/modprobe.conf file.

5.
Your NIC should start to function as expected as device wlan0 when you use the ifconfig -a command. Configure the IP address, and activate the NIC as shown earlier in this chapter.

The procedure removes all reference to the Orinoco driver in the Linux configuration files and then forces kudzu not to configure the NIC card according to the Linux defaults. The eth device will be recreated, but the ignore option provided to kudzu will prevent the Orinoco entry in the /etc/modprobe.conf from being reinserted, preventing conflict with the Linux-WLAN package's wlan device.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows