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 192.168.1.1) 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
INTERFACES="-ieth1" |
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 > /etc/wpa_supplicant/wpa_supplicant.conf |
My /etc/wpa_supplicant/wpa_supplicant.conf will now read
network={ ssid="mynetwork" #psk="thisismypass" psk=ee9a5cd2e36d4056464787fdb24c7b9168fea5d9050711c5fc44cf322569e4e6 } |
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
network={ scan_ssid=1 ssid="mynetwork" #psk="thisismypass" psk=ee9a5cd2e36d4056464787fdb24c7b9168fea5d9050711c5fc44cf322569e4e6 } |
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
DEVICE=eth1 ONBOOT=no BOOTPROTO=dhcp HWADDR=XX:XX:XX:XX:XX:XX TYPE=Wireless |
(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.
INTERFACES="iwlan1" |
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.
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.
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)
That will tell you what's installed. If it was the net5211 then
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
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
For Ubuntu, you can probably get by with
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,
When I write <version> it refers to whatever the latest file name
will be, for example madwifi-hal-0.10.5.6-r3816-20080724.tar.gz
6. It may be necessary to remove and/or blacklist conflicting Atheros
modules.
In Fedora, you should be able to do this without rebooting.
Add the module to blacklisted modules. With your favorite text editor,
open the file /etc/modprobe.d/blacklist and add this line to it.
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
In Arch, Zenwalk and PCLinuxOS, I didn't have to disable or blacklist
anything.
7. Insert the ath_pci module
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.
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
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
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.
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
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
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.
IMPORTANT NOTE
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
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.
This work is licensed under a Creative Commons
License
ndiswrapper -l
ndiswrapper -e net5211
make uninstall
yum -y install gcc gcc-c++ make kernel-devel
sudo apt-get install build-essential linux-headers-$(uname -r)
tar zxvf madwifi-<version>tar.gz
cd madwifi-<version>
make
make install
rmmod ath5k
blacklist ath5k
blacklist ath_hal
modprobe ath_pci
ifconfig ath0 up
iwlist ath0 scan
sysctl -w dev.wifi0.ledpin=3
sysctl -w dev.wifi0.softled=1
/usr/bin/setkeycodes e055 159
/usr/bin/setkeycodes e056 158
dmesg |grep HAL
dmesg |grep ath0
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.)
make uninstall
make clean
make
make install
modprobe ath_pci