Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

  1. My computer freezes when I rmmod ath_pci
  2. No wireless signal
  3. Intermittent Problems or Poor Signal
  4. "HAL Status 3" and ath5k
  5. Performance related questions.
  6. I get: "Warning : Device ath0 has been compiled with version 15 (...)"
  7. How do I see what version of the Wireless extensions I'm using?
  8. The drivers compile fine, but I get "unresolved symbol" errors on modprobe
  9. What does "HAL status 13" mean?
  10. IP Forwarding with WEP makes my kernel panic!
  11. My logs say "ath0: ath_chan_set: unable to reset channel 12 (2467Mhz) hal …
  12. On RedHat? I get "SIOCGIFFLAGS: No such device".
  13. On my Thinkpad X31 I get: "kernel: ath0: hardware error; resetting" …
  14. When I try to run iwlist ath0 scan, I get "ath0: Interface doesn't …
  15. Why won't my wireless NIC associate properly when I use enable restricted …
  16. When I used my card in Master mode, my system gets sluggish, and clients …
  17. I see "ath0 (WE) : Buffer for request SIOGIWPRIV too small (x<y)". What's …
  18. When trying to configure WEP encryption, iwconfig complains about "invalid …
  19. When I run try to scan I get: "ath0: Failed to read scan data : Resource …
  20. When I load the ath_pci module I get "unable to attach hardware: Hardware …
  21. After building and installing madwifi modprobe doesn't find the modules!
  22. Modprobing madwifi modules fails with a message "kernel disagrees about …
  23. I get: "Makefile.inc:94: *** KERNELPATH must be defined. Stop." Why?
  24. I get "ath0 (WE) : Driver using old /proc/net/wireless support, please fix …
  25. I've just upgraded. I can modprobe ath_pci, but no athX
  26. modprobe ath_pci with Pre Rev 1408 MadWifi code creates …
  27. Hostapd crashes when a WinXP client tries to associate
  28. I cannot get an IP with DHCP
  29. Everything appears to be operational, but I still can't access the …

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 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 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 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 "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: 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 athx 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 reported by Ron Dippold:

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.
Asking a DHCP lease if you are not connected is like having an unplugged RJ45 and asking a DHCP lease.

Never ask a DHCP lease on wifi0, you won't get anything on this interface.

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

route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.20.1