Since the Atheros acquisition, introduction of new ZyDAS ZD1211 USB-wireless devices has been concerningly slow.

Fortunately, some new ZD1211 devices have been popping up recently, based on new radio chips. After some help from the community, I managed to get my hands on the new types and write zd1211rw code needed to support these chips.

The first new chip, the AL2230S, only needed a few changes on top of the older AL2230 code. This radio is working well.

The second new chip is especially interesting: the Ubec UW2453. Ubec publish full technical specs for this chip, so we’re able to understand more than usual about the ZD1211 interactions with the radio. Maybe due to it’s complexity, the UW2453 isn’t performing quite as well as the other radios, but this should improve after time. I emailed ZyDAS some feedback about their UW2453 programming code – I think I spotted a few mistakes.

Third, we started seeing the already-supported AL7230B RF chip being combined with the ZD1211B base chip on some newer ZyXEL products. This particular combination was not supported before, but thanks to some testers on the mailing lists, the code has been written and submitted to support these.

Fourth, Atheros appear to have rebranded the ZD1211B chip as AR5007UG. These devices are appearing in Medion laptops, very popular in some parts of Europe. The first ones seem to be based on the UW2453 RF mentioned above. I’m especially interested to hear from people who have AR5007UG devices in other laptops or in standalone USB-dongle form, and also if they exist based on other RF chips.

All the above will be available in Linux 2.6.22, except UW2453/AR5007UG which will be available in 2.6.23.

On a final note, I moved the zd1211rw homepage to the new linuxwireless.org wiki. One nice feature here is that the zd1211rw supported devices list gets aggregated onto the more general Linux-supported USB wireless devices list, however we’re the only USB driver with device information published there at the moment.

ketchup is a neat utility to download and unpack a specific version of the Linux kernel sources into the current directory. It also does rather well on saving download bandwidth, i.e. if you have the 2.6.17 source tarball and ask for 2.6.18, it will only download the 2.6.17-to-2.6.18 patch.

Here’s a quick usage example, which installs the 2.6.21-rc7 kernel sources:

# emerge ketchup
# cd /usr/src
# mkdir linux-2.6.21-rc7
# cd linux-2.6.21-rc7
# ketchup 2.6.21-rc7

When ketchup has finished, you then have a clean set of kernel sources for that particular version in front of you.

I like to configure ketchup to use the same storage directory as portage, so that they can share kernel tarballs. In my ~/.ketchuprc I have:

archive = "/usr/portage/distfiles"

Earlier this month, I met with 25 other contributors at the 2nd Linux Wireless Summit. This was a followup from the 2006 summit.

The meeting happened in London and was scheduled to occur immediately after the IEEE 802.11 working group meeting. This enabled us to get some kind of vendor attendance.

While we had this opportunity, one of the biggest topics was discussion of why vendors still aren’t playing nice in releasing open source drivers (or providing the resources to let the community do so). The vendors in the room confirmed our suspicions – vendors are afraid of the FCC and other regulatory agencies who place restrictions on frequencies and power levels which these devices are legally allowed to transmit as.

Matt Norwood from the Software Freedom Law Center was in attendance and had studied the FCC regulations in some detail. The conclusion is that the FCC rules are vague and while they don’t explicitly say that open source drivers are not allowed, vendors are not prepared to risk falling out of compliance and are playing it safe (or not playing at all). Unfortunately there is no short term solution to this: it would take years for the FCC to clarify the regulations. Short term workarounds such as finding ways to encourage vendors to produce open drivers with only the regulatory part closed (such as Intel’s ipw3945 offering) are under investigation.

The other large topic was the merge of the new wireless stack (d80211) which was donated to the community by Devicescape. The stack has many more features than the current in-kernel ieee80211/softmac stack, and improves consistency between drivers. We are now much closer to getting d80211 merged into mainline Linux, but there are still some significant technical issues to be resolved.

Before the conference, several people asked me if I could raise issues with the suckiness of Intel’s ipw3945 driver offering in that it relies on this awkward closed-source userspace daemon. Fortunately Intel have found a way to rewrite their firmware so that the regulatory domain control is no longer at the driver level, therefore a fully open-source driver with no binary userspace part has been developed (iwlwifi). Although Intel have not yet announced it, the source code has been released here. This rewritten driver uses the d80211 stack mentioned above, so it’s not possible just to compile it against mainline Linux at the moment. The iwlwifi website includes instructions for how to check out the wireless-dev tree where d80211 is being held.

All slides and notes from the conference can be found here. Stephen Hemminger wrote a more detailed summary. Also, one other significant product of the summit was a central information source aimed at Linux wireless users – we have now launched linuxwireless.org.