Atheros AR5BXB6 wireless card

[random01]

Gents,
 
Thanks to all so far, regarding all of the help in getting my Dell D630 x3100 Low-Res (1280x800) 'airborne' on Lion.
 
(Hervé, especially Mate - My hat's off, my son - my hat is well and truly off! You are a true Gentleman and Guru! That D630 Bootpack you threw at me, along with your additional advice to resolve my boot-up issues - has resulted in a D630 that just simply 'hummmms' on Lion v10.7.5!)
 
Now needless to say, the Dell factory-fitted 'Intel' MiniPCIe Wi-Fi Card - (a Dell '0NC293' 802.11a/b/g Card to be precise) - simply ain't gonna fly... I do however, have an old Early-2006 MacBook - (2.0GHz Core Duo, NOT Core2 Duo) - which has been 'retired' for a while now. It has a genuine Apple MiniPCIe WiFi Card in it - an AR5XB6, (based around the AR5424 Chipset which delivers 802.11a/b/g) - and because I'm such a fan of 'e-cycling', I'd love to be able to use it!
 
The Dell factory-fitted 'Intel' Card on the Left, and the Genuine Apple AR5XB6 Card on the right.
(Again, sorry for the high-res image, just ensuring the necessary detail is present-and-accounted-for)
 
 
This Genuine Apple Card isn't currently listed on the above Compatibility List - as yup, granted - this Card is from a MacBook that can't, (read, 'isn't supposed too'), go beyond Snow Leopard. I've already changed the BIOS in the D630 to re-allow WiFi, installed this Card and rebooted, but denied - no 'OOB' joy...

Running 'lspci -nn', from within Terminal, revealed the following information - verbatim:

'0c:00.0 Ethernet controller  [200]:  Atheros Communications Inc.  AR242x / AR542x Wireless Network Adapter  (PCI-Express)  [168c:001c]  (rev 01)'

Running 'lspci -v', revealed the following information - again, verbatim:

'0c:00.0 Ethernet controller  [200]:  Atheros Communications Inc.  AR242x / AR542x Wireless Network Adapter  (PCI-Express)  [168c:001c]  (rev 01)
              Subsystem:  Apple Inc.  AR5BXB6 802.11abg Wireless MiniPCIe Card
              Flags:  bus master,  fast devsel,  latency 0,  IRQ 16
              Memory at f6cf0000  (64-bit,  non-prefetchable)
              Capabilities:  [40]  Power Management version 2
              Capabilities:  [50]  Message Signalled Interupts:  Mask- 64bit- Queue=0/0 Enable-
              Capabilities:  [60]  Express Legacy Endpoint,  MSI 00
              Capabilities:  [90]  MSI-X:  Enable- Mask- TabSize=1
              Capabilities:  [100]  #168c
              Capabilities:  [001]  #1c16
              Capabilities:  [470]  #4b
              Capabilities:  [101]  #1c16
              Capabilities:  [470]  <chain looped>'

What extra information do you guys need from me / from this Card, which would allow me to wrap up this build, and also allow this Card to be added to your Compatibility List? Let me know.
 
Forever impressed and thanks once again in advance.

[Hervé]

You can always try to patch the vanilla Atheros kext. One easy and safe way to do this is to make a copy of the vanilla AirportAtheros40.kext on the desktop (it should be a PlugIn of /S/L/E/IONetworking or /S/L/E/IO80211Family kext - can't remember off-hand) and patch it with your card's PCI ids (168c,001c). Then move the patched kext to /E/E and re-run myFix (quick).

[Bronxteck]

make sure the wifi switch is on also boot without caches to see if the kext just needs a reload into kernelcache.

[random01]

Mario,

 

I just pretended to know what the pair of you Gurus are talking about, so the first thing I did BEFORE REMOVING the Dell factory-fitted WiFi Card - was have a look within System Profiler - (have a look here):

 

Now, once I had replaced the Dell factory-fitted WiFi Card - with the Genuine Apple AR5BXB6 WiFi Card, I rebooted both with and without Cache from the Chameleon prompt. Immediately, using 'lspci -nn' from within Terminal - I was able to confirm without fail, that the new Apple WiFi Card had indeed taken, but looking back inside System Profiler, nothing had changed - and still nothing inside System Preferences / Networking was found to reflect the new Card.

 

Next step, the attack as directed by Hervé.

 

Located the 'offending' Kext - the vanilla AirportAtheros40.kext, (which was located - as advertised - within the PlugIns Folder of IO80211Family.kext). I made a copy of this Kext onto the Desktop and as instructed, right-moused on this Kext and selected 'Show Contents' - (I assume that's what you are supposed to do…). Looking inside, the only 'file' I could see that contained anything even relevant to the task at hand was the 'Info.plist' file - contents of which, as below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
[...]
[...]
[...]
<key>Atheros Wireless LAN PCI</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.AirPort.Atheros40</string>
<key>IOClass</key>
<string>AirPort_AtherosNewma40</string>
<key>IOMatchCategory</key>
<string>IODefaultMatchCategory</string>
<key>IONameMatch</key>
<array>
<string>pci168c,30</string>
<string>pci168c,2a</string>
</array>
[...]
[...]
[...]
</plist>

Noting the variables that I have highlighted with bold - I knew I was on the right track.

 

Dragging a copy of this 'Info.plist' file out of this Kext onto the Desktop as well, I opened the 'Info.plist' file from within Terminal using 'sudo nano', (simply the best Terminal-based editor - as is doesn't affect ownership upon exiting!): 'sudo nano /Users/User-Name/Desktop/Info.plist'

 

All I did, after noting that the two existing Hardware Devices within this file DID NOT have leading zeros, was add the following line - (read, the Bold and Italic, below the two Bold entries):

<string>IODefaultMatchCategory</string>
<key>IONameMatch</key>
<array>
<string>pci168c,30</string>
<string>pci168c,2a</string>
<string>pci168c,1c</string>
</array>
<key>IOProbeScore</key>
<integer>505</integer>
<key>IOProviderClass</key>

I then, wrote 'out' to the file, and to be sure the changes 'took, re-opened it to clarify - All was well.

 

As directed, selected 'Show Contents' of the Desktop-copied AirportAtheros40.kext, navigated to within its PlugIns Folder - and replaced the existing 'Info.plist' file with my amended version. I then moved this amended Kext into the /Extras/Extension Folder, launched myHack v2.2 / entered my 'sudo password/ and chose 'Run myFix' / 'QuickFix'

 

myHack ran riot - and upon completion, I rebooted again both with and without Caches - both occasions failing to reveal any joy within System Preferences / Networking OR System Profiler - (still showing the same device as per the pic above…)

 

Further investigations revealed that myHack had in fact FAILED to 'update' the vanilla AirportAtheros40.kext along with its embedded 'Info.plist' file, all located within the original IO80211Family.kext, - from the 'changed version' that I had placed within /Extras/Extensions - to effect my intended changes.

 

Now - I don't know if manually 'dropping in' the amended Info.plist file directly - without using myHack - is OK to do, but that was my next attack vector.

 

This time at least, upon manually dumping in the amended 'Info.plist' file directly into the vanilla AirportAtheros40.kext, (located within the original IO80211Family.kext), resulted in my changes sticking tight.

 

Next, I ensured that both the vanilla AirportAtheros40.kext AND the 'modified' AirportAtheros40.kext placed within the /Extra/Extensions Folder WERE BOTH IN THE SAME MODIFIED STATE, (with the original unmodified vanilla AirportAtheros40.kext, backed-up for safety)

 

I then re-lit myHack v2.2, again selected 'myFix' and set about letting it run wild with a 'Full' deep fix - reasoning that at least if both Kexts were identical, then it wouldn't matter.

 

Once it had wrapped up ensuring that all permissions were repaired and such - I rebooted, again both with and without Cache from Chameleon - and yup, you guessed it - no joy in either System Preferences / Networking, or again within System Profiler - (the same Hardware as found within the above pic…)

 

Just to be triple-confident, I repeated the entire procedure ALL OVER AGAIN from the top - in all of its incarnations - only this time, i utilised the full Hardware ID instead of the abbreviated one;

• Initial - <string>pci168c,1c</string>
• Amended to - <string>pci168c,001c</string>

 

Once completely through every incarnation of the above steps, (with the 'new' string entry) - here I still stand, still with no joy...

(No change within either System Preferences / Networking - along with the same System Profiler status, as pic'd above.)

 

What am I, or have I - done wrong?

 

Regards, and thanks again - in advance...

[random01]

Uh-Oh and Doh!

 

After just finishing the Post I made above - I've just stumbled across Conti's Topic, surrounding how to patch Lion's 'AppleRTC.kext' - as per here: https://osxlatitude.com/index.php?/topic/3199-how-to-patch-lions-applertckext/

 

Have I committed not one, but two - Mortal Sins?

 

One - Edited a .plist file and hence a Kext - using 'nano', instead of using a formal Binary Editor…

Two - Recklessly overwritten an existing .plist file, directly within a Kext that resides right inside the outright primary /System/Library/Extensions location...

 

How much trouble am I in now? Mmmm, once either of you have picked yourselves up of off the floor - (from just losing it), please advise…

 

Fingers crossed - there is in fact, some way out of all of this.

(No real fears-for-tears, as my D630 still boots Lion sweet - and still plays AOK - but this WiFi issue has led me to this current potential issue with this Kext in question…)

 

Regards - and once again, thanks.

[Hervé]

Ok, a few comments:

• What you initially did was correct, but your subsequent assumptions were erroneous. Patching a copy of a vanilla kext, placing the patched kext in /E/E and running myFix (quick) was the right thing to do. However, this DOES NOT modify any vanilla kext in /S/L/E. That's the whole essence and philosophy of myHack: it leaves vanilla (=Apple's original) files untouched. See here for detailed explanations.
• Patching a kext does not in anyway guarantee that your hardware will be supported by the kext. Sometimes it works, sometimes it does not.
• 168c,1c or 168c,001c is just the same; it makes no difference at all.
• You also have to ensure that you've patched the right potential kext. I mentioned the AirportAtheros40 kext, but it may be a good idea to check on your old MacBook which actual kext is loaded for the card. Who knows, it may be a different kext...
• Do not confuse binary patching (aka a binmod) a binary/executable file and patching a kext's plist, which is indeed done via any text editor.
• The reporting of a DW1390 in System Profiler derives directly from the contents of the DSDT file (normally in /Extra). This is usually just a cosmetic matter (unless full wireless card description has been entered in the DSDT, but it should not be the case here). There's a detailed article on the Web site that explains how to modify this (a simple character string). It's in the Articles section of the web site (not the forum), look at the very top of your browser page.

 

Now, whilst your Atheros card has PCI ids 168c:1c, I see that your SysProfiler reports the DW1490 with ids 168c:4311 (which is incorrect) so the DSDT may require patching to adjust the data currently specified for the wireless card (under Device (ARPT) section). Zip your DSDT file, post it in a reply and I'll look into it.

 

Edit: AR5BX86 appears supported up to Lion but not after!