Configuring the Linksys WUSB54GR on OS X 10.5 Leopard

I spent some time today coaxing my USB wireless adapter to work in OS X 10.5.6 Leopard, and I would like to share my experience (which wasn’t a particularly painless one). I have a WUSB54GR-UK – this is a basic 802.11g adapter which I bought because of (a) Vista compatibility, and (b) cost-effectiveness. Although admittedly, there was an ulterior motive – this adapter contains a Ralink chipset, and in my experience, Ralink provide very good drivers for OS X and Linux. (Maybe it’s just impressive that drivers for anything other than Windows are provided at all!)

After plugging it in the USB adapter shows up in System Profiler under the ‘USB’ category as:

Wireless-G USB Network Adapter
Product ID:    0x0023
Vendor ID:    0x13b1
Version:    0.01
Speed:    Up to 480 Mb/sec
Manufacturer:    Cisco-Linksys
Location ID:    0xfa300000
Current Available (mA):    500
Current Required (mA):    300

A quick google doesn’t return much information about the WUSB54GR and OS X, but if you remove the R there are plenty of hits.

I visit the Ralink support page for Macintosh and find the recommended drivers: USB(RT257x/RT2671). An install, root password confirmation dialog and a reboot later, the UsbWirelessUtility doesn’t see a device. Great.

Beginning to wonder whether I’m out of luck with this adapter, and it’s not a Ralink at all (which could be, because versions of the WUSB54G prior to v4 were Broadcom devices), I find the Kismac-ng Trac page which confirms the adapter as RT73. Sigh of relief, but no closer to the goal. After checking kextstat, the equivalent of lsmod in OS X, I find the RT2500 kext absent from the loaded list, and begin to suspect that the USB device/vendor ID matching mechanism is not linking this device to the right driver. A quick check of ioreg supports that theory – the Wireless-G adapter is given a generic USB driver, and nothing else.

Google gives some posts on InsanelyMac from 2006 which recommend changing Info.plist for the kext, but after some tinkering I noticed the USB product code recommended for the WUSB54G v4 is different from what System Profiler shows. A couple of reboots later, and still no show – even though ioreg has the adapter’s driver status as matched. Close, but not close enough – I decide to take a look at similar adapters, in particular, the WUSB54GS. This has a product code of 0x20, admittedly closer than 0xd – and the plist example given in Google’s cache indicates that I’m probably using the wrong portion of the driver for my adapter. I change it, and a reboot later wireless works. Question: why does this have to more painful than needed – is it too hard for Ralink to add the relevant section to their drivers?

Here then are the instructions to get this adapter to work. I am assuming you have already installed the correct drivers. Open up Terminal and switch to root user by typing in sudo su - and your password when prompted. Edit the kext’s plist file nano /System/Library/Extensions/RT2500USBWirelessDriver.kext/Contents/Info.plist. The beginning of the file should look like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>RT2500USBWirelessDriver</string>
<key>CFBundleIdentifier</key>
<string>com.Ralink.driver.RT2500</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleShortVersionString</key>
<string>1.1.3.0</string>
<key>CFBundleSignature</key>
<string>Lens Wang</string>
<key>CFBundleVersion</key>
<string>1.1.3</string>
<key>IOKitPersonalities</key>
<dict>

Press Enter, then add the following lines:

<key>Cisco-Linksys</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.Ralink.driver.RT73</string>
<key>IOClass</key>
<string>RT2573USBWirelessDriver</string>
<key>IOProviderClass</key>
<string>IOUSBDevice</string>
<key>bcdDevice</key>
<integer>1</integer>
<key>idProduct</key>
<integer>35</integer>
<key>idVendor</key>
<integer>5041</integer>
</dict>

The next line ought to read <key>ALPHA</key>. Press Ctrl-X, press Y to confirm saving, and nano will exit. Before rebooting, the kext cache needs to be flushed, so run the following lines in the Terminal you have open:

chown -R root:wheel /System/Library/Extensions
chmod -R 755 /System/Library/Extensions
kextcache -k /System/Library/Extensions
diskutil repairPermissions /

Reboot, and enjoy!

P.S. If you don’t yet know about AppleJack, now is the time to find out about this useful little utility. A somewhat interesting point is that when I installed Windows 7 RC1 recently, the drivers for this adapter were automatically installed and it “just worked”. That, Apple, is perhaps something to think about, even as Mac market share is relatively steady through the recession. Operating Systems are for allowing hardware to function, not for restricting arbitrarily what hardware can function.