Airport compatible Mac OS X drivers for Intel® wireless adaptors
I have removed the ability to comment on posts, since it was no longer serving a useful purpose.
People can still use the “Ask questions” link on the left side to ask questions which will be publicly answered if needed.
The blog theme has also been updated to be easier on the eyes.
Since not everyone follows the Facebook page I thought I’ll summarize what has been happening with this project since I posted the last blog entry.
As far as VoodooWireless and the HAL architecture is concerned, although it’s nicely designed, we have hit a dead end with regard to functionality and reliability. Unless an entire 802.11 stack is implemented (right now only the bare minimum is implemented), we won’t be having good stable support for most drivers.
To work around that, I started porting OpenBSD’s net80211 stack to Mac OS X a few months ago. The effort so far has been very mechanical, mostly centered on re-implementing missing functions and reducing the number of errors. Nothing has been tested. This is akin to building an entire aircraft on the ground and hoping it flies when you turn it on. But since this was the technique I used for VoodooWireless and 3945 HAL, which worked, I’m quite positive the net80211 port will also work with a little effort.
There is no time estimate yet since I have way lesser time than I did earlier. But as of today, only around 25 compiler errors remain - which means the first stage is almost done. The 2nd stage involves plugging this (hopefully compilable) code into OS X’s IO80211 framework. Since the first stage took around a month, I expect the 2nd stage to take about the same time.
So what I’m saying is that around the end of June we should have a fully functional port of net80211.
As for the features, it supports everything - including WEP,WPA1,WPA2 (Personal only, no Enterprise yet, but I’m sure there should be a way to use Apple’s own RSN supplicant for this), adaptive rate control, automatic roaming etc etc. The real deal. Most of this has already been ported and what remains is plugging it in to OS X’s Airport interface.
After that we also need to port the actual drivers from OpenBSD. This should not be as much work because most net80211 functions will be accessible by the OpenBSD already. Some tweaks might be needed, and we’ll need to convert this to proper IOKit drivers. Let’s see how long that takes, but I’d say no more than a week if I have time.
Those will be released as open source code (BSD licensed) shortly, so that others can fix bugs or improve it, as a stopgap, while I continue working on porting net80211.
Yes this port will support all Intel cards 3945 and up. Maybe I’ll port Intel 2200 also if I have time.
That’s all the updates for now.
Those of you who’ve been following the Facebook updates know about this already
VoodooWireless was successfully updated to be Snow Leopard compatible!**
This is a big success as I never expected to be able to successfully decipher the changes Apple made to the IO80211 classes, and update the header files accordingly. But a lot of reading about C++ ABI and vtables later, I was able to do just that.
So VoodooWireless won’t need any separate GUI and will continue to be fully Airport-compatible — conforming to our goals since the beginning.
Next up, I have made important changes to the Intel 3945 driver. I added support for dynamic transmit rate selection (based on connection quality), recalibration of transmit power based on HW temperature, and a few other important fixes.
These kexts are only for OS X 10.6.2 or higher. You might be able to get it to work on 10.6.0 or 10.6.1 if you modify the Info.plist in the kexts and replace the version numbers of all bundles under OSBundleLibraries section with proper versions of your own kexts (use kextstat command in the Terminal to find proper versions).
Currently the only two limitations of this beta are that 11g mode is not stable at all, and that WEP/WPA/WPA2 are not yet supported. Which basically means only unsecure 11b networks will work with any reliability. Your mileage may vary. However, the previously fixed tx speed of 11mbps has been removed and the card will now adapt the speed as it sees fit based on line condition. The algorithm has been ported from FreeBSD’s Adaptive multirate retry.
In other news, I’ve stopped counting the number of hours I spend on this project, because I no longer think it serves any useful purpose now that releases of the driver are free from any dependence on donation.
When will drivers for 4965, 5100, 5300, 6000 or 1000 be available?
I have not yet started working on those, but plan to start soon.
What about Leopard versions?
My primary development machine is now Snow-Leopard based, so that is what I am developing for right now. Since this is a work in progress, I’m not bothering with compiling several versions for SL, Leo, Tiger etc. However I plan to make versions for each one of them in the near future.
What are you working on now?
Fixing bugs in 3945 driver to allow stable and fast connections for full-speed 11g and 11a networks.
I am also currently looking for ways to port the entire BSD net80211 stack to OS X. That should give us the ability to use the robust BSD wireless drivers with minimal source code modifications, in addition to giving rock solid 802.11 performance and feature set (yes, even WPA/WPA2).
Any time frame for that?
Next several months. This is a big project, essentially ProjectCamphor v2.
Is 2200BG forgotten?
No, but I don’t have much time to work on too many things at once, so it will be updated whenever I have time. My primary machine has a 3945 wireless card so I’m focusing efforts on that.
For any other questions, feel free to post a comment.
After a long break, I’m back to provide updates on the current status and future of this project. We have hit some more roadblocks. In December, planned development was abruptly stopped because the laptop on which I was relying for 3945 testing went dead. It has since been resurrected by capable hands (just tonight), but it’s no longer with me. Anyhow, we’ll go back to the old model of alpha-releases followed by community testing.
I have much less time to spare this year than last, so I must prioritize. In the coming few days, I’ll work on fixing bugs in the 3945 driver (slow speed, heating issues, connection failures). There will be no work on WEP or WPA. The API for writing ciphers was released some months ago as part of VoodooWireless, so if anyone wants to start writing WEP, TKIP or CCMP ciphers meanwhile, it’ll be much appreciated. I’m always available via e-mail if any help is needed. The FreeBSD net80211 architecture already implements these software ciphers. I have mostly based the cipher API on net80211, so it should be a simple port with minor changes. I will only start with WEP/WPA once the majority of bugs in 3945 HAL are fixed so that most people can use unsecured connections stably.
While I was away I got to fiddle with a Macbook with Snow Leopard and Xcode installed. Airport compatibility on Snow Leopard seems to be a distant dream. The SDK no longer includes the crucial apple80211 headers against which VoodooWireless is linked. If it is made available by Apple in the future, all is well and dandy. If not, then the community will have to develop our own GUI for managing the wireless driver. I have no experience with userland graphical tools on OS X, so I will not attempt this myself, but I’m sure there are tons of talented programmers among us who will be able to do it.
First of all, a big thank you to everyone who has donated in the past and to those who plan to donate in the future. I have updated the current donation figures (around ~€550 in total). Given that donations have dried up (likely due to lack of progress since December), a majority of the effort has been put in, and that I am less likely to have as much time to spend on Project:Camphor this year as I did in 2009, I would like to announce that the release of any drivers or source code will be independent of how much donation I receive from now on. In other words, the bounty system is no more, and we’ll move to regular open-source Voodoo-kernel-like development model. As soon as I have updated drivers, they will be offered for download/testing.
With that said, I would still like to encourage everyone to donate if/when they can. It keeps me motivated and I highly appreciate it.
I have decided to gradually release all the source code I have written for this project so far. I began by releasing 2200BG HAL and VoodooWireless SDK. Next, 3945 HAL will be released. If compiling VoodooWireless for Snow Leopard proves difficult for me, its source code will be released so the community can pick up on it.
Yes, there will be drivers for all of those. I will begin writing a unified 4965/5xxx driver in the next few days. How long it takes to get it usable remains to be seen. I expect around a month at least.
Those are all the updates for now. Please keep an eye on the Facebook page for shorter blurbs.
I have released the current version of the VoodooWireless SDK (headers) and the complete source code of the Intel 2200 driver’s HAL.
Click the title of this post to access the Mercurial repository, which can be found at -
http://opensource.mercurysquad.com/
voodoo-wireless-sdk contains the framework you will need to compile and link all HALs based on VoodooWireless. You must put the folder VoodooWireless.framework in your /Library/Frameworks folder. Go through the header files to get an idea of what the API looks like. Your wireless driver will subclass VoodooWirelessDevice class. Also included are headers for writing WEP/WPA ciphers.
voodoo-wireless-hal-intel2200 is the source code for the Intel® 2200BG driver beta 7 (newer than the ones released in kext form on this website). It provides an example driver which you can use to study how VoodooWireless HALs can be written. Feel free to send me improvements as Mercurial changeset bundles.
To develop or use any driver made using VoodooWireless, you need to install the binary kexts VoodooWireless.kext and VoodooWirelessCipher.kext. Currently these can be found in the zip file for the Intel 3945 driver. Source code for these is not released at the moment.
This is important.
The Intel 2200BG source code is currently released under Creative Commons BY-NC-SA license. Which means you can use or modify it for personal projects, and distribute it, provided that you attribute the original work to the author (i.e. me), and do not use it for any commercial purposes.
The VoodooWireless SDK is released with all rights reserved, with some relaxation. It will be relicensed under a more specific license soon, as there will be some major changes to the API in the near future. Currently you are allowed to download the SDK and use it to develop drivers for private use. You may distribute your drivers in binary or source forms. You may not use the SDK for any commercial purpose and you may not modify or redistribute the SDK.
Hope this helps with Intel 2200BG and other wireless driver development. More detailed documentation will be made available in the future.
Click the title of this post to download a fixed version of the kext.
Remove the old kext, install this kext (along with VoodooWireless.kext and VoodooWirelessCipher.kext from the previous package). Then try again.
If it doesn’t work, send me the log via email or pastebin - get the command from the previous blog post.
If Airport turns off while trying to connect, turn it back on a few times until it stays connected.
If you cannot connect at all, try to change your router’s setting .11b-only mode (max 11mbps).
Do not email me asking for help on how to install or load the kext, or for troubleshooting dependency problems. Use Google or other forums.
If the log file is too large, cut out the part from today’s log entries - I am getting 100+ MB log files from people, and find that it contains log entries starting from 1 week ago. I don’t need to see your 7 day old log entries, I need the log entries from the time you tried the new kext.
Since people are eager to test anything that’s available, I’m uploading a pre-alpha version for the Intel 3945 driver. Click this post’s title to download.
You need to install all three kexts for it to work. Rebooting is generally not necessary.
Note that I got this working only a few hours ago, and I am not the one who tested it - so there is absolutely no support. I cannot help if it doesn’t work for you. I need more time to test it better before I claim it as beta-level.
If you want to send me your logs, type this in Terminal:
cat /var/log/system.log | grep Voodoo > ~/Desktop/Intel3945Log.txt
Then right click, Compress, and send it to me by email.
If you get a kernel panic, reboot using bootflags:
keepsyms=1 debug=0x146
then try again and send me a photo of the kernel panic screen. Keep the file size under 500 KB please (no need for ultra high resolution, it should just be readable).
Those who cannot see any new Airport device after installing, make sure you are using 10.5.8 or have the latest IO80211Family kext from 10.5.8. You can get it from here.
Those who are getting kernel panics - it’s a bug in the kext during scan, which I will fix soon.
If your wireless card is not turning on, try flicking the WiFi on-off switch (it might have been off)
Stephen H worked with me to test a couple versions of the driver today and we are reporting success.
Association works. Data transfer works. Surfing works, chatting works. Almost a year’s work seems to have paid off. You can follow the development on the Facebook page as usual, there are a couple more screenshots there.
To be more specific about what works so far (and keep in mind we need more data points soon):
The 3945 driver can scan for all .11b/g networks, connect to open (unsecured) wireless networks, receive data from the access point at any speed and transmit data to the access point at a fixed 11Mbps rate, allowing normal internet access.
As you can see the current “held-together-by-duct-tape” version of the driver is somewhat limited. The reasons are as follows:
Out of these, I will implement the 2nd and 3rd features before uploading a beta version. WEP is next, and then WPA will probably be a whole project of its own.
Since the driver finally works, it’s time to start filling the bounty pot. The time spent so far including everything is 434 hours. That comes to around €8680. I’m thinking of releasing the beta as soon as donations reach €2500, and then working through the remaining features/bug fixes until it reaches whatever the total for that time is. I hope this is a reasonable condition.
Feel free to voice your concerns in the comments.
I am planning to release the VoodooWireless SDK, the Intel 2200BG driver HAL source code, and an empty template project for developing HALs. This will probably be some time in the next 10 days (I need to write some documentation and clean up the code a bit). The 3945 HAL will also be released in due time.
By popular request, I’ve put the Donate link back! I will appreciate your generous monetary contributions to this effort.
(Please note that although 90-95% of the driver is finished, it is still not usable because it cannot - yet - connect to networks. I’m working on it, but I think we have achieved enough progress to warrant putting the link back).
Some stats are mentioned below. Thanks everyone :)
Time spent on each subproject so far, rounded up to the hour, are as follows -
Total time spent: 425 hr
Time for a status update!
If you’ve been following the newsfeed, yesterday I managed to finish a majority of the driver for 3945. We’ve got scanning for networks, reception and transmission of packets working.
The biggest difficulty was to get the card to actually connect to an existing network. Unlike the 2200, for the 3945, it appears that the driver needs to send authentication and association requests via raw 802.11 management frames. Since transmission seems to be working, I played around with this idea and came up with an ad-hoc (no pun intended!) “plan” to get this working quickly. I finished implementing all the 6-7 steps, completing the goal I had in mind. Eventually this whole process is going to be moved out into VoodooWireless (similar to BSDs’ net80211), because the entire Intel wireless range from 3945 onwards seems to need this.
Now the not-so-good news: Steps up to 3rd (authentication response) are working well. The card shows up as ‘authenticated’ on my WiFi router’s information page. However, from here on, the actual association doesn’t work yet. Most of the work now is to debug steps 4 to 7 (specifically step 4 - sending the association request), so that a successful connection can be established. Everything else is in place already, so once this crucial step works, our work is mostly done.
I didn’t have enough time or energy to debug this further as I was going out of town that evening. I suspect that given the time, 2-3 days is the maximum this will take. But note that apparently iwidarwin is also stuck at this same stage. So we could well be in for a blocker. Again, I can’t say if this actually is the case as I’ve not had enough time to investigate this properly.
I don’t have easy access to the 3945 laptop anymore, but I suppose I can still procure it if needed since I’m in the same town for next 2 weeks. We’ll see how that goes; if it doesn’t work out, I still have the long list of interested beta testers, some of whom might receive test versions in the near future.
That said, next few are busy days for me so expect few, if any, updates. Have a good weekend, everyone.
