Bad news. It appears that the Linksys WPC54G is no longer a good candidate for those looking for a cardbus AirPort Extreme compatible card.
According to Bob (see the end of this comment thread), he just bought a WPC54G "ver 2," and from what ioreg says on his machine, they're no longer using the Broadcom chipset.
To review: To work with Apple's AirPort Extreme driver, a cardbus card must use the same Broadcom 802.11g chipset Apple uses. To check a prospective card, stick it in your machine and run 'ioreg -w 0 -l | more'. Look for it and make sure that the 'compatible' section has an entry that says 'pci14e4,4320'. If it doesn't, take it back and get something else.
Alas, apart from the 1st gen WPC54G, I don't have a first-hand list of working cards. I understand (2nd hand) that the Buffalo cards work. Post comments here if you have a 3rd party 802.11g card you have working and help others!
First, let me say I'm sorry it's been a while since I've updated anything here. I thought it would be of interest to show how to set up WPA easily between Panther and the WAP54G.
I've been wanting to set up WPA to get rid of the security problems of WEP. I noticed that with Panther came support for 802.1x. My WAP54G, with the latest firmware, also supports WPA, so I decided to give it a try.
I started heading down the road of setting up freeradius, but never got to a point where network traffic would actually flow. But along the way, I discovered the so-called "WPA Personal" setting for connecting up. It turns out that this is the same thing as what the WAP54G calls "WPA Shared Key" mode.
So it's trivial to set up. Just tell your WAP54G to use "WPA Shared key", select TKIP, and make up a pass phrase and type it in. Next, pull down from the AirPort icon in the main menu to "Other...". In the pulldown, select "WPA Personal", and type in the network name and passphrase.
One thing that's still unknown is how well this plays with Windows machines. I believe that all you have to do is set up WPA-PSK mode and type in the passphrase. If anyone else has any experience, you might report here (even though this is a MacOS X blog, it's nice to interoperate).
MacCentral (and Yahoo) is reporting that Apple has confirmed what we already know: The AE driver intentionally now works with 3rd party Broadcom-based PCI and CardBus cards.
Apple released AirPort update 3.1 today, and it appears that in addition to final 802.11g standards compliance that Apple has decided to allow their drivers to work with any Broadcom based 802.11g card, be it CardBus or PCI.
Evidence of this can be seen in the stock Info.plist file that comes with the AppleAirPort2.kext. If you look in the <IONameMatch> section, you'll see that it matches Apple's own AE module, and also now pci14e4,4320, which is the chip ID for the Broadcom 802.11g device.
Huzzah! And many thanks to Apple for this unexpected gift!
People are starting to post questions to multiple stories, so here's a place you can use as an impromptu forum for getting help.
Some of the most frequent recent questions and their answers:
If the script says that it isn't finding the correct version of the driver, then you need to uncomment one of the other definitions of $patchloc. This number changes every time Apple recompiles the kext. If you have come across a driver that requires a $patchloc not present in the script, let me know so I can add it. You can determine $patchloc for yourself by carefully examining an ASCII dump of the driver file and looking for pci106b in it somewhere.
When you plug any CardBus or PCCard card into your powerbook, you'll see a card menu show up in the menu bar with the option "Power off card" and the name of the card greyed out. This is normal behavior and has no bearing on whether or not a driver is talking to the card.
If you have an old AirPort card installed in your machine and you use the hack to enable a CardBus or PCI 802.11g card, your network preferences will become confused, as you'll have two "AirPort" cards. You should disable the original AirPort driver by renaming /System/Library/Extensions/AppleAirPort.kext and AppleAirPortFW.kext to ....kext.disabled. Then remove the kext cache files and reboot. You'll be back to just one AirPort interface. It would be really nice if Apple would open up its 802.11 configuration interface so that 3rd party 802.11 cards could be configured the same way as Apple's own. It's sort of sickening to realize that in this area Windows XP is more open than OS X.
Make very, very sure that your 802.11g card is based on the Broadcom 802.11g chipset. If it isn't, it's not going to work. Combo A/G cards won't work either.
Apple released another AirPort software update this evening. This one contains v3.0.4 of AppleAirPort2.kext, but then so did 10.2.5. I guess they recompiled it without changing the version number. Oops. The PERL script has been updated to reflect the new $patchloc (which is 0x4e8ac). After re-applying the patch, the driver works just like it always has.
Enjoy.
I'm using this entry to keep a sort of log of differences I find with the brand new (since 10.2.5 came out) 3.0.4 version of the AirPort Extreme driver.
Already, I've been able to put my access point back into G-only mode, so it appears that they've fixed that.
It also looks like I can disable SSID broadcasts on the access point (meaning you need to know the network name as well as the WEP key to associate).
More as I discover more...
Update! Even more good news! My preliminary fiddling suggests that a lot of the panics relating to removing CardBus cards with the driver active may be fixed. If you have the signal strength icon in the menu bar you may need to open up Internet Connect and toggle the checkbox if it gets stuck in the "X" (hardware missing) state, but apart from that it appears that you can stop and remove the card without blowing anything up.
While I was at work this afternoon, aparently Apple released 10.2.5. Todd Heidesch (look near the bottom) reports that 10.2.5 has updated the AirPort Extreme kext. When I get home, confirm the report and update the script, I'll update this entry.
In the mean time, good work, Todd!
Update: Sure enough, 10.2.5 comes with AppleAirPort2.kext 3.0.4, and changing the $patchloc variable is all that's necessary to fix it.
So here's how you update to 10.2.5:
1. Start a terminal and sudo tcsh. Just let that sit there.
2. Start softwareupdate. Update to 10.2.5 normally. DO NOT reboot or shut down when it's done.
3. Go back to the terminal. cd /System/Library/Extensions/AppleAirPort2.kext/Contents and rm Info.plist.orig Macos/AppleAirPort2_patched. Now you've got a 'virgin' 10.2.5 AppleAirPort2.kext.
4. Modify the $patchloc in the perl script. You'll find the correct one commented out.
5. Run the perl script. It should say 'finished' as always.
6. Reboot.
You can go fetch it here. So far as I can tell, it does not update the AppleAirPort2.kext at all, so so far as I know, you can download and install it with impunity. No word yet on whether it fixes anything important, as I am on the road and away from wireless LANs at the moment.
A lot of comments I've received about the AE hack have been from folks with older PowerBooks saying that they experience a hang on boot with the card installed.
Unfortunately, I've got no information, since I don't have a Wallstreet (the only possibility I can think of is a bug in the CardBus support for the CardBus bridge that machine uses), but if you do, use this entry as a comment area and we'll all get to the bottom of it together.
It was very cool to see the site mentioned on TSS this evening. Brett Larson did an excellent job explaining The Infamous Hack, but there are some things that should be mentioned about his presentation:
su and the root password to get a root shell. With the standard installation of OS X, however, there is no root password set (instead, root is locked). sudo tcsh and specify your password to get a root shell.I was trying to help my friend (all PCs) get his new WAP54G set up this afternoon, and after much gnashing of teeth, I found that there is a new firmware version on the Linksys site that makes mixed mode configuration much more reliable.
So when I got home, I installed it on my WAP54G only to find that the TiBook would no longer associate.
It turns out that the difference was that I told my AP to be "G only" rather than mixed-mode (802.11g and b). My conclusion is that there must be a bug in Apple's driver (since a WPC54G stuck in a winxp box doesn't have the problem) that impacts the way the WAP54G now does G only configuration (because this used to work).
So if you've set up your AP to exclude 802.11b and are having trouble associating, try turning 802.11b compatibility back on.
The Apple AirPort Weblog is reporting that very soon there will be 3rd party drivers for Intersil Prism GT based 802.11g cards. This may make The Infamous Hack a moot point, although 3rd party drivers use different mechanisms for setting up wireless connections (WEP key, SSID, etc).
Enough of the documentation has gotten scattered around the site that it's time to consolidate it a bit. So without further ado, here's the step-by-step instructions for getting Apple's AirPort Extreme driver to talk to 3rd party cards:
pci1737,13". For other devices, you will need to poke around in the output from "ioreg -l -w 0" to find it. Look for devices that mention "14e4" - that's Broadcom's vendor ID. You want the first string in the "compatible" list. Edit the script and change where it says "pci1737,4320" to your replacement ID.sudo perl scriptname (change scriptname to whatever you called the script). It should say "finished" if it did what it needed to do./System/Library/Extensions and rename AppleAirPort.kext and AppleAirPortFW.kext, adding .disabled to the end of their names. This is so that the original AirPort card won't confuse the Network Preferences./System/Library/Extensions.mkext and /System/Library/Extensions.kextcache.Instead of the last step, you could just try using 'kextload,' but there's lots of troubleshooting if it doesn't go exactly right.
If you have a PCI device, and if you start getting panics every time you reboot, try moving the device to another PCI slot.
After the system comes back up, you should be able to use Internet Connect to hook up to the wireless network of your choice.
One corespondent reported that when his WMP54G was in a particular PCI slot, he would get kernel panics from the driver immediately after kextloading it (after the hack was applied). He moved the card to a different slot and the problem went away.
So if you have a PCI card and get panics, try moving the card to another slot.
I suspect this is actually a bug in Apple's code. It probably has to do with Interrupt sharing. I didn't see the panic or look at any of the logs, so I can't really be sure one way or another. Just if you have problems, try another slot.
It occurs to me I haven't done a lot of whacked out speculating in a while, so let me give it a shot.
Those with the PCI variant Linksys device (the WMP54G) may have an opportunity that those of us with the Cardbus device may not.
Remember that the Apple device is mini-PCI. Electrically there is absolutely no difference whatsoever between true mini-PCI and regular PCI. It's all just wiring.
Apple's Airport Extreme module isn't true mini-PCI, but I would not be at all surprised if all they did was rearrange some of the pins and remove some of the unnecessary ones.
Broadcom makes the chips that make up the functional parts of both devices. But both devices have different PCI vendor and device ID numbers. So there's clearly a ROM of some sort (actually according to Broadcom's Product Brief, it's a 1 kilobit ROM with a lot more than just those two numbers).
So the big question of the day is this: how similar are the two implementations? Are they the same except for the contents of the FLASH? If so, then all you'd have to do is reprogram the Linksys card's ROM with the contents of Apple's ROM and all of a sudden it's as if you really do have an actual Apple AirPort Extreme module! The best part of that is that you won't have to engage in the driver hacks to get the driver to work - it will just work!
We CardBus folks aren't so lucky. CardBus devices have a different device identification scheme because of the PCCard legacy they have to live with. So there is no way we'd ever be able to use Apple's FLASH. So the correlary here is that if (when?) Apple releases any "updaters" or other programs that look like they might want to reflash your device, don't do it to your CardBus card! You may be able to do well on a PCI device, but be prepared to have your card destroyed if the reflash procedure doesn't work right.
If you downloaded the perl script before now, fetch it again. It has a bug. But it works now. Promise.
If you downloaded it before now and ran it, then to recover, do one of these two things:
Info.plist with the Info.plist.orig and remove the MacOS/AppleAirPort2_patched executable. You're now back to the 10.2.4 state (or at least the state that existed before you ran the perl script).CFBundleName and CFBundleExecutable. Now you should be in the happy place.Also, if your dmesg output contains the "h/w not supported" message, here's how to recover:
kextunload AppleAirPort2.kextkextload -t AppleAirPort2.kextI've had my first 2nd-hand look at a WMP54G. It appears that it is a different PCI device, perversely enough. So the thing to do is download the perl script, then change the obvious spot near the top from "pci1737,4320" to "pci1737,13"
Also, after running the perl script, you may need to do this:
cd /System/Library/Extensions
kextunload AppleAirPort2.kext
kextload -t AppleAirPort2.kext
It occured to me this morning that if you hadn't loaded the developer tools, you'd be unable to run the C program I so hurredly threw together the night I discovered the 10.2.4 breakage.
So I've tweaked the procedure a little bit and written it in the form of a PERL script. Just download this file and run it as root (you may need to chmod a+x the file to make it executable). It will only run on 10.2.4, and it will only work if you haven't messed with anything. It does some rudimentary checking to make sure the driver is the right version, but as before, if this doesn't work for you, or does something nasty, then you were a fool to trust me. :-)
Silly Apple. Driver tricks aren't for kids.
A ''strings'' on the new 3.0.3 driver discovers a string that is a copy of Apple's "official" device ID. All you need to do is replace their string with Linksys' string, and the driver works just fine again.
You might think this is impossible since the original ID is pci106b,4e and the replacement is pci1737,4320. The replacement is longer. But fortunately, the next string is just the error message that we won't be seeing anymore anyway. No problemo.
So. We need to write a little program to patch the driver so that it checks against "our" device ID. Here it is:
#include <stdio.h>
main() {
long patch_address = 0x4b71c;
int i;
char *write = "pci1737,4320";
FILE *f = fopen("AppleAirPort2_patched","r+");
fseek(f, patch_address, SEEK_SET);
fwrite(write, strlen(write) + 1, 1, f);
fclose(f);
}
You need to cd into AppleAirPort2.kext/Contents/MacOS and cp AppleAirPort2 AppleAirPort2_patched. Then compile and run the above C program. You can verify it worked with strings AppleAirPort2_patched | grep pci1737. You should see it print out the replacement device ID.
Next, replace your Info.plist file with this file.
Now, when you kextload AppleAirPort2.kext, you should see everything work again.
MAKE DAMN SURE that you do this EXACTLY right, or you WILL break something REALLY BADLY. Maybe I will take some time this weekend to make this patch procedure a little more drool-proof, but I wanted to get the word out quickly.
10.2.4 comes with a 3.0.3 version of the AppleAirPort2.kext driver. This driver performs a check on the hardware, and when told to talk to the Linksys card, reports ''AppleAirPort2: h/w not supported''.
I am looking into the situation to see if anything can be done. For now, you might try moving the 3.0.1 AppleAirPort2.kext out of the way before upgrading to 10.2.4 and then moving it back.
An anonymous source has told me that he believes 10.2.4 will ship with the AppleAirPort2.kext driver.
So far as I am aware, there are only two ways to get ahold of a copy of the new Airport Extreme driver so that you can try a Linksys cardbus or PCI card: You can buy a new AirPort Extreme Ready mac or you can buy an AirPort Extreme Base station.
The common denominator is AirPort software 3.01, which (so far as I know) Apple has not put up for download anywhere.
It is possible that the 10.2.4 update may come with AirPort 3.01. I have no idea, but I guess we'll all find out when it becomes available.
Some more data...
If your machine has an old-school AirPort card built in, you may want to disable it. If you don't, the Network Preferences panel may wind up confused. The easiest way I've found is to cd to the Extensions directory, kextunload AppleAirPort.kext, then rename the AppleAirPort.kext and the AppleAirPortFW.kext so that they don't have .kext at the end of their name.
Airport Extreme cards don't seem to be able to connect to FreeBSD machines running 802.11b cards in HostAP mode. Go figure.
If I were you, if you're using the CardBus variants, I wouldn't attempt to power off the card or remove it while the machine is running. I don't think Apple's driver has been set up to deal well with this, given that they didn't consider people using it with hot-swappable hardware. It is safe to sleep your notebook, remove the card, then replace it before you wake. It definately is unsafe to forget to replace it before you wake. What happens is the screen greys out and you get a box telling you in 5 languages that you must power off and restart your system.
If you can get ahold of the AppleAirPort2.kext (and the associated software), you can get a Linksys WPC54G inserted into the cardbus slot to be your Airport Extreme card.
You must edit the AppleAirPort2.kext/Contents/Info.plist file a bit.
You need to copy the <dict> section that talks about the pci device and modify the copy to give it a unique name and a device name of pci1737,4320.
Here is a patch that does the right thing, and here is the final result.
Of course, if this doesn't work for you, or if it damages your machine or anything else, then you were a damn fool to listen to me.
I've learned some more about Airport
Extreme.
ioreg, it also uses the new Broadcom chip. I did some further googling around and I now remain convinced that getting Airport Extreme to work will require nothing more than an Info.plist entry to have the driver find and associate with this card.Apple has introduced 802.11g, or as they call it, Airport Extreme.
It's in the form of a Mini PCI card. 802.11g CardBus cards are available, however. My searches on the net suggest that all of the 802.11g cards out there are probably using the Intersil Prism GT chipset. That suggests that the Airport Extreme driver may be able to talk to the CardBus card by simply teaching it about the device in the Info.plist file of the driver kext. I have a Linksys WPC54G and an Airport Extreme module on order, so I'll have more on this later.
But what about desktop machines? Currently, you can buy a Linksys WMP-11 card, which is a standard 802.11b device. But under the covers, the WMP-11 is a PCI->mini PCI adapter card with an 802.11b antenna!
I have not tried it (yet), but I believe it should be possible to open up the WMP-11, substitute Apple's 802.11g card for the 802.11b module, somehow make an adapter to connect the antenna pigtail from the PCI card to the Apple card, and plug the Frankensteinian contraption into any Desktop mac with PCI and use Apple's drivers to talk to the thing.
Since I don't have a desktop Mac with PCI, but a friend of mine has agreed to plug it in and try it when the parts all arrive.
I got my AirPort Extreme card in the mail today. The news is not good. The interface does not look a thing like the mini PCI interface on the WMP-11, and even worse, the card did not come with any drivers.
That means that either the card is supposed to work with the current drivers or that new drivers will come with 10.2.4. I hope it's the latter. No sign of 10.2.4 yet.