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).
A while ago, there was much news about the fact that someone who worked at an Apple reseller figured out how to hack iDVD to allow 3rd party drives to work.
Things may have changed now that iDVD has been updated to 3.0.
I have a SuperDrive in my TiBook, so I haven't researched this at all, but I thought I'd open up a category here for it.
If anyone figures out how to make iDVD work with 3rd party drives, I'll be happy to post the details here. You can either remain anonymous or I will give you full credit - your choice.
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.
We start with a bit of a walk through recent history.
Once upon a time, I discovered with a very simple edit to a particular file that I could get Apple's AirPort Extreme driver to talk to a Linksys card. That made me happy. Then Apple released 10.2.4. They added code to that driver to check to make sure that someone didn't do exactly what I had done. That made me angry. I was quickly able to workaround Apple's treachery, and I was happy again, but not quite as happy as before. Because Apple had demonstrated that they were hostile to the idea that we should be able to use their driver with someone else's hardware. Apple wants to force you to buy a new computer to use their driver. That makes me angry. So now I am dedicating myself to doing everything I can to keep them from getting away with trying to keep you from using your mac the way you want, even if it's not with their hardware.
So what can you expect here? I intend to gradually migrate all of the content available at my OS X hints page over to this new site over the coming days (weeks?). First, I plan on cleaning up all of the data I have about The Infamous AirPort Extreme Hack and making a nice, easy to read category out of it all. Stay tuned.
After making any changes to your 10.x kernel extensions, according to various sources, you should remove the files making up your kext cache. The two files are /System/Library/Extensions.mkext and /System/Library/Extensions.kextcache. Remove those two files and they will be rebuilt the next time you reboot. This will fix situations where the driver loads and works, but does not auto-load on reboot, and maybe other situations as well.
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.
I've been in contact with someone at Apple about the JRE test results I posted, and between him and I we've narrowed things down a bit.
In particular, it appears the issue centers around name service lookups. If you call InetAddress.GetByName() with a literal IPv6 address, it works. InetAddress is an abstract base class starting with 1.4.1, and is implemented as either an Inet4Address or an Inet6 Address, and all (most?) of the socket type operations take InetAddress objects and just do the right thing.
However, not everything is perfect. Calling InetAddress.GetByName() with a name that has only an IPv6 address (no IPv4 address) associated with it does not appear to work correctly.
I had to copy a CD (this was at work, and it was an image we owned, so there were no copyright ramifications) today, so I wound up getting a crash course in disk mounting.
disktool is the command line tool for manipulating automatically mounted media, like CDROMs. Before you can use dd to read a CD, you must unmount it. disktool -u disk1s0 will unmount the CD from your desktop. You can then dd if=/dev/disk1s0 bs=2k | dd of=diskname.iso bs=10m will copy the CD into a file called diskname.iso. ISO files can be used by Disk Copy to burn copies.
Once you're done reading the image in, you can use disktool -e disk1s0 to eject the CD.
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.
I don't know where I've been hiding, but aparently Nextel's packet data service has come of age a bit in the last year. Rather than using your Nextel phone to make data calls into your own house/company/ISP (which is slow, costs you minutes and takes an eternity to connect), you can now just use your phone as a connection directly to the Internet.
Of course, Nextel only really supports this on a PC, but it appears to work just fine on *nix machines and a Mac. You have to get your Mac(hine) talking to the phone (Check out the iDen modem script and 232A driver hack), then just tell Internet Connect that the "phone number" is "S=2". All done. I've been getting about 20 kbps or so, with not-great latency. I sort of compare the agregate experience to not-quite-first-generation-Ricochet, but it's the best offer I've had so far...