Project: Camphor

Updates and future of Project:Camphor

Thu, 11 Feb 2010 02:44:00 +0530

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.

Current status of 3945 HAL

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.

Snow Leopard compatibility

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.

About donations

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.

Source code release

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.

About 4965/5-series/6-series/1-series Intel WiFi cards

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.

VoodooWireless SDK and Intel 2200 HAL source code release

Thu, 03 Dec 2009 19:32:00 +0530

VoodooWireless SDK and Intel 2200 HAL source code release:

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.

Licensing

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.

For those who got kernel panics with the previous kext

Fri, 20 Nov 2009 02:15:00 +0530

For those who got kernel panics with the previous kext:

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.

Voodoo Intel 3945: pre-alpha download

Sat, 14 Nov 2009 07:32:00 +0530

Voodoo Intel 3945: pre-alpha download:

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.

Leopard only (no Snow Leopard yet)
Open networks only (no WEP, no WPA, no shared authentication)
.11b/g networks only (no .11a)
Transmit rate is fixed at 11Mbps
Transmit power is not temperature calibrated

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).

Hints

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)

Preparing to land: Intel 3945 for OS X is here!

Sat, 14 Nov 2009 03:19:00 +0530

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.

What exactly works

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:

I don’t have a .11a router and have never used it, so the support for .11a mode is sketchy at best, and the 3945 HAL ignores it.
The WEP cipher is implemented but has some bugs preventing it from working properly.
The WPA cipher does not yet exist.
The rate is fixed at 11mbps because I have not yet implemented the dynamic rate scaling algorithm based on transmission characteristics

What’s left to do

WEP and WPA
Dynamic rate scaler to allow use of all transmission speeds from 1Mbps to 54Mbps (packets can be received at any rate)
Dynamic transmit power scaling based on hardware temperature
Bug fixing, Ad-hoc mode etc.

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.

Bounty pot

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.

Source code release

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.

Donation link is back

Sat, 24 Oct 2009 20:38:00 +0530

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 logs

Time spent on each subproject so far, rounded up to the hour, are as follows -

Intel 2200BG original driver (beta5) : 290 hr
VoodooWireless : 67 hr
Intel 2200BG HAL port: 11 hr
Intel 3945 HAL: 57 hr

Total time spent: 425 hr

Updates on 3945 driver HAL

Sat, 24 Oct 2009 20:28:00 +0530

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.

Marathon coding: get set go

Sat, 10 Oct 2009 15:23:00 +0530

Quick note to say that I have the 3945 laptop for 1 week now, and marathon coding for next 6 days has started. By next Sunday 18 Oct, the driver will either work, or it will not work.

Please use this page for up-to-minute information.

Update 18 Oct 2009:

From the facebook page I hope people are aware that 65-70% of the driver is finished. However, there are issues with system freeze on repeated power on/off, and scanning for networks currently has some bugs according to the firmware. In other words, the driver is not functional by the deadline we had.

Thankfully though, I still have access to the laptop for 4-5 days further. So I shall continue working on the driver and see how far we get. I’m hoping at least unsecured connection is working by then! As usual, more up-to-the-minute updates are posted on the FB page linked above. Cheers!

3945 HAL updates & comparison with 2200

Mon, 14 Sep 2009 08:17:00 +0530

It’s about time I consolidated the previous status updates into a blog entry of its own for those not following the facebook page.

Around 20% of the HAL is coded by now. Lots of support functions were first written, followed by code for uploading firmware and microcode to the card. A particularly nasty bug with VoodooWireless was also tracked down and fixed which was causing kernel panics on scans yielding no results.

What’s left now for completion of Stage 1 (i.e. firmware stage) is to finish implementing the allocation and initialization of Rx, Tx and command rings. Once this is done, the driver will be able to turn the card on or off, load the firmware and make it ready or action. Those following the project for 2200BG driver will remember that this was a major part of the work for that driver — once this was completed and working, the rest was simply a matter of time.

Comparison between 3945 and 2200

It’s interesting to compare the two cards to see what will be different for 3945 HAL compared to the experience of writing driver for 2200.

The 3945 is actually a 100% Intel-designed wireless card (partly to avoid licensing issues), so it differs in many ways from the 2200BG. Incidentally, although the Stage 1 code for 3945 is simpler than 2200, most of the things following that are more complicated. They moved a lot of work out of the hardware and put it into software - for example, to scan for networks, in 2200 you just prepared the scan parameters and channel list and sent the scan command to the hardware. In 3945 from what I can see so far, you have to manually create the actual probe request that is sent, then switch the channels manually to scan for each.

There are also some other changes - in 2200, the firmware automatically chose the best transmit rate so the driver didn’t have to do anything other than send the packet out. In 3945, the firmware doesn’t do this and the driver has to actually configure the tx data rates itself, mostly based on the adapter’s temperature checked every minute.

So all in all, the amount of code reduced in Stage 1 (firmware stage) is basically balanced (actually exceeded by a small amount) by the increase in code in Stage 2.

ETA

Currently we have clocked about 11 hours for the 3945 HAL. My expectation is that it will take around 40 to 50 hours to finish, which leaves at least around 30 more hours of work before it can go into beta.

Testing

In other news, fassl from Voodoo Labs, who worked on much of the Chameleon GUI, has offered to help his expertise in alpha-and-beta testing of the 3945 HAL. Since I am well aware of his expertise and prefer to keep things in-house, at least until stage 1 is done, I plan to work with him exclusively for testing. Afterwards we’ll use the loooong beta testers list I’ve compiled from your emails.

That’s all the updates for now. It is likely that Stage 1 will be completed in the next couple of days. News will be provided as and when it happens. Thanks for staying with me patiently.

Misc

The donation link is gone until 3945 HAL is finished. What would you guys’ opinion be on putting Google Ads on the blog?

Facebook page and smaller updates!

Sat, 05 Sep 2009 19:13:09 +0530

Many people asked me to create twitter account so they could follow up-to-the-minute progress. So I created a facebook page instead because my twitter account is for personal use :P

The FB page offers more features like photo albums and discussion in addition to twitter-like short updates. Feel free to subscribe to it. This blog will contain only more major updates.

mercurysquad on Facebook

As for progress: firmware upload is still being worked upon, should be done today.

Hell hath begun

Wed, 02 Sep 2009 01:33:06 +0530

Just got done with creating the 3945 HAL template based on VoodooWireless. There is barely any hardware-specific code in it right now, but the kext project and the subclassed functions are there with a few basic (getHardwareInfo() etc.) functions implemented. Firmware is converted. From here on, it’s a lot of mechanical work with a little bit of careful thinking and added technique, to finish implementing the remaining 10 or so hardware-specific functions.

This is gonna be one hell of a ride because I can’t test anything until I finish coding all of it, and even then it’ll be external testers. Exciting! :-D Expecting to finish it in a few days (depending on any difficulties encountered during the course, and how busy I am), and then beta testing can begin. (Alert: beta testers who sent me an email, you might receive a beta driver from me this week.)

NOTE: For the umpteenth time, please do NOT send me ANY MORE emails asking to be a beta tester. Every day I get a few emails, and right now I must have like 60-70 people on the list, maybe more. Out of those I have chosen only 3 or 4 who will participate in the test initially, based on their credentials. As the hardware is going to be the same for all, I don’t need 200 testers during this phase. So the rest of the list is “reserve.”

Updates will continue during the next few days of heavy-weight coding, of course.

Updates on VoodooWireless bugfix

Fri, 28 Aug 2009 22:32:00 +0530

As everyone probably knows, VoodooWireless is the major component which allows a hardware abstraction layer for a card to talk with OS X. This layer implements a nano-sized 802.11 (Wifi) stack and handles all Airport-related stuff. Few weeks ago I posted that this part was completed, and I’m trying to fix some bugs in it.

Today the bug with packet transmission was fixed (it was an incorrectly copied BSSID address in the wifi header - Apple’s association requests typically zero out the BSSID and the driver must scan for that on its own). Once that was fixed, the 2200 HAL was able to get an IP address and small packets were flowing.

But larger packets weren’t, and so web surfing or any non-trivial network activity wasn’t working. Further testing showed a very peculiar behaviour : Packets up to length 168 were being transmitted fine, but those from length 169 onwards were not. Turns out to be a problem in Apple networking stack (I think so), where the larger packets are not coalesced into one mbuf before being sent to VoodooWireless.

So those are the updates for now - currently trying to fix the problem with un-coalesced packets. After this, there is one little To-Do left with the scan results handling part.

UPDATE (40min later): OK, the large-packet coalesce bug is fixed. Had to manually coalesce the mbuf chain, but it works. I’m now online via the totally rewritten VoodooWireless + 2200BG HAL architecture! :-)

So now I’ll make the small scan-handling change and then 3945 is probably only a few days away.

Out of town again

Wed, 19 Aug 2009 16:41:00 +0530

Hey guys, sorry for the lack of activity recently. I’m out of town these days. Progress update will come when there’s something worthwhile to report. 3945 target is still within this month I hope.

And two reminders —

I am not looking for any more beta testers!
I am not looking for a 3945 card because it is incompatible with my laptop!

Oh and one more thing: All the early donators deserve another big thank you — my laptop screen’s hinge got broken a few days ago and it’s literally just hanging on one hinge. But thanks to the donations I was able to immediately order a replacement set which should arrive by the time I get home [this weekend] so no interruption in coding :) Thank you all.

Thanks to all those who emailed

Sat, 08 Aug 2009 21:30:00 +0530

I now have enough interested testers. Even if you didn’t get a reply directly, if you’ve emailed me, you are added to the pool of testers. There are some who I have contacted directly, who are first in line to get any beta versions when required. If they disappear or are otherwise unable to test, others from the pool will be contacted.

Progress

As a test case I’ve ported the 2200BG driver to VoodooWireless — the hardware-specific driver code is now a paltry 1550 lines of code! This is the smallest out of all existing drivers for this wireless adapter — less than half of the size of the FreeBSD driver, and 10% the size of the Linux driver! Adding support for Ad-Hoc mode should take no more than 200 lines of code in the HAL (and some more in VoodooWireless). WEP and WPA support can theoretically be added without modifying the HAL at all.

Unfortunately there are some bugs remaining in VoodooWireless. The scanning part is working well but there is some bug with transmission of packets. I’m currently trying to debug those.

3945 HAL is currently blocked on this, as the bug with packet Tx could be either in VoodooWireless or the 2200 HAL.

In any case, I’m moving towards having a working 3945 driver this month:)

VoodooWireless is now completed

Mon, 03 Aug 2009 02:50:46 +0530

Testing still remains, but the coding part is done.

Some statistics:

Lines of Code — Total: 2736, VoodooWireless only: 2200, VoodooWireless Ciphers only: 536 (WEP encryption only right now, decryption and WPA to be added later)
Time taken: 58 hr 45 min
Lines of code / hour = about 46

The API is basically finalized and I don’t envision any changes immediately, except of course when new features like WPA, hardware crypto, .11n or Ad-Hoc mode are added. For a first version I decided to only implement .11b/g (.11a will come soon) connections with WEP in Infrastructure mode. This should cover a lot of users already.

A clipping of the eight (8) hardware-specific functions that HAL writers will need to implement —

Next in line are:

Port over the existing 2200BG driver to VoodooWireless and make sure no bugs remain in it. Now I know people will be up in arms about this, but there is no other way to test that the VoodooWireless code actually works. This might take a day or two.
When I’m convinced the code works, I’ll port over the FreeBSD wpi driver for the 3945ABG card. This will probably take 4 or 5 days.

Looking for 3945 testers

Now, something important. The inevitable has happened and I no longer have access to the 3945 card anymore. That means I’ll need to code it blind and rely on external testers. Coding part shouldn’t be that difficult anymore (I hope), but the testing probably will be so.

I’m looking for 2 or 3 experienced testers for 3945. The criterion is that you should have a good understanding of how OS X works, how wireless networks work, and how to debug driver issues (e.g. I will not tell you how to load the test drivers, or what to do when you get a kernel panic, or how to change your router settings). The second criterion is that you must be available and able to respond to emails and send test results fast. I’m talking 10 test versions of the driver a day, or something in its vicinity. I usually test drivers 20 times a day! If I rely on external testers, I don’t want to be waiting all day for a test report.

If you think you fit the criteria, and want to help with testing, write me an email at voodoo@mercurysquad.com. I am expecting a lot of messages; so to help me pick, please include any past testing/coding experience or similar information.

NOTE: Just to stay clear, there is NO alpha or beta driver for 3945 yet! The coding/testing will run in parallel all this week.

VoodooWireless is nearing completion

Thu, 30 Jul 2009 18:02:31 +0530

Just a quick update.

The hardware-independent part of VoodooWireless framework is almost completed. What remains is handling of scan results, and handling the various apple80211Request() function calls and mapping relevant ones to hardware-dependent functions.

Out of these the first part is somewhat complicated as a lot of decisions need to be taken on which results to store, for how long, when to renew them, which ones to send to Airport, which ones to choose while associating, and so on. The second part is more mechanical work, as there are something like 25-30 message types to respond to (or map to hardware-dependent function calls).

Once these are done, the hardware-dependent parts of the HAL (for 3945) will be written. I’ve gone through the FreeBSD wpi driver already during my trip last week, and have a somewhat clear idea of how this card works. It is different than 2200BG in many respects, but also similar in many other respects. Some things that the 2200BG firmware handled for us, need to be handled in software for the 3945 (like manually creating probe request frames for scanning). But other things are more streamlined that 2200BG.

All in all, it should be an interesting experience. Let’s see how long it takes to complete.

Total time logged so far is 336 hours, out of which 46 hours have been spent working on the “new” architecture.

Preview of VoodooWireless API

Tue, 28 Jul 2009 20:48:25 +0530

I’m publishing here an early preview of the API used to create wireless device HALs for VoodooWireless.

There have been many big changes from the initial API that I designed. The most important change is that the HALs will no longer be a provider nub for the VoodooAirportBridge client — that design got way too complicated, for both development and testing, from the client’s as well as the provider’s points of view.

The simplified design is a ‘superclass’ which derives from IO80211Controller. HALs will need to derive from this subclass and implement some hardware-specific functions. HALs will need to call some functions provided by the superclass when events happen (like card is turned off, scanning is completed, or data is received).

Most of the hard work will be handled by the VoodooWirelessDevice superclass, and HALs will typically only need to implement hardware-specific code. For example, driver writers will not need to worry about parsing probe responses to get scan results and network information — they simply pass the incoming packets up to the superclass which will take care of the rest.

Given below is source code of most header files that will be used during development of HALs. Hope this is useful to those who are planning to help write HALs for cards like 4965 or 5100.

IMPORTANT: All this source code is made available for preview/academic purpose only and the copyright remains with me (the author).

Click to view the source code

Note that it is not always possible to finalize the APIs before starting to use it. So, big and small changes are expected. To repeat myself: this is only a preview designed to give prospective developers an idea of how the final API might look like.

Back

Mon, 27 Jul 2009 10:54:34 +0530

I am back now and work on 3945 has started.

No other updates currently, it’s still in very early stages.

Beta v05 of 2200BG driver and goodbye for a few days

Tue, 14 Jul 2009 11:49:00 +0530

A slightly updated and bug-fixed version of the 2200BG® driver is available from the Download page now.

It has many small and big fixes which I don’t have time to describe in detail now, but in brief:

Fixed bug in setting antenna sensitivity to large dBm values. Connections should be more stable now. Also changed antenna to “auto” (firmware selects best antenna) instead of “slow diversity” - should provide better reception in weak signal.
Fixed some transmit queue related problems: freeing mbufs and transmitting mbufs is now more robust in laggy connections.
Now using just the first Tx queue instead of all four: to try to get rid of firmware resets during heavy transfer while using WEP.
Changes in background scan watchdog, but it doesn’t work well yet.
Misc fixes..

Estimate time of availability for 3945 driver and WPA support

ETA for 3945: this is a blind guess but I’m hoping to get it working with WEP by the end of the month.

ETA for WPA: this will take more time that I had thought, so it’s postponed until 3945+WEP is working. (Note: WPA support will be common to all drivers so it only needs to be written once).

Getting debug logs

If you want to investigate any problems with the 2200bg kext, you can get extended debug logs in your Console by setting a sysctl key as follows (in Terminal):

sudo sysctl -w debug.voodoowireless=xx

Replace xx with any sum of the following values to selectively display debug messages:

    dbgUnused   = 1,        // (currently unused)
    dbgFatal    = 2,        // Fatal/abort errors
    dbgWarning  = 4,        // Warning messages
    dbgInfo     = 8,        // General informational messages
    dbgIoctl    = 16,       // apple80211request messages
    dbgRxTx     = 32,       // Rx/tx of packets
    dbgBeacons  = 64,       // incoming beacons
    dbgEntryExit    = 128,      // Function entry and exit logs
    dbgDump     = 256,      // rx/tx packet dumps
    dbgEverything   = 0xFFFFFFFF    // All levels of debugging

The most useful value is 14 (ie. display Fatal errors, warnings and useful information).

That said, I won’t be available for the next few days, so no updates or responses to comments. Have a good week everyone.

Just one last update to the 'old' 2200BG driver

Thu, 09 Jul 2009 21:09:00 +0530

I have uploaded beta version 04 of the driver for 2200BG. Everyone is advised to update.

This version fixes a very important bug in previous versions which was preventing the card from connecting in 11g and working at full speeds.

It is available from the Downloads page.

Note that in WEP networks during long transfers at high speeds, I have experienced frequent firmware errors resulting in the driver shutting down the card. If this happens with you, either lower the maximum connection speed in your access point’s configuration, or use the debug.wirelessmode sysctl key to force the driver to always connect at 11b speeds only.

By default the driver prefers 11g mode if available.