[Azurewave AW-CE123H] Usual Clover DSDT FixAirport_4000 and AddDTGP_0001 + WIFI FakeID doesn't work anymore on 10.12.1
Opened this issue · 67 comments
While it was perfectly working on 10.12, the usual Clover FakeID injection as described in "Airport Injection Methods/Enable WiFi" method 5. of https://github.com/toleda/wireless_half-mini/blob/master/README.md file, doesn't work anymore on 10.12.1 at least with Azurewave AW-CE123H (DeviceID: 43b1).
To fix that, I use Info.plist patch, but not by editing it directly, and use Clover Kext patch feature instead, that allows dynamic Info.plist patching (see pull request #9).
This offers multiple advantages compared to usual FakeID/Clover's DSDT Fixes:
- Avoid direct edition of Kext (so should be update proof)
- Avoid DSDT patching
- Use real DeviceID instead of inject a fake one
Please tell me, how to use this patch in Clover.
The same please, how install this patch ? Thanks for your work
config-bcm94352-120.plist/10.12-BCM94352-5GHz-US-FCC-dv works in 10.12 and 10.12.1, nothing changed. See README/Problem Reporting.
Other patches are not supported with this thread.
@toleda
Yes the existing patch work with 10.12.1 (it applies correctly and is still required), I never said the contrary. But on 10.12.1, 10.12-BCM94352-5GHz-US-FCC-dv is not enough to have the WiFi card detected by the OS and working and you need to add 3 additional patches (included in the config-bcm94352-121.plist I put in the pull rrequest).
If you just use the config-bcm94352-120.plist as is on 10.12.1, than WiFi doesn't work. Period.
I tried adding all of the config patches and I still can't get this to work. I have an Azurewave BCM94352HMB. Had it working on 10.12. I have my config.plist file attached if anyone can help me out. Thanks in advance.
config.plist.zip
@Duffman1914
There is a typo in your config.plist, you typed "AirPortCrcm4360" for the Name value of "10.12.1-BCM94352 Patch #2", while it's normally AirPortBrcm4360. Because of that the patch is not applied.
Fix the typo, and it should work (I've the same exact card as you, and it works for me).
but it's necessary kext or only 3 patches?
@bpresles: If you just use the config-bcm94352-120.plist as is on 10.12.1, than WiFi doesn't work. Period.
To be clear, 10.12 patch works in 10.12.1 with 4352. Without Problem Reporting files, impossible to determine what is not correct on your system.
i used in 10.12 rehabman's kext, but in 10.12.1 with 3 patches not works for me, Do i have to use toleda's kext?
@johnnynuca14
On 10.12.1 you need 4 patches (maybe not all the 4 but I didn't investigate fully on that part yet to see if all the patches are useful), the 10.2 patch (which was already in config-bcm94352-120.plist) and the additional 3 other patches included in the config-bcm94352-121.plist file attached, in the config.plist file of your Clover bootloader.
The rehabman kext is for Bluetooth firmware (if you are talking about BrcmPatchRAM), not for WiFi. And can be used additionally.
@toleda
As you can see this issue affect multiple users, so I don't think there is anything wrong with my system, just that the updated AirportBrcm4360 requires additional patches for the Azurewave BCM94352HMB WiFi card to be correctly and fully detected on 10.12.1.
Maybe it's only Azurewave BCM94352HMB owners, I don't know, but the fact is that for us if you only apply the 10.12 patch included in config-bcm94352-120.plist alone (without the 3 other patch I provided on my config-bcm94352-121.plist file), it doesn't work in 10.12.1 (but work perfectly in 10.12) and the OS display a message "No hardware present" when you click the Airport menu bar icon.
So at least for Azurewave BCM94352HMB owners, the 10.12-BCM94352-5GHz-US-FCC-dv is not enough to make the card detected by the OS.
If I apply the 3 additional patches here, then it's working perfectly again, with correct and full detection. Which demonstrate that at least one of these patches are required (maybe even all 3 of them) in addition to the existing "10.12-BCM94352-5GHz-US-FCC-dv".
I'll provide you more data (i'm not sure I'll be able to give you all what you listed on the "Problem report" section of your README, I'll try) later as soon as I can.
I'll also investigate more the issue to see if a or a set of patch(es) in particular is/are fixing the issue among the 3 I added (taken from a hackintosh forum).
I have GA-H97N-WIFI, when i updated to 10.12 i removed all patches and used this
http://www.insanelymac.com/forum/topic/312759-fix-macos-sierra-dp1-bcm94532z-wifi/
everything is working fine and after the update to 10.12, if it helps..
@bpresles, I have 2 Azurewave BCM94352HMB, both working after 10.12.1; no edits required. The patch is only to enable 5 GHz and is not the problem. Likely, did not properly install a README/Airport Injection Methods/Enable WiFi method (device_id injection).
@toleda
I double checked the device_id injection, trying Clover's method i, method ii separately and together. And without additional patch still "no hardware present".
The Device ID used is: 0x43a014e4
Find attach the complete config.plist file I used (in the file attached method ii is used (FakeID)) alongside other files listed in your "Problem report" section.
Procedure/method used: Clover config.plist
WiFi Card: AzureWave AW-CE123H
Clover Config: config.plist.zip
Motherboard: Gigabyte GA-Z87N-WIFI, BIOS Version: F6 (latest)
System Information report: SysInfo.spx.zip
IOReg: IOReg.ioreg.zip
DPCIManager Status: DCPIManagerStatus.png.zip
DPCIManager BootLog: DCPIManager_BootLog.txt.zip
MaciASL: MaciASL.acpi.zip
IOReg shows Clover method "i" is not working. Try a different device-id injection method.
@toleda
After further investigation, the problem I have has nothing to do with device-id injection issue, because even if I add the real device id (14e4,43b1) by adding "pci14e4,43b1" in the "IONameMatch" section of the Info.plist file in /System/Library/Extensions/IO80211Family.kext/Contents/PlugIns/AirPortBrcm4360.kext/Contents, and regenerate the kext cache using "sudo touch /System/Library/Extensions && sudo kextcache -u /" and reboot, the card is still not detected.
And once I put back the 3 additional patches (originally coming from this source), it works at the very next reboot (even without patching kext Info.plist):
http://www.insanelymac.com/forum/topic/316060-pre-release-macos-sierra-10121/page-1#entry2281834
So clearly these patches are useful on 10.12.1, at least with (some?) Azurewave AW-CE123H card. According to the forum entry above, they fixes PCI error(s) that is/are occurring with 10.12.1's AirportBrcm4360.kext (probably only with some cards or even some cards/motherboards combinations).
You said your have 2 Azurewave BCM94352HMB, is one of them (or both) a Azurewave AW-CE123H? Apparently the issue here occurs with Azurewave AW-CE123H (maybe only with certain cards? Or with certain card/motherboard combinations?).
When I don't put these 3 patches I can see in system.log the following line repeating continuously:
com.apple.xpc.launchd1: Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
For your own interest, find below the system information extract, DPCIManager Boot Log, IOReg extract and config.plist when the card is correctly working under 10.12.1 (so with the 3 additional patches):
DCPIManager_BootLog_working.txt.zip
P.S: I updated config.plist, IOReg and DCPIManager Boot Log in original comment with 100% sure working injection but without the 3 patches (so not working) (in a nutshell it's just working config.plist with the 3 patches removed)
After correcting the typo in AirPortBrcm4360 I still wasn't able to connect my card. I did copy and paste the kext patches from config_working.plist.zip file in the previous post into my config.plist and it is working now. I am not able to connect to my 5.0GHz network, but I do see other ones listed. I am not sure why that would be different, but I am happy that my laptop is once again useful.
@Duffman1914
Did you also include the toleda 5GHz patch? Because the 3 patch I added are only to fix the PCI error, and don't enable the 5GHz support, for this you need to add also the 10.12-BCM94352-5GHz-US-FCC-dv patch.
for me works now with 4 patches!
@bpresles: the problem I have has nothing to do with device-id injection issue
Wrong.
IOReg/Search: ARPT
Cancel Search
No AirPort_Bcrm4360 kext loaded > no hardware detected - 4352 works/2.4 GHz only.
Cause: dsdt/ARPT edits are not correct, remove patched/dsdt.aml
Restart, reply with new IOReg.
@toleda
"Cancel Search
No AirPort_Bcrm4360 kext loaded > no hardware detected - 4352 works/2.4 GHz only.
Cause: dsdt/ARPT edits are not correct, remove patched/dsdt.aml
Restart, reply with new IOReg."
The latest IOReg provided above are already on a running system without any patched dsdt or ssdt. Only with Clover DSDT Airport4000 and AddDTGP_0001 and FakeID 0x43a014e4.
It works perfectly on 10.12.0, and was also working perfectly in 10.10.x and 10.11.x.
Also the 3 additional patches by Neo.aka.Darkman are not at all related to injection, which is still required to make the card detected (if I don't inject device-id or patch the Kext directly, the card is not detected), it only fixes a PCI error on some hardware combination (Azurewave AW-CE123H (and probably also depending on motherboards)).
There is at least 2 reasons a card can be undetected, either the device is not recognized (wrong device-id) or the driver just fails to load. In our cases (mine and the others above having commented),
IOReg_working.ioreg (above) shows no WiFi. There is no evidence to support any of your claims.
@toleda
If you look at the System Information extract you can see that the WiFi card is detected and perfectly working. So apparently IOReg here doesn't show WiFi while it's in reality present and working.
I don't know how IOReg work and if it's fiable when device-id injection is done through Clover. The fact is all the _working files are from a running system with full WiFi working (using the 3 additional patch from Neo.aka.Darkman)
What I know for sure is:
- If I don't add Airport4000 and AddDTGP_0001 DSDT fixes and FakeID 0x43a014e4 on Clover (except if I patch the kext Info.plist to include the real device-id):
=> The card is not detected in all case (with or without Neo.aka.Darkman patches)
- If I add Airport4000 and AddDTGP_0001 DSDT fixes and FakeID 0x43a014e4 on Clover but I DON'T put the Neo.aka.Darkman patches
=> The card is not detected.
- If I add Airport4000 and AddDTGP_0001 DSDT fixes and FakeID 0x43a014e4 on Clover but I DO put the Neo.aka.Darkman patches
=> The WiFi is fully working
- On 10.2.0 WiFi was working with only Airport4000 and AddDTGP_0001 DSDT fixes and FakeID 0x43a014e4 on Clover (no need for additional patches)
I think that would be useful if others affected persons (@Duffman1914, @johnnynuca14 , @lesvink, @codEmotion) provide also data from their system (IOReg, DPCIManager boot log and status, Sys info extract...etc).
@toleda
How do you explain that I've full WiFi working and it doesn't seem to be visible on the IOReg extract?
I'm trying to be as useful as I can providing all the information I've. But I can't invent information that I don't have.
If IOReg isn't able to get WiFi related information even though it's fully detected and working by macOS (when using Airport4000 + AddDTGP_0001 DSDT fixes, FakeID 0x43a014e4 on Clover and Neo.aka.Darkman's patches), I don't see what can I do...
I've done all what you asked me to do, but it seems that you can't find any clue to help you to find why it's not working on our systems without Neo.aka.Darkman's patches.
If you can think of anything that can cause IOReg not to report data on WiFi and of anyhting that could fix it to report them, then don't hesitate to ask me.
I did remove all patched dsdt.aml (and ssdt.aml) files from Clover (and in fact I never had a patched dsdt.aml, only ssdt.aml) and it doesn't seem to help. So if you have any other suggestion, feel free to ask me.
Asked and answered, nothing to explain.
@toleda
"Asked and answered, nothing to explain."
I finally had access to a macOS computer so I could look at the IOReg_working.ioreg file to see check that if there is WiFi information or not.
I found the following information in IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP05@1C,4/IOPP/ARPT@0 with device-id value of 43a0 (which is what I but in Clover FakeID parameter. The exact value of device-id entry: a0 43 00 00).
It's the same exact data on IOReg.ioreg file when booting without Neo.aka.Darkman patches.
So the device-id seems OK.
I noticed that some kexts patched through Clover seem to not be listed afterward in IORegistryExplorer.
But while there is not trace of AirPortBrcm4360 in IORegistryExplorer, you can see on the System Informations files (both working (SysInfo_working.spx and not working (SysInfo.spx)) that the AirPortBrcm4360.kext extension is loaded:
IORegistryExplorer screenshots:
With Neo.aka.Darkman patches (and so WiFi fully detected and working):
Without Neo.aka.Darkman patches (so with "hardware not present" message):
Missed this:
Neo.aka.Darkman/Post #20: http://www.insanelymac.com/forum/topic/316060-pre-release-macos-sierra-10121/?p=2281980
Not AW-CE123H/43a0
@toleda
For information, my exact WiFi card is this one (link took straight from my original command back in November 2014): https://www.amazon.fr/gp/product/B00NTTZ81A/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
So an AW-CE123H
The original device id (as shown in DPCIManager PCIList tab, and in "IOName" key value of ARPT@0 entry in IOREgistryExplorer): 43b1 (14e4,43b1)
Fake id used in Clover: 43a0 (14e4,43a0)
So the same exact card as Neo.aka.Darkman (see post #22 where he confirms to have original device-id of 43b1).
device ids:
4352: 43b1 (see README/BCM94352)
4360: 43a0 (native)
Neo.aka.Darkman: 2154 (not a valid Broadcom Wifi device id, not applicable)
Complete waste of time and effort, does not apply to genuine AW-CE123H
No support for Neo.aka.Darkman method in this repo
@toleda
Indeed. But the patches doesn't seem to refer to this device id (I don't see any trace of it on them and if it were the case his patches wouldn't have worked in my case as I'm using 14e4, 43a0 as fake id, not 2154)
@toleda
Also I noticed that while there is no "Airport_Brcm4360" in the IOReg_working file, there is in the SysInfo_working (from Apple's System Information app) on Logs -> IORegistry contents, which is also a representation of the IORegistry (I'm trying to think I posted the wrong IOReg file for the IOReg_working one. I'll give you a new one when I have access to my Hackintosh).
Maybe that can help you tracking the issue?
Problem: AW-CE123H (43b1) only works when using Neo.aka.Darkman method
OS X Version: 10.12.1
Motherboard: Gigabyte GA-H77N-WIFI
BIOS Version: F2
Processor: Intel i3-3225
Graphics: NVidia GTX 750 Ti
Procedure used: AirPort Injection Methods/Enable WiFi/5. Clover/config.plist
Clover kext patches for 5GHz, Handoff, AirPort Extreme, and Neo.aka.Darkman patches.
Attached: Problem reporting files with and without Neo.aka.Darkman patches.
@toleda
After further investigation, it seems that the Clover DSDT FixAirport_4000 and AddDTGP_0001 + WIFI FakeID doesn't work correctly anymore on 10.12.1, at least for AzureWave AW-CE123H (43b1).
Indeed, I Achieved to make the AW-CE123H (43b1) working without Neo.aka.Darkman patches (and without any FakeID or DSDT Clover Airport / DTGP Fixes) by following this procedure:
First backup your config.plist. Then open the config.plist in a standard text editor and:
- Remove FixAirport_4000 and AddDTGP_0001 fixes from ACPI -> DSDT -> Fixes
- Remove Devices -> FakeID -> WIFI
- Add the following patch to the KernelAndKextPatches -> KextsToPatch section, changing the replace value with your real device-id (use DPCIManager, PCI List tab to get the device ID of your device)
<dict>
<key>Comment</key>
<string>BCM94352HMB add 0x43b114e4</string>
<key>Find</key>
<data>PHN0cmluZz5wY2kxNGU0LDQzYmE8L3N0cmluZz4=</data>
<key>InfoPlistPatch</key>
<true/>
<key>Name</key>
<string>AirPortBrcm4360</string>
<key>Replace</key>
<data>PHN0cmluZz5wY2kxNGU0LDQzYjE8L3N0cmluZz4=</data>
</dict>
Use a Base64 decoder/encoder (e.g: http://www.asciitohex.com) to change the Replace value with your device-id (on the above example the value match the 14e4,43b1 device-id.
The patch on 3) is just injecting the real card device id to the IONameMatch array of the AirPortBrcm4360.kext driver dynamically (without altering it on the filesystem).
If you do so, you don't need to use Neo.aka.Darkman patches, just the ones from https://github.com/toleda/wireless_half-mini/blob/master/config-bcm94352-120.plist.zip (additionally to the above one).
Advantages of this method:
- No alteration of original AirPortBrcm4630.plist (so it's resistant to macOS updates)
- No DSDT patching required
- No FakeID injection required
Find attached an example of working config.plist
config.plist.zip
Also for @toleda curiosity, find below the IORegistryExplorer export with this configuration:
@gurase (apologies for the auto format nonsense)
- clover boot log:
8:428 0:000 Start Airport Fix
8:428 0:000 found Airport device [001C0006:0] at 3A10 And Name is PXSX
8:428 0:000 Name PXSX present at 0xA2, renaming to ARPT
8:428 0:000 Name PXSX present at 0xE0, renaming to ARPT
8:428 0:000 AirportADR=3A10 add patch size=F4
-
clover dsdt patch:
Device (ARPT) { Name (_ADR, Zero) // _ADR: Address Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake { 0x09, 0x04 }) Name (_SUN, 0x00000000) // _SUN: Slot User Number Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x12) { "built-in", Buffer (0x01) { 0x00 }, "model", Buffer (0x10) { "Apple WiFi card" }, "subsystem-id", Buffer (0x04) { 0x8F, 0x00, 0x00, 0x00 }, "subsystem-vendor-id", Buffer (0x04) { 0x6B, 0x10, 0x00, 0x00 }, "device_type", Buffer (0x08) { "Airport" }, "device-id", Buffer (0x04) { 0xA0, 0x43, 0x00, 0x00 }, "vendor-id", Buffer (0x04) { 0xE4, 0x14, 0x00, 0x00 }, "name", Buffer (0x0D) { "pci14e4,43a0" }, "compatible", Buffer (0x0D) { "pci14e4,43a0" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } -
only required patch is:
"compatible", Buffer (0x0D) { "pci14e4,43a0" } -
clover fix: remove all clover airport patches
-
download (select View Raw): https://github.com/toleda/wireless_half-mini/blob/master/ssdt_arpt/ssdt_arpt-bcm4352.zip
-
edit MaciASL/SSDT-ARPT-BCM4352
Find: RP04
Replace All: RP07
Save/Install/Restart
- Reply with edited ssdt, IOReg and config.plist
@bpresles:
Info.plist patches are not reliable, suggest ssdt injection.
- clover fix: remove Info.plist patch and whitelist patches
- download (select View Raw): https://github.com/toleda/wireless_half-mini/blob/master/ssdt_arpt/ssdt_arpt-rp05-bcm4352.zip
- Install/restart
- Reply with clover boot log, IOReg and config.plist
@toleda
Added back config-bcm94352-120.plist/10.12-BCM94352-5GHz-US-FCC-dv and 10.11-BCM94352-Airport-Extreme patches; Wifi hardware is detected and working now. Thanks for your help with the SSDT.
@toleda
You patch works, thank you. Find attached the clove config.plist, boot log and IOReg.
But I'll revert to the Info.plist patch, because I personally find this method cleaner and I fail to see why it wouldn't be reliable.
The fix works to enable the device, I have both BT + Wifi working, but has anyone gotten Handoff/Continuity Working?
See README/BCM94352 5 GHz/Handoff Patch (10.12+)
Using the fixes you've suggested including config.plist edits and SSDT-4.aml I still cannot get wireless to work, went backwards from earlier when trying to fix handoff, but hoping to get a more correct solution. Thanks for helping.
Wrong arpt ssdt, remove
Install https://github.com/toleda/wireless_half-mini/blob/master/ssdt_arpt/ssdt_arpt-rp04-bcm4352.zip
Restart/reply with new files
Are kexts native?
Remove config.plist whitelist patches (2x)
dsdt does no allow RP04 ssdt injection, remove ssdt
See README/Airport/WiFi Injection Methods/1. kext enabler/FakePCIID for BCM94352
Install 2 kexts
Restart/reply with new files
Made sure kexts are native, applied suggestions.
Azurewave.zip
FakePCIID made the match, however, the kext did not load.
Edited the dsdt to force the match.
Suggestion, put the dsdt on an installer USB and boot your 10.12 partition. If the dsdt works the wifi card will load, no patches required. Key is do the experiment in a way your system is not compromised.
If it boots, reply with IOReg and boot log
Boots, but still without wifi.
Did the 4352 ever work. If yes, with what injection, what OS version, etc?
dsdt edit worked, kext problem
Install native IO80211Family.kext, Pacifist or Sierra installer.
Reply with new files
It works in the Sierra installer.
Reinstalled fresh Sierra using install usb with DSDT. Updated Clover with DSDT. Installed FakePCIID, FakePCIID_Broadcom.. + BrcmNonPatchRam2 + BrcmFirmwareRepo. Now I have no wifi or bluetooth, had bluetooth before.
Boot with installer; attach config.plist, boot log and ioreg
How do I generate the ioreg and boot log in the installer? If you mean the installer's clover it's the same as the installed version.
You said: It works in the Sierra installer. ?????
Yes, when I boot into the Sierra installer USB to install from scratch in the top right corner is the wifi icon and it connects fine to the network but I do not understand how I could generate the files from the applications while in the installer which is essentially recovery "os". I really appreciate the help so far, thanks. My sierra installation and sierra usb installer both use the same copies of clover, config.plist, etc. from the files above
Fresh install using Sierra installer that showed wifi working during the install, as in when booted from the usb.
Archive.zip
Boot the Sierra partition with the usb installer. Reply with files.
Latest: Wifi working, posting files.
I removed the DSDT and added 5GHz patch + toledaARPT, even though it's deprecated, it enables wifi so we can work from here.
Kext patch enables 5 GHz, not WiFi.
Is the 4352 working with normal boot of Sierra install?
Device doesn't work if I remove kext patch or toledaARPT, they both need to be there for the 4352 to work. I've tried both individually and I got the wifi icon but would show no device. I have wifi now but it shows as Third Party instead of Broadcom/AirPort Extreme
toledoARPT injects 4352 device_id into Info.plist, deprecated a year ago.
bpresles wrote a Clover patch (above) to do the same thing.
Extreme, add patch: 10.11-BCM94352-Airport-Extreme-skvo
Handoff, add patch: 10.11-BT4LE-Handoff-Hotspot-lisai9093
@toleda I also have the same issue, only way I got it working was using ToledaARPT and the 5GHz patches
ToledaARPT is deprecated. Injection failure, see README/Problem Reporting; attach requested files.
@toleda I have removed toledaARPT and it still seems to be working, but unsure what will happen when an update comes around. Here are the files you have requested.
archive.zip
BCM94352HMB add 0x43b114e4 does the same as toledaARPT. I prefer the ssdt.
Whitelist patches do not apply to your system, remove.
@toleda Ok the whitelist patches are now removed. I got no Wifi Hardware Detected without the info.plist patch. I named the SSDT as SSDT-4.aml. Not sure if I should just stick with the info.plist patch or figure out why SSDT didn't work.
High everybody!
I’ve recently replaced the genuine wifi card Atheros Ar5bmd222 from my Acer Aspire 3S-371, with a new one Atheros ARBHB92H. I have 3 OS installed on this machine: Ubuntu 17.04, Mac OS Sierra, and Windows 10. The new wifi card is acting very strange even it was expected to act as a native card. It’s been activated on booting from Ubuntu USB installer (try Ubuntu without installation - option), and works great on all 3 OS, but after booting in Sierra, if trying to reboot in Sierra again or in other OS the card is loosing it’s properties and become unactivated. It is recognized in all 3 OS but the networks are not listed and is impossible to connect or activate manual. The single solution is to boot again from Ubuntu USB installer, which has this capability to activate the wifi card. After that I can boot ubuntu17.04 and windows 10 , no mather how many times, the card remain active and works properly. But if I boot Sierra the card will work great but I'll become a prisoner because once I quite Sierra, the card become insane again. Is there anybody able to give me a hand to solve this issue?
thanks!
Do not double post. Broadcom topic; Atheros off topic.