Fedora 8 and wpa_supplicant

If you're here about the AR5007EG card, that section is below.

When I first wrote this, there were several issues going on with Fedora and wireless, the worst one being a bug in wpa_supplicant. Many are now resolved. This page is now pretty old, but most of it still holds. This is how I've gotten wireless working. NOTE: If you use NetworkManager, do NOT try to mix it with this method of using wpa_supplicant. You have to use either one or the other. (If you use NetworkManager, the MadWifi section of this article may still be useful to you.)

One note which is sometimes overlooked by beginners. If you also have a wired connection, e.g., eth0, and they're on the same network, (for example, if both are getting a DHCP address from a router that has an address of they will conflict with each other. Once you get your wireless setup, before trying to get an address from the router with dhclient or dhcpcd, or setting it manually, don't forget to disable your eth0 card with /sbin/ifconfig eth0 down. You can enable the wireless card and even run iwlist scan (as mentioned below) while eth0 is still up and running, but before getting an address for the wireless, eth0 should be turned off.

I have the popular Linksys WRT54G router. Linksys recommends that you disable broadcasting the network's SSID. I haven't had a problem with this in Fedora 8 with the three wireless devices that I mention. At one point, however, trying an older version of PCLinuxOS, I was unable to connect until I enabled broadcasting. I use WPA2 with AES encryption and PSK (Pre Shared Key).

The first machine I tried was an old Gateway Arc200. It has the Intel 2100 mini-pci card. The card was recognized out of the box. This card only works with 802.11b. It doesn't work with 802.11g. It uses the ipw module which is installed by default. (Support for the module can be found in the Base System=>Hardware Support section.) There were various issues with wpa_supplicant at the time. They have since been partially resolved.

For a discussion of the startup order issue see the bugzilla report and discussion.

In comment #63 of the bug report (yup, it's a busy one) a gentleman named Mike offers an excellent guide describing how he gets wireless to work with wpa_supplicant. (He's generously given me permission to post the link here.)

In my case, the Intel card was seen as eth1. I don't use NetworkManager. I edited /etc/sysconfig/wpa_supplicant to read

I then ran wpa_passphrase. Assuming that my network is called mynetwork and my password is thisismypass the syntax is (this should all be on one line in case your browser breaks it)
wpa_passphrase mynetwork thisismypass >

My /etc/wpa_supplicant/wpa_supplicant.conf will now read

As mentioned, my network doesn't broadcast its SSID. There is a parameter, scan_ssid with a default of 0, meaning off. If your network broadcasts its SSID you can ignore this parameter. As mine doesn't broadcast, I have to add a line to tell wpa_supplicant to scan for my network.

I insert the line so that my wpa_supplicant.conf now reads

As mentioned in the bug report, because network starts before wpa_supplicant, the card will be unlikely to get an address. At present, the most popular method is to mark the card inactive at boot, then add a line or two to /etc/rc.local. The /etc/rc.local file has a few lines in there already. Add
/bin/sleep 1
/sbin/dhclient eth1

I also want to edit /etc/sysconfig/network-scripts/ifcfg-eth1. (The file may or may not already exist.) The important lines are

(There will be other lines in there, usually blank, for example SSID= with nothing after the = sign. That's fine, it gets that information from wpa_supplicant.)

The XX:XX:XX:XX:XX:XX represents the hardware address. The machine might put that in for you, otherwise, you can always get it by running ifconfig eth1.

Lastly, make sure that wpa_supplicant will run at boot. As root or with root privilege
/sbin/chkconfig wpa_supplicant on

Now, on boot, network starts bringing up the lo loopback interface. Then, wpa_supplicant starts. Lastly, dhclient is run on your network interface--now that wpa_supplicant is running, it should be able to get an address from your desired network.

The above instructions should work well, changing eth1 to whatever designation the machine gives your wireless device. The driver line for wext is no longer necessary and can be left commented out.

The Linksys WUSB54GC USB stick

Recently I bought an Acer 4720z lower end laptop. It comes with an Atheros 5007EG card which doesn't work out of the box. As I was, at first, unable to get it to work, I bought a USB wireless adapter to use in the meantime. Googling for one that works with Linux out of the box, I found the Linksys WUSB54GC. Setting it up on the Acer was almost identical to setting up the Intel on the Gateway. The device was recognized at boot and called wlan1. I changed the INTERFACE line in /etc/sysconfig/wpa_supplicant to read

Speaking of Ubuntu, several on Ubuntu forums (including, to my chagrin, one person to whom I recommended the adapter) have not had the same good results that I had. Many of them found that it would frequently drop the connection. If you're using Ubuntu, you might want to look for a different adapter.

The Atheros 5007EG card and MadWifi

This section will soon become obsolete as more and more distributions provide built in support.

IMPORTANT NOTE: MadWifi changed their website from madwifi.org to madwifi-project.org. One assumes there was a reason, but apologies to anyone who tried any of the URLs in this article and found that they didn't work. It's been fixed. (Of course, this site also changed its URL and roadrunner didn't allow me to leave any sort of redirect, so I suppose I shouldn't comment.)

In general, the 2.6.27 kernel's ath5k module supports the card. If you're running an earlier kernel, then you should use the MadWifi drivers. You can find out the number of your kernel by typing the command
uname -r

However, Ubuntu's Intrepid does not support it by default. From the Intrepid release notes

The version of the ath5k driver for Atheros wireless devices included in Linux 2.6.27 interferes with the use of the madwifi driver for some wireless devices and as a result has been disabled by default. Many Atheros chipsets will work correctly with the madwifi driver, but some newer chipsets may not, and the madwifi driver may not work with WPA authentication. If you have an Atheros device that does not work with madwifi, you will want to install the linux-backports-modules-intrepid-generic package, which includes an updated version of the ath5k driver. While not installed by default, this linux-backports-modules-intrepid-generic package is included on the Ubuntu 8.10 CD and DVD images for ease of installation.
Different people have different results, no doubt, in part, because of the differing chipsets. Some, although they have some success with the ath5k module find that the card is more reliable with the MadWifi driver. Others have the opposite experience. The reader is advised to first try the ath5k module (if your kernel supports it) and, if it doesn't seem to work very well, then try the MadWifi driver.

Ubuntu's Hardy also seems to now support the card without using the MadWifi drivers. As of 26 October, 2008 doing
aptitude install linux-backports-modules-hardy

(or possibly hardy-generic rather than hardy), should enable the card to work with the ath5k module.

Although a reboot might be necessary, the card should then be seen as wlan0. (If you have the ath_pci module installed, remove and blacklist it. Add the line "blacklist ath_pci" without quotes to the end of /etc/modprobe.d/blacklist). In theory, one should be able to do
ifconfig ath0 down
modprobe -r ath_pci
modprobe ath5k
ifconfig wlan0 up

and have the card working, but in practice, it is usually simplest to add the blacklist line for the ath_pci and reboot.

Many distributions are not yet supporting this card. At this point in time, if your distro is not running the 2.6.27 kerne, I would recommend trying your distribution's version of MadWifi, for example, the rpmfusion repo with Fedora. If that doesn't work, uninstall your distribution's package and use the instructions below. If you are using a 2.6.27.x kernel, you should try the builtin ath5k module first.

To enable a particular repo in Fedora, the syntax is
yum --enablerepo=rpmfusion install madwifi

The example is for rpmfusion. To find a repo's name, look in /etc/yum.repos.d and look through the repo name's .repo file. You'll see things like [rpmfusion] or [rpmfusion-testing] above the line that reads something like
name=Fedora-$releasever - rpmfusion

The word in the square brackets, for example, rpmfusion-testing is the word you'll use in the command.
yum --enablerepo=rpmfusion-testing install madwifi

Both MadWifi's drivers and the ath5k module also work with 64 bit systems. A few warnings and disclaimers first.

For those revisiting this page, you'll note that the download snapshot has changed. The later version should work with 2.6.26 kernels (the old one didn't) and 64 bit systems.

If you are using a distribution with a 2.6.26 or older kernel, the steps below should enable you to use the card with the MadWifi drivers. Experienced users probably only need the steps written in boldface type. The explanations after each step are for the less experienced.

Most of these commands require root privilege. Fedora users should use su -. Note that there is a space and then a hyphen after the su. This is because (although this should change with Fedora 10) only root has /sbin and /usr/sbin in the program path. See my page on paths for more explanation. This depends upon the distribution. Mepis and PCLinuxOS, among others, also only have /bin and /sbin in root's path, not that of a regular user. If this is confusing to you, it's safe to disregard the explanation. Just remember to do su - instead of just su.

Ubuntu users, preface all commands with sudo. That is if I write make install, please use sudo make install.

1. Determine if it is the AR5007EG card

Running lspci will, on some 32 bit systems, show the card as AR5006EG. If you haven't uninstalled Windows, you can check with its Device Manager, which will show the card to be the AR5007EG. On my Acer 4720z, there is a sticker on the bottom, apparently present in most Acers, saying that it has AR5BXB63. With 2.6.24.x and newer kernels, lscpi may identify it as AR242x 802.11 abg. Running the command lspci -nn should show, however a vendor ID of 168c:001c. If you get command not found then use /sbin/lspci -nn.

2. Remove any ndiswrapper or other MadWifi cruft.

If you haven't previously tried to make the card work with ndiswrapper or MadWfi you can ignore this section. If you've previously installed ndiswrapper or MadWifi, there's a possibilty that whatever is left might interefere with what we're going to do. With ndiswrapper, first uninstall whatever driver you installed. (It will probably be either the net5211 or net5416.) As root or with root privilege (in other words, if using Ubuntu, use sudo for all these commands)
ndiswrapper -l

That will tell you what's installed. If it was the net5211 then
ndiswrapper -e net5211

If it's the 5416 then change that to net5416.

Then remove ndiswrapper. If you installed it from your distribution's packages, then use yum remove or apt-get remove or whatever your distro uses. In Ubuntu, I believe it will also put a file in /etc/modprobe.d. If you see such a file (it will be probably be called ndiswrapper), remove it with the rm command.

If you installed ndiswrapper from source, then cd into the ndiswrapper directory that was created when you untarred the tar.gz file and type
make uninstall

It will remove the various files it installed and suggest that you run make uninstall a couple of times till you're sure there's nothing left.

If you've installed a version of MadWifi the procedure is similar. If you used your distribution's package use the distribution's package remove tool. If you installed from source, cd into the directory created when you untarred the source and run make uninstall.

3. Download the patched snapshot. The ticket concerning the build that works with the card is here.

The ticket has a link to the snapshot page. Get the latest version. Often, there will be a problem with one distro or another's latest version, or a problem with the newest kernel, and fixes go into the latest snapshot. For example, an older snapshot required patching before working with the latest alpha version of Ubuntu's Intrepid Ibex. Therefore, it is always better to go to the snapshots page linked above and make sure that you have the latest version available.

Save it somewhere. If you're in Gnome, the default will be your Desktop.

4. Make sure you have the necessary tools to compile source code.

In Fedora, I always install several packages that are necessary to compile source code, build rpms and the like. For a bare minimum, I'd suggest
yum -y install gcc gcc-c++ make kernel-devel

For Ubuntu, you can probably get by with
sudo apt-get install build-essential linux-headers-$(uname -r)

This first time, you probably won't need the headers. However it's useful to have them, and this way, when your kernel updates, hopefully that package will update as well. As you'll have to recompile this driver each time you update your kernel, it's good to have the package installed.

Ubuntu and Fedora are the only distributions I've used that didn't have these tools installed by default. ArchLinux, Zenwalk and PCLinuxOS installed the necessary files with their default installation.

5. Untar the file, cd into the directory and run make; make install. If using a system based on RedHat, make sure you have root's path.

Make sure you are in the directory where you downloaded the file. For example, if it downloaded to the Desktop directory, when you open your terminal, do a cd Desktop. (Then run the ls command to make sure you are in the same directory as the file.)

Fedora users, and others who use distributions based on RedHat, please note that some of the commands in make install, e.g., depmod are either in /usr/sbin/ or /sbin. It's necessary to be sure that those directories are in your path. In RedHat and its offshoots, only root's path has that. So, if you did an su, rather than an su -, you might wind up with some command not found errors. For a more in depth explanation, see my page about paths in RH based distros. For now, if using Fedora or another RH based distribution, make sure to do su - and not just su. (This shouldn't be an issue for people using Ubuntu, PCLOS, etc.)

To untar, build and install the source file we just downloaded, do,
tar zxvf madwifi-<version>tar.gz
cd madwifi-<version>
make install

When I write <version> it refers to whatever the latest file name will be, for example madwifi-hal-

6. It may be necessary to remove and/or blacklist conflicting Atheros modules.

In Fedora, you should be able to do this without rebooting.
rmmod ath5k

Add the module to blacklisted modules. With your favorite text editor, open the file /etc/modprobe.d/blacklist and add this line to it.
blacklist ath5k

In Ubuntu, I used System, Hardware from the menu. It showed some Atheros modules and I disabled them. (That was in Hardy--in Gutsy, it might be System, Restricted Drivers or something like that.) Once in Hardy, I had to do rmmod ath_hal as well. That should be added to the blacklist as shown above. In other words, in Hardy, add the line to /etc/modprobe.d/blacklist

blacklist ath_hal

In Arch, Zenwalk and PCLinuxOS, I didn't have to disable or blacklist anything.

7. Insert the ath_pci module
modprobe ath_pci

Hopefully, you then see a command prompt, meaning that the module installed without error. If you get an error message, it still might work after a reboot. For the moment, let's assume you didn't get any error messages. Now, doing lsmod |grep ath should show ath_pci and a few other things.

8. Bring the card up with ifconfig.
ifconfig ath0 up

That step isn't always necesary. However, it doesn't hurt anything, and sometimes things won't work until you do it.

In Fedora 8, the system may see it as wlan0 rather than ath0. If, when doing ifconfig up you get an error that there's no such device, try doing ifconfig wlan0 up instead. Hopefully, you'll get back a command prompt, indicating that the command succeeded. (If there are no errors, you don't get a message, you're just put back at the command prompt.)

9. Run iwlist ath0 (or wlan0) scan
iwlist ath0 scan

If this gives you a list of available wireless networks, you should be in good shape. From there, you can enable wireless the way you usually do. Most Ubuntu and Fedora users make use of Gnome's NetworkManager while many PCLinuxOS folks use the PCLinuxOS or KDE configuration tools. For Archers, there are good articles on the wiki, and for Fedora users who prefer the command line, go back to the beginning of this page which is about using wpa_supplicant.

With luck, you'll now be able to use your wireless card. Sometimes, a reboot might be necessary, but most of the time, I haven't found this to be the case.

The LED light doesn't work by default, but thanks to a posting on Fedora forums, this too is easily solved. As root or with root privilege
sysctl -w dev.wifi0.ledpin=3
sysctl -w dev.wifi0.softled=1

These sysctl values seem to be added by MadWifi drivers. If using a later kernel and using the ath5k driver, instead of the MadWifi driver, the sysctl options won't work--you'll get an error of value unknown or something similar.

Some machines also have a slider. Mine doesn't, but the same poster added two more changes to get that working.
/usr/bin/setkeycodes e055 159
/usr/bin/setkeycodes e056 158

To make either or both of these permanent, add the lines to /etc/rc.local. The sysctl options can be added to /etc/sysctl.conf.

I don't know if the keycode values are also associated with the MadWifi driver. As mentioned, I don't have a slider, so I never tried it. If you are using the ath5k module, and those keycodes don't work, then the chances are that it's because they too are provided by MadWifi modules.

Many laptops have a button or switch to turn the wireless on and off. On my acer laptop, there is such a button. I don't enable the LED light (I find its flashing a bit annoying) so I can't always tell if I've put wireless on or off. If wireless isn't working, and you have such a button, try pushing it a few times. (It didn't always work for me the first time.)

If you still have no luck, then try a reboot. After rebooting, run
dmesg |grep HAL

If it didn't work there might be some sort of HAL error, such as HAL error 3, Hardware didn't respond as expected, or unable to attach hardware: Hardware revision not supported (HAL status 13). You might get some other sort of error. If running the above command doesn't return anything, that's a good sign. If running Fedora 8 (or any other distribution that seems to use wlan0 instead of ath0) try doing
dmesg |grep ath0

If you get back something like ath0 renamed to wlan0 you should be in good shape. Try running iwlist wlan0 scan again. Hopefully, this time it will be successful.

If it's stil not working, you can run through this checklist. It's not a very good one, but it covers a few things that I missed in my early attempts. If you've followed all of the above instructions, you've already covered this.

If this wasn't the first time you installed madwifi, did you run make uninstall and then make clean before running make?

If you had used or tried using ndiswrapper first, did you uninstall that driver and ndiswrapper?

If you did run it as root, (in Fedora) did you do su -, with the space and then the hyphen after the su? If not, there might have been an error somewhere, since Fedora only gives a path that includes /sbin and /usr/sbin to root's environment.

Did you remember to blacklist the kernel's builtin ath5k module?

Did you remember to modprobe ath_pci?

If your laptop has a switch or button to enable or disable wireless, did you remember to check that? On some, like my Acer, the only indication is an LED light that doesn't work in Linux, so one has to guess and possibly try a few times.

Each time you upgrade your kernel, you'll have to do the following. (The modules are tied into the kernel version, so when the kernel is updated, the modules no longer work.)

Go back into the Madwifi directory. (Hopefully, you haven't deleted it. If you have, download and untar it again.) Once you're in the directory
make uninstall
make clean
make install
modprobe ath_pci

At that point, you might get an error. If you do, then reboot and try again.

If you can't get it to work, you might wish to try ndiswrapper.

I've had success with the net5416.inf file, rather than the usual net5211 one. This might be wrong, but I am getting the impression that the 5211 will not work with WPA2 encryption. There a thread on Ubuntu Forums about the Acer 4520, which also uses this card. That's where I found the suggestion to use the net5416 driver, which, aside from working with my WPA2 network also turns on the wireless LED light.

In the same thread, another poster tells how he got it working with 64 bit. Unfortunately, there doesn't seem to be a 5416.inf 64 bit driver. I tried his instructions, including trying older versions of ndiswrapper, but it didn't work for me. I suspect it's because of the network being WPA2, but I am not sure. I've seen reports that the 5211 driver does work with WPA2, but in my searches, I've seen people post that it doesn't. I don't know, but it didn't work for me, and I never got around to trying it with plain WPA.

At one point, though I believe it's been fixed, the default Fedora kernel wouldn't work with ndiswrapper. This thread on Fedora Forums discusses ndiswrapper. One of the posters was kind enough to make an rpm of a recompiled kernel that can be used.

Hopefully, ndiswrapper won't be necessary. Judging from various posts on Fedora and other forums, the success rate seems to be improving. Even if you can't get it to work right now, there's reasonable hope that it will soon work, if not out of the box, then with very little effort. The hope is that soon the kernel's ath5k module will support this card. On Ubuntu forums, one person apparently got it working by using the very latest Hardy Atheros drivers. I wasn't able to duplicate his feat, but with any luck, it will, sooner or later, be one of those cards that just works.

Creative Commons License This work is licensed under a Creative Commons License