[[PageOutline(2)]]

= Troubleshooting =
This page hold lots of FAQs related to troubleshooting MadWifi. Some of the entries are not relevant to recent driver versions, but have been left here to help out people who might be using older driver versions. Feel free to add entries to the bottom, but please don't just ask questions here. If you need help, start with the [wiki:Support] page.

== My computer freezes when I {{{rmmod ath_pci}}} ==

Upgrade! You need a newer version, See UserDocs/GettingMadwifi

== No wireless signal ==

Mini-PCI has a feature that allows the host to inhibit all IO that occurs via the card. This is a commonly used on laptops to implement an RF (Radio Frequency) kill switch, which allows all wireless signals to be stopped (e.g., so one can turn them off on an aeroplane). See [wiki:UserDocs/MiniPCI]

== Intermittent Problems or Poor Signal ==

All Atheros hardware has the capability to host at least two antennae. However, all antennae ports are not always connected. Unfortunately, MadWiFi currently does no auto-detect this, so it needs to be set up manually. See UserDocs/AntennaDiversity for information.

== "HAL Status 3" and ath5k ==

The pure ath5k driver is generally present in newer kernels and is auto-loaded. Unfortunately, with some hardware, it tries to initialise the Atheros hardware and fails. The HAL is then unable to initialise the hardware properly, or to reset the hardware, giving a "HAL Status 3" message. To prevent this, the ath5k must be stopped from loading and the computer must be rebooted (eww).

== Performance related questions. ==

Check out the latest version (see UserDocs/GettingMadwifi) and use that before asking any question
you may have through the normal channels.

== I get: "Warning : Device ath0 has been compiled with version 15 (...)" ==

This is easy to fix, you need to rebuild your kernel with the latest [http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#wext Wireless extensions] bear in mind that new kernel tend to ship with the latest version, so it might be worth just upgrading. 

== How do I see what version of the Wireless extensions I'm using? ==

Try this:

{{{
cat /proc/net/wireless
}}}

And look in the final column (marked WE). You could also look at the wireless extensions home page (above).

== The drivers compile fine, but I get "unresolved symbol" errors on modprobe ==

This generally means that your kernel was built with CONFIG_MODVERSIONS set,
but the madwifi modules got compiled with different options. Rebuild your
kernel with it disabled, hopefully that will fix it.

You can also try to modprobe the module, by forcing it to strip the versioning information from the module, and it should go in. Read 'man modprobe' for more details.

{{{
/sbin/modprobe ath_pci --force
}}}

Also make sure you have {{{CONFIG_NET_WIRELESS=y}}} in your /path/to/kernel/source/.config.

== What does "HAL status 13" mean? ==

Unfortunately this is the status code returned when an unsupported card is detected.

If you see this message, check the kernel log to see what your current HAL version is by running {{{dmesg | grep ath_hal}}}. If the version you see is the same as the version number at the bottom of: source:trunk/hal/version.h, then
you are already running the latest HAL code, and unfortunately have to wait until the next HAL release before your hardware is supported.

If the version number is less that the one in {{{version.h}}}, then you should upgrade your version of the driver. See UserDocs/GettingMadwifi for more information.

Note: All laptops have some capability to disable the radio via a RF "kill" switch (generally on the front or side): on some hardware, loading the modules while the switch disables the radio produces this error.  Try unloading all ath_* modules, pressing the switch, and loading the modules again.

== IP Forwarding with WEP makes my kernel panic! ==

This issue was fixed early in 2004. You should upgrade (see UserDocs/GettingMadwifi).

== My logs say "ath0: ath_chan_set: unable to reset channel 12 (2467Mhz) hal status 3" and nothing works, what can I do? ==

Try loading the ath_pci module with the parameter:

{{{xchanmode=0}}}

== On RedHat I get "SIOCGIFFLAGS: No such device". ==

This entry was sent in by Stuart Higgs, and only applies to the old code. The new code brings it's own set of Kudzu problems. See UserDocs/Distro/RedHat for more information.

On Redhat, KUDZU detects the card, and makes it the next available eth (in my case, it was eth1). On network start, eth0 comes up, but you get 'SIOCGIFFLAGS: No such device' for the wireless card. The solution I worked out was:

 * Edit the {{{/etc/modules.conf}}} file
   * Change {{{eth1}}} to {{{ath0}}} (for the alias {{{eth1 ath_pci}}}).
 * Rename the file {{{/etc/sysconfig/network-scripts/ifcfg-eth1}}} to {{{/etc/sysconfig/network-scripts/ifcfg-ath0}}}.
 * And then execute:
   * {{{/etc/rc.d/init.d/network restart}}}

== On my Thinkpad X31 I get: "kernel: ath0: hardware error; resetting" whenever I use the wireless tools. ==

Thanks to John Morgan Salomon for this tip.

I am running madwifi on a Thinkpad x31 (Atheros 5211) under Debian kernel and I
kept getting the following error messages:

{{{kernel: ath0: hardware error; resetting}}}

{{{kernel: ath_hal_wait: timeout on reg 0x8: 0x0000002 & 0x00000004 != 0x00000000}}}

Whenever running iwconfig or any wireless utilities to set it up (it compiled and loaded fine otherwise.)

If someone else has this problem, it might be useful to know that getting rid
of acpi in the kernel made it work fine (I seem to recall stumbling across this
in a newsgroup somewhere.) Maybe it's helpful as an interim fix.

== When I try to run {{{iwlist ath0 scan}}}, I get "ath0: Interface doesn't support scanning : Invalid argument." ==

You need to run {{{ifconfig ath0 up}}} before you can scan. 

== Why won't my wireless NIC associate properly when I use enable restricted mode WEP on my AP? ==

This question and answer were supplied by Aaron Turner.

If your AP is configured to have WEP enabled and is in restricted mode (rather
then open mode) the madwifi driver won't properly associate. Symptoms of this
include iwconfig showing the NIC associating and unassociating on a regular
basis and not being able to send any traffic.

The solution is to force the authentication to restricted mode using iwpriv in
addition to iwconfig.

The following commands should do the trick:

{{{
iwconfig ath0 key restricted
iwpriv ath0 authmode 2
}}}

Hopefully the default behavior will change soon, so that this isn't necessary.
Should iwpriv complain about no extensions, you're running an old version of the userspace wireless tools and need to upgrade (see above).
  

== When I used my card in Master mode, my system gets sluggish, and clients disconnect. What can I do? ==

You may be suffering from the infamous 'Stuck Beacon Problem', as first
described by Greg Chesson of Atheros.

Have a look at our StuckBeacon page for more information, and experiences.

== I see "ath0 (WE) : Buffer for request SIOGIWPRIV too small (x<y)". What's wrong? ==

This entry was sent in by Mike Renzmann, who, (again) did all of the
writing and detective work.

The wireless extensions (WE) is an interface (API) used to retrieve data from
wireless LAN cards. It also allows manipulation of the settings of such cards.
The wireless tools (iwconfig, iwpriv et al.) are perhaps the most important set
of programs that make use of these extensions.

Many wireless drivers have special requirements that are not covered by the
generic requests provided by the WE. Private requests are the answer to this
problem. A generic tool to access these private requests is available as part
of the wireless tools: {{{iwpriv}}}.

Due to iwpriv's generic nature it sometimes happens that the buffer, which the
tool uses to store the driver's response to a private request, isn't big
enough. iwpriv handles this situation by dynamically increasing the buffer's
size and retrying the request. Nevertheless the kernel prints out an error
message whenever this situation occurs. For this reason you possibly see more
than one of these messages at a time.

Currently there is no way to suppress these messages (other than patching the
kernel, which probably isn't a good idea). Ignoring them is safe, as long as
you don't get an error message from iwpriv as well.


== When trying to configure WEP encryption, iwconfig complains about "invalid argument". What's wrong? ==

You most probably have kernel module autoloading disabled in your kernel config and didn't
load the wlan_wep.[k]o module which implements the support for WEP encryption.
In this case you would see a message such as:

{{{Error for wireless request "Set Encode" (8B2A) :}}}
{{{		SET failed on device ath0 ; Invalid argument.}}}
	  

Running {{{modprobe wlan_wep}}} should solve this problem.

== When I run try to scan I get: "ath0: Failed to read scan data : Resource temporarily unavailable". How do I fix it? ==

Upgrade your wireless tools to at least 28-pre3. If you are using the correct version of the wireless tools and have an integrated card in a laptop, make certain the card is 'on' by turning on the mechanical switch to activate the card. This error was noted running a 2.6.13 Linux kernel, wireless-tools 28pre9 / WE18 with a 5212 chipset card.

On a Dell Inspiron 8200 I see the same symptom. Wireless tools is at 28-pre8. lspci shows "Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)". ath_hal 0.9.14.9. ath_pci 0.9.6.0 (EXPERIMENTAL).  There is no "mechanical switch" to be found and the BIOS shows that mini-PCI is enabled.  Still, it does not work. If anyone finds a solution to this please post.

Also, try the instructions from the section "[wiki:UserDocs/Troubleshooting#MywirelessNICwontproperlyassociatewhenIuseWEPrestrictedmodeontheAP. My wireless NIC won't properly associate when I use WEP restricted mode on the AP.]" above, as this worked for me with a Linksys WMP55AG card running on a 2.4.22 kernel.

== When I load the ath_pci module I get "unable to attach hardware: Hardware didn’t respond as expected, (HAL status 3)"! ==

PCI bridges exist which pose difficulties to Atheros cards (and maybe
other hardware too). To get your card working, you first have to find your
PCI bridge's PCI ID with {{{lspci}}}. Then you have to set the SUBORDINATE_BUS
option for this PCI ID with the {{{setpci}}} tool.

For example:

{{{
# lspci | grep -i "pci bridge"
0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge
# setpci -s 0:1e.0 SUBORDINATE_BUS=0A
}}}

If you have problems with your Cardbus card instead, you should try with the PCI ID of your
PCI to Cardbus controller, which you can find by running {{{lspci | grep -i "cardbus bridge"}}}.

Use {{{lspci -tv}}} to make sure you are configuring the bridge upstream from
the Atheros card.  You can also use {{{pci=assign-busses}}} on the kernel command
line to allow the kernel to assign the busses automatically.

== After building and installing madwifi modprobe doesn't find the modules! ==

On some distributions the running kernel has another name as the
installed kernel source. Madwifi takes information from the installed
kernel source. If this is not correct it can happen that the modules
are installed in the wrong location.
To prevent strange things to happen you should set the {{{KERNELRELEASE}}}
environment variable before running {{{make}}}:

{{{export KERNELRELEASE=`uname -r`}}}

Or, if you run a csh variant:

{{{setenv KERNELRELEASE `uname -r`}}}

(and then {{{make; make install}}}) should do the job in most situations.

On some Linux distributions you may need to run one command after "make install":
{{{
depmod -a
}}}

== Modprobing madwifi modules fails with a message "kernel disagrees about module version". ==

See above.

== I get: "Makefile.inc:94: *** KERNELPATH must be defined.  Stop." Why? ==

This could be one of three things: 

1. Your kernel source isn't installed in one of the default places {{{make}}}
looks for it. If this really is the case, you have to tell make where to
find it:
{{{
make KERNELPATH=/path/to/your/kernel/source
}}}

2. You don't have the kernel source for your running kernel installed. Install the sources for you kernel, or roll your own kernel and use the sources for that.

3. You don't have installed the headers for your kernel. If you use Debian, run {{{apt-get install kernel-headers-2.x.y}}} (2.x.y being your kernel version).

== I get "ath0 (WE) : Driver using old /proc/net/wireless support, please fix driver !" when loading the driver. Why? ==

Lately (late 2005) there has been a change in the kernel's interface for WLAN drivers. The message you see is a warning, meant to urge developers to make use of the new interface rather than relying on the old one. It's a warning, not an error, so ignoring it is safe. If you don't want to see this message in your logs, you should consider upgrading to a more recent snapshot of MadWifi, where this issue has been fixed.

== I've just upgraded.  I can {{{modprobe ath_pci}}}, but no {{{athX}}} device comes up. ==

You do see a {{{wifi0}}} device, but it doesn't work (doesn't support wireless extensions), right?  You've just upgraded to a recent version of madwifi (probably from an "old" one included with your OS distribution).

You'll want to read about MadWifi here: [wiki:ngFeatures], especially the part that discusses the {{{wlanconfig}}} command, e.g.

{{{
wlanconfig ath0 create wlandev wifi0 wlanmode sta
}}}

That will help you setup your {{{athX}}} device(s), which should then work as before.

== {{{modprobe ath_pci}}} with '''Pre Rev 1408 MadWifi code''' creates {{{ath0}}}, not {{{wifi0}}} ==

''Note Please:  This erroneous behavior is specific to MadWifi code up to revision 1407, all revs after 1407 make a working ath0 station by default.'' 

It is likely that you have an '''ath'''x line in {{{/etc/iftab}}}, if so, erase it and unload/reload the ath & wlan modules (or restart).

See '''man ifrename''' and '''man iftab''' for more information.

== Hostapd crashes when a WinXP client tries to associate ==

The following has been [http://article.gmane.org/gmane.linux.drivers.madwifi.user/9353 reported] by Ron Dippold:
{{{
#!blockquote
It appears that if hostapd is set up for PSK and EAP that it confuses the Windows XP supplicant. It doesn't reply (or doesn't reply properly?) and hostapd crashes. Other Windows supplicants like Intel !ProSet work okay. If hostapd is set to use just
{{{
wpa_key_mgmt=WPA-PSK
}}}
instead of
{{{
wpa_key_mgmt=WPA-PSK WPA-EAP
}}}
then the XP supplicant is satisfied.
}}}

== I cannot get an IP with DHCP ==

Be sure to be connected to a peer or an Accesspoint before asking a DHCP lease.[[BR]]
Asking a DHCP lease if you are not connected is like having an unplugged RJ45 and asking a DHCP lease.[[BR]]
[[BR]]
Never ask a DHCP lease on wifi0, you won't get anything on this interface.[[BR]]
[[BR]]
See also the entry above on using restricted mode.

== Everything appears to be operational, but I still can't access the network! ==

If you have an Ethernet card, there's a chance you have two routes for your local network, one outbound on eth0, the other on ath0. Try disabling eth0 (which will disable its outbound route):

{{{
ifconfig eth0 down
}}}

Try hitting the network now!

=== Alternative method - routing ===
You can also set up proper routing.

Suppose you want to act as an gateway on 192.168.20.1

|| '''interface''' || '''addr/network'''    ||
|| ath0            || 192.168.20.1/24       ||

then just type as root

{{{
#!sh
route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.20.1
}}}