You are here

The long slow trainwreck of Linux Atheros support

I just stuck the following line in my cron.d directory.

17 05 * * * www-data /etc/init.d/atheros stop; /etc/init.d/atheros start

What this does is to restart the Linux driver for my Atheros PCI card every night. I'm trying this because the driver seems only able to stay up for about 36 hours. This is my latest and most desperate attempt to date to actually have this card act as a working Linux AP… I, like many people, purchased my Atheros HW several years ago because it was cheap, and because it worked really well with Linux. Atheros, unlike most of its competitors at the time, wanted to encourage open source drivers. However, for complex reasons it was unwilling to release specification for its hardware. Their solution was to release a binary-only Hardware Abstraction Layer that open source drivers could be written atop. The MadWifi project did so.

The resulting driver was quite cool. It enabled some really useful functionality, such as running multiple stations on the same piece of hardware. It always had reliability issues, but eventually stabilized by early Linux 2.6 as something that was of production quality.

However, because of the dependency on the binary HAL, it was politically difficult to get MadWifi into the mainline Linux kernel. Vendors were concerned about shipping a binary blob in a GPL'ed product, and the FSF was not encouraging in this regard. Thus, someone started to reverse engineer the Atheros hardware with the goal of writing a fully open-source driver.

The result of these efforts was the ath5k Linux driver. The MadWifi team made the decision in 2007 to declare their existing driver legacy and work on ath5k. During this time period, there was also a bunch of copyright and licensing dispute over the reverse-engineered code, which was originally written for BSD by several parties and licensed under an eclectic collection of licenses. This dispute now appears to be largely resolved, if not entirely amicably. The ath5k driver is now in mainline.

...

Unfortunately, two years later ath5k still doesn't work. Vital functionality is still missing. The mainline version as of kernel 2.6.30 does not even support station mode. The development version reportedly does, but it has a number of bad outstanding bugs in this regard.

Meanwhile, the legacy MadWifi bits have bit-rotted. MadWifi, in every incarnation I have tried, now regularly hangs itself at best, and the kernel at worst. Only a couple of patches in the development tree over the last couple of years even try to address these problems; the MadWifi developers have truly moved on.

Thus, I am left with no workable driver for a PCI card that I had adopted as an important part of my Linux infrastructure. Worse yet, the Atheros chipset still appears to be the best-supported Wifi chipset for Linux, so I can't just replace the hardware and move on.

What I will probably do this week is what everyone else does: set up an external WAP and kill my Atheros card. I'm still trying to figure out whether I need one or two WAPs as replacements. I was running two stations on my old card, so I have to decide whether it's worth trying to keep them both. Alternatively, I might be able to find a WAP that supports multiple station mode, but I don't know of one offhand.

This being open source and all, in principle what I should do is fix MadWifi or ath5k, or at least provide detailed bug reports that might enable an ath5k fix. However, this is quite complicated hardware and software; I would guess I'm looking at 20 or 30 hours of work to get any kind of resolution to my problems. I just don't have that kind of time right now. [Turns out I was wrong. Thanks to help from Luis Rodriguez (see comments below) it took me about five hours to get ath5k going. So far, no bugs, and I don't particularly expect any given the apparently newly-mature state of ath5k.]

As you can tell, I am quite frustrated. Regressions are always frustrating; regressions on a critical and largely irreplaceable piece of hardware are worse. I really wish some folks had done things differently over the past few years. I hope that something was learned from this train wreck, but I see little evidence of that right now. All I see is broken stuff scattered across the tracks. Fob

Comments

Users with issues should report them so that they are fixed. If you definitely have to give up on ath5k AP support for now you may want to try a MadWifi release from openwrt -- I suspect that is still maintained and compiles.

Everything should be fixed on ath5k though -- so please help address the issues you see and report them properly. You do not mention the kernel you are using and ath5k has gone through many changes over the recent kernels, I encourage users of ath5k to at the very least use 2.6.32 driver bits. If you doesn't want to compile the entire kernel kernel you can get the 2.6.32 wireless subsystem alone from:

http://wireless.kernel.org/en/users/Download/stable

If you want even more bleeding edge you can try the compat-wireless bleeding edge:

http://wireless.kernel.org/en/users/Download

Please keep in mind ath5k issues must be fixed first on bleeding edge unless it is a regression or oops issue so using bleeding edge helps more with developers.

I'll try to get some more recent ath5k bits up on my host box; I was working on that tonight anyway, actually. I will certainly report any issues I encounter if I can put together a sensible bug report.

That said, I still have questions. AFAIK ath5k still doesn't support multiple station mode? As I said above, I've been using this mode for years and have grown quite fond of it. Also, I note that linux 2.6.32 isn't even released yet; I assume I'm supposed to grab rc5, or maybe linux-next? I'm not quite understanding the purpose of wireless-compat, I think; I assumed it was a backport to 2.6.31 or something, but I guess it's even newer than the stuff in the top of Linus's tree?

Again, thanks much for your comments; I'll see what I can figure out. Fob

Multiple station support has not been implemented on ath5k but patches are welcomed. Again, if the features available for ath5k are not yet up to par with what you are used to I highly you encourage to check out the work that openwrt does with maintaining MadWifi -- I believe that stuff is always well maintained and will compile. But ath5k should obviously be the focus of development as that is upstream.

The download page for compat-wireless has text explaining what it is and reasoning for it -- but essentially its there because users do not run bleeding edge kernels and users of ath5k and other drivers do need more bleeding edge kernels. There are two compat-wireless releases, the bleeding edge and the stable releases. Both are hopefully documented well enough.

I have a single-station ath5k installation up and running; I'm using bleeding-edge compat-wireless with a stock Debian 2.6.30-2 kernel. It seems to be working great so far; the only error message I've seen is "unsupported jumbo", which presumably means that jumbo frame support isn't there yet.

It looks like a lot of the infrastructure is there for multiple station support, although I haven't tried it yet. I can create a second virtual interface, at least. I'm a little confused as to what would happen if I hooked another hostapd instance to it; it looks like it should just work, but I'll try it and watch it crash sometime soon.

The iw tool has a pretty painful UI, even compared to things like iwconfig and wlanconfig. I also miss being able to just set master mode on an interface; it's odd to have to always run hostapd to do this, even on an unsecure connection. Should I try to patch iw to support this, or is it hard for some reason? I'll definitely try to write a real manpage for iw at some point soon, and try to put some small interface patches in to add some extra function.

Thanks much for all your help. It's been really informative to have you respond so quickly on my little blog, and I really appreciate it. Fob

I've been running two atheros wireless cards in my server for the past 12 months, and since switching to ath5k I've had no problems other than my syslog being spammed with the two following messages:

kernel: ath5k phy0: unsupported jumbo kernel: ath5k phy1: unsupported jumbo

when I say spammed, it's about every ten seconds. It may have something to do with the APs usually in monitor mode i guess. It is frikking annoying, but other than that I've had no problems with the drivers

currently running 2.6.31.4 Now : 25 day(s), 15:17:52 running Linux 2.6.31.4-jupiter-00

I often used wlan0 or wlan1 as the default route for my entire LAN during that time period too, and I've never rmmod'd during that time, just ifconfig/iwconfig work etc.

YMMV

The kernel apparently hung once in the last 10 days, while I was out of town. I didn't find much in the logs that was helpful.

Other than that, everything has been good. The "unsupported jumbo frame" messages might be caused by jumbo frames on the wire; I get them, but not nearly as frequently as you. Fob

I have ath9k chipset - does not work in 2.6.32 kernel too. Their support is really bad. I wonder how they sell.

Finally, I moved to ralink and it works great as of now. They do have driver source on their website with good enough support.

I'm running an Ubuntu distro and having issues with my Atheros-based WiFi card.

Although the application for it isn't as critical as some of you folks, it's really frustrating to find that my Mythbuntu box stops communicating on the wireless network after a few hours.

I'm not exactly sure how long it is, but it's reasonably quick. I've not found any messages indicating any errors other than the Jumbo issue.

I'm trying to turn off all wireless power saving settings too.

http://wireless.kernel.org/en/users/Drivers/ath5k#features contains an account of how to deal with the "Unsupported Jumbo Frame" issue for ath5k Linux. I haven't tried it yet. Someone should probably modify the driver to do this patch itself when it gets the first error of this type, but I'm too lazy.

It's a real shame that Linux ath5k is still so borked. Fob

Sorry guys I have been having intermittent problems over the years with this card.. but this latest kernel breaks its usability completely. Seems sometimes it is impossible to scan for AP's with the card, even unloading the module and loading it again fails to get it to work. It is just nuts as it was working well enough in 2.6.34. To be honest I am fed up with having to wait for people to maintain this card I think I will swap out the card for an Intel one, which at least I know is working. How did things get in such a mess?

I finally have ath5k working really well with my 2.6.32 kernel. It supports multiple virtual APs and everything. So I'm sad to hear it all got borked again.

Thanks much for the report. Fob