Jump to content

macOS Sonoma Wireless Issues Discussion.


SavageAUS
791 posts in this topic

Recommended Posts

3 hours ago, AppleBreak said:

Please try AMFIPass.kext with -amfipassbeta boot flag and remove amfi=0x80

so i can disable amfi by using AMFIPass.kext + -amfipassbeta boot flag ( then i can remove amfi=0x80 right? )Is it the same function, just disable amfi, right? just a stupid question, thanks a lot

  • Like 1
Link to comment
Share on other sites

4 hours ago, mnfesq said:

 

I disabled AMFI and Firefox and WhatsApp for Mac both stopped working.  Anyone have a possible solution or workaround?

 

Same to me. I will try this kext. 

3 hours ago, AppleBreak said:

Please try AMFIPass.kext with -amfipassbeta boot flag and remove amfi=0x80

 

 

Link to comment
Share on other sites

Very nice this AMFIPass.kext 

 

Im run executable Patcher program from  @chris1111  page. 

 

https://gist.github.com/chris1111/781e9324bcd9657af294462c0b3f6582 

 

After that drag and drop OpenCore-Patcher on Terminal to finish and get AMFIPass-v1.3.1-RELEASE.zip on Desktop. 

 

Works Airdrop, Wireless, WhatsApp Desktop and Firefox again!!

 

Thanks a LOT to everybody

 

:superman:

 

 

2121057112_CapturadeTela2023-07-30as05_22_54.png

  • Like 2
Link to comment
Share on other sites

20 hours ago, deeveedee said:

It does appear that the key to working Sonoma Wi-Fi with the BCM 94352HMB was replacement of the Acidanthera AirportBrcmFixup.kext 2.1.7 with AirportBrcmFixup.kext 2.1.7 included with OCLP 0.6.9 (different kexts, same version).  See here.  I don't see any commits in the Acidanthera repo (yet).  I'd be curious to know the change if anyone knows.

 

EDIT: Maybe in the Dortania nightly builds?  I haven't checked yet. *** Nope - not yet.

The difference that I see between the 2 versions of AirportBrcMfixup.kext is the absence of the plugin: AirportbrcM4360_injector.kext

  • Like 2
Link to comment
Share on other sites

17 hours ago, emax31 said:

The difference that I see between the 2 versions of AirportBrcMfixup.kext is the absence of the plugin: AirportbrcM4360_injector.kext

Yes - that is what @ThriftLover determined, too.  See my EDIT3 here for a theory.

===========================================

 

@emax31 - you were right  - that is the only difference in the kexts.  I was experimenting with device spoofing and different versions of AirportBrcmFixup.kext as I explain here and misinterpreted my test results.  It was the spoofing and NOT the AirportBrcmFixup.kext version that resulted in successful Wi-Fi patching in Sonoma.  See my mea culpa here.

 

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

@deeveedee sorry for bothering, can you help me a bit. i tried doing the same as you did, however i can't activate the root patch because it's greyed out ( cant press root patch - OCLP 0.6.9 nightly build ). without OCLP wifi can turn on but not find any wifi signal. (i have mapped the usb correctly, did your way in the most accurate way) am i doing something wrong, please help me. below is my EFI, thank you very much! ( my wifi is BCM943602CDP )


image.thumb.png.7325dbdf169ce5b9fa8ae21179f1ff7c.png

image.png.9ab0f57d59a3ffd3ffbec9f2bf8e8616.png

image.png.b8665d240ea31c38bff16796b963a2eb.png

image.png.255d172f2d50fd5f4df0ad718e832460.png 

EFI.zip

Edited by kinhhoang161
Link to comment
Share on other sites

23 hours ago, AppleBreak said:

Please try AMFIPass.kext with -amfipassbeta boot flag and remove amfi=0x80

Thank you!  This works!  

 

Since I am multi-booting Big Sur, Monterey, Ventura and Sonoma on my HackBookPro6,2, I have modified my EFI as follows:

  • Remove AMFI and LV kernel patches from OC/config.plist
  • Renamed new OCLP AirportBrcmFixup.kext 2.1.7 to AirportBrcmFixup-Sonoma.kext (in OC/Kexts)
  • Re-added Acidanthera AirportBrcmFixup.kext 2.1.7 to OC/Kexts
  • Added boot-arg -amfipassbeta and removed amfi=0x80 (config.plist)
  • In OC/config.plist, added Kernel > Add > AirportBrcmFixup-Sonoma.kext with MinKernel 23.0.0 and Set MaxKernel = 22.99.99 for AirportBrcmFixup.kext

With these changes, I can boot Big Sur, Monterey, Ventura and Sonoma with a single EFI.  A new sample config.plist is attached.

 

@AppleBreak Where did you learn about boot-arg -amfipassbeta?  Lucky guess?

 

 

Edited by deeveedee
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

@kinhhoang161 I took a quick look at your EFI and noticed the following:

  • You use revpatch=sbvmm  where I add revpatch to NVRAM > Add > 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102. I've never used the boot-arg format of this and I doubt this is the problem, but it is a difference
  • You don't have the LV and AMFI kernel patches (Kernel > Patch) (see my sample config.plist attached here)

 

If those suggestions don't work, then you will need to step through my thought process starting here to see what I missed in my final summary.  Unfortunately, you'll need to be patient with reading my guesses that didn't work.

Edited by deeveedee
Link to comment
Share on other sites

1 hour ago, deeveedee said:

@kinhhoang161 I took a quick look at your EFI and noticed the following:

  • You use revpatch=sbvmm  where I add revpatch to NVRAM > Add > 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102. I've never used the boot-arg format of this and I doubt this is the problem, but it is a difference
  • You don't have the LV and AMFI kernel patches (Kernel > Patch) (see my sample config.plist attached here)

 

If those suggestions don't work, they you will need to step through my thought process starting here to see what I missed in my final summary.  Unfortunately, you'll need to be patient with reading my guesses that didn't work.

Thank you for your help. i did it again like what you did, add 2 kernel patch for LV and amfi but same result. I don't understand why anymore. I will check it again.
- I realize I don't need SSDT-ARPT to spoof device id because my card already have a support id. try all but i cant start root patching...
image.thumb.png.e469f4c242afa55a30717c026789af91.png

here is my config.plist 

config.plist

Edited by kinhhoang161
Link to comment
Share on other sites

@kinhhoang161 I admire your persistence! That is what it will take to solve. When I have time, I will re-install Sonoma from scratch and confirm all my steps. Hopefully you figure it out before waiting for me.

Link to comment
Share on other sites

13 hours ago, kinhhoang161 said:

so i can disable amfi by using AMFIPass.kext + -amfipassbeta boot flag ( then i can remove amfi=0x80 right? )Is it the same function, just disable amfi, right? just a stupid question, thanks a lot

https://github.com/dortania/OpenCore-Legacy-Patcher/releases/tag/0.6.8

 

 

 

@Max.1974Merely passing the information.

 

5 hours ago, Max.1974 said:

Thanks my friend

 Directed to OCLP developers for their tremendous work.

Edited by AppleBreak
  • Like 2
  • Thanks 2
Link to comment
Share on other sites

5 hours ago, kinhhoang161 said:

EDIT: 1

i try edit sys_patch_detect.py > self.legacy_wifi = True and rebuild OCLP again and althought it show available patches for your system but i still cant start root patching because unsupported host OS 


image.png.733d7a8643665dddd4ad5b6c998ec175.png

I went through that same issues but did a new Sonoma install booting with my regular EFI that is use for Ventura, then followed @deeveedeerecommendations and built a EFI using OCLP in Sonoma, copied my regular EFI to USB and configure it in USB and tried it to boot Ventura, once I got that working properly, I booted with edited EFI into Sonoma and did the patch, reboot and its working. I used the EFI generated by OCLP only as a reference for kext order etc. 

Edited by surenmunoo
  • Like 1
Link to comment
Share on other sites

So, on my T490 Laptop I had Ventura and Sonoma on 2 different volumes booting from the same EFI. Everything was working great. So I decided to Upgrade Venture to the public beta of Sonoma and kill the Volume with the Sonoma Dev build. And after that Intel Wifi stops working after about half a minute or so. So I updated AirpritItlwm from  https://github.com/OpenIntelWireless/itlwm/issues/883  but the issue remains- I will never do incremental upgrades again. Goddamn Sonoma BS.

 

EDIT: I forgot to update Little Snitch to the preview version of Sonoma after the upgrade so it just blocked all the traffic. Now everything's back to normal again

Edited by cankiulascmnfye
  • Like 4
Link to comment
Share on other sites

21 hours ago, kinhhoang161 said:

@deeveedee thank you, I'm still redoing the steps you did earlier. I look forward to your confirmation of the steps..

 

I am glad that you asked me to confirm my installation steps.  It turns out the the steps that I thought were unnecessary for my hack (the steps with a strike-through here)  are actually necessary for post-install patching but are not necessary for normal Wi-Fi operation (after patching).  If my config.plist does not include a binary rename of PXSX -> ARPT or it does not include spoofing the Wi-Fi device that is in a real MBP6,2 ("pci14e4,4353"), the OCLP 0.6.9 post-install patcher does not recognize my Legacy Wi-Fi to be patched.  The reason that I thought this was unnecessary is that after the Wi-Fi patches are applied, the binary rename and device spoofing are NOT required for normal Wi-Fi operation.  The spoofing is only required for patching.  Sorry I'm repeating myself, but this "before and after patching" behavior is important.

 

After performing a clean installation of Sonoma 14.0 Beta 4, I attempted to apply post-install patches with OCLP 0.6.9 (nightly build downloaded on 07/30/2023).  If my config.plist did not include a binary rename of PXSX -> ARPT or spoofing "pci14e4,4353" (the Wi-Fi device in a real MBP6,2), post-install patching did not recognize my Wi-Fi as needing to be patched:

Spoiler

49004339_Screenshot2023-07-30at8_24_10PM.png.889f6a3e729ea567eb3d6e2f8170eb8e.png

 

If I modified my config.plist to include the PXSX -> ARPT binary rename and spoofing "pci14e4,4353", the post-install patcher recognized my Wi-Fi as needing to be patched:

Spoiler

1635874049_Screenshot2023-07-30at8_33_46PM.png.514545302b848d0991a5b7b14b12a22f.png

 

If my config.plist included only the binary rename PXSX -> ARPT or only the device spoofing to "pci14e4,4353", the post-install patcher did not recognize my Wi-Fi as needing to be patched.  BOTH ACPI patches were required for me.

 

Attached are my SSDT-ARPT (to spoof the MBP6,2 Wi-Fi device) and a sample config.plist that includes the elements that I required in my config.plist to apply legacy Wi-Fi post-install patches.

 

IMPORTANT: I cannot post a "universal" SSDT-ARPT and a binary rename (PXSX -> ARPT) that works on all PCs, because different PCs have different ACPI device paths and device names.  You will need to customize my ACPI patches to spoof the BCM 94352HMB Wi-Fi on your PC.

 

NOTE: I performed my clean Sonoma installation and post-install patching with AMFI and Library Validation fully enabled (no amfi=0x80 boot-arg, no AMFI or LV kernel patches).  AMFIPass.kext 1.3.1 with boot-arg -amfipassbeta was all I needed.

 

NOTE: After post-install Wi-Fi patches are applied, device spoofing is no longer necessary and can be disabled/removed in config.plist.  My BCM 94352HMB Wi-Fi works fine in Sonoma without the device spoofing after the patches are applied.

 

SSDT-ARPT.aml.zip config-sonoma-patch-sample.plist.zip

Edited by deeveedee
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Well, I need to admit to one of my more public F'ups.   It appears that the "new" AirportBrcmFixup.kext included with OCLP 0.6.9 is not the reason that Wi-Fi works on my HackBookPro6,2 in macOS Sonoma.  @ThriftLover and @emax31 were on the right track by suggesting that the AirportBrcmFixup.kext change was only the removal of an unused plugin. The before patching and after patching behavior of my Wi-Fi (explained in my previous post) is the true reason that Wi-Fi now works for me in Sonoma with my BCM 94352HMB on my old Dell Latitude E6410 (SMBIOS MBP6,2).  I was experimenting with device spoofing (via ACPI patches) and different versions of AirportBrcmFixup.kext at the same time and did not recognize that it was the spoofing that resulted in a successful application of post-install legacy Wi-Fi patches, not the AirportBrcmFixup.kext version.

 

I apologize for my confusion and hope that my revelation helps others to get Wi-Fi working in Sonoma on their legacy hacks.  I have successfully been able to repeat a clean installation of Sonoma, post-install Wi-Fi patching with OCLP 0.6.9 and my Wi-Fi is working perfectly in Sonoma Beta 4.

 

Once OCLP 0.6.9 post-install patches are applied (which requires the Wi-Fi device spoofing on my old legacy hack with BCM 94352HMB), the Acidanthera version of AirportBrcmFixup.kext 2.1.7 works fine in Sonoma.

 

EDIT: Others may prefer to modify OCLP to apply post-install patches (instead of spoofing Wi-fi).  You'll see that I started to do this here.  I'm content with my Wi-Fi spoofing (ACPI patch) approach, but if you want to modify OCLP, hopefully my initial attempt here helps.

Edited by deeveedee
  • Like 1
  • Thanks 2
Link to comment
Share on other sites

@deeveedee Nice find. I will test this later since I have a BCM94352 as well.

 

Notes on your SSDT: it can be optimized, so you don't need any binary rename: change the form of the SSDT: If OSI = Darwin: disable PSXS, add ARPT. I think this is the cleanest implementation. Example: https://github.com/pupboss/Hackintosh/blob/master/CLOVER/ACPI/patched/SSDT-ARPT.dsl (needs If OSI Darwin still)

Alternatively: Use a binary rename to rename the device system wide and use device properties add the compatible device-id etc. Pros: relatively easy, changing the device-id property only affect macOS. Cons: ACPI Rename might affect WIFI in Windows.

 

But I am baffled to why the rename is required on Wintel systems. Here are my "specualtions".

 

If your run OCLP on a real Mac,  (I guess) the patcher does the following:

  1. Dectects the WiFI device (ARPT)
  2. Checks the deviceID of the wifi card to figure out the vendor and model
  3. Depending on the rules defined for the Mac Model (or the detected card, or both?), it adds the required kexts to re-enable Wifi to the EFI and config (a look into the source code might help to clarify)
  4. It then applies the root patches. Which ones? I don't know! Maybe the patch log will provide clues.
  5. Reboot Mac. Hooray, working Wifi

Now my speculations on what  happens in this case when running OCLP on Wintel systems instead:

  • It detects AirportBrcmPatchRAM (which handles the renaming to ARPT on Hack, btw) is already present
  • It then goes: "Hey, AirportBrcmPatchRAM is already present on this Mac – must be patched already, nothing to do here"

If you have a look at the complete config of OCLP (located at https://github.com/dortania/OpenCore-Legacy-Patcher/blob/main/payloads/Config/config.plist), you will notice that it can inject various kexts for Wifi devices (check the comments):

 

1478146827_Bildschirmfoto2023-07-31um04_31_13.thumb.png.155e386b62db7992b3663e02a13b6338.png

 

NOTE: The prefixes mentioning older versions of macOS indicate the origin of the kext (where they are from – not the OS they are for).
 

Possible approach/test for PC Users: treat her like  a real Mac – in other words:

  • Add a PSXS to ARP Rename
  • Disable all the Wifi kexts (these don't exist on real Macs either)
  • Run OCLP, see if it apply the patches
  • Add/enable the required kexts
  • Reboot

>> Iv'e tested this, it doesn't work for me.

 

Edited by cankiulascmnfye
  • Like 2
Link to comment
Share on other sites

@cankiulascmnfye I like it! My ACPI patch is only temporary (used only for post-install patches and not during normal ops) so I'm not too concerned about its optimization or conditional (Darwin) application, but I like your suggestion better than mine.

Edited by deeveedee
Link to comment
Share on other sites

For me this method doesn't work yet, because my DSDT does not contain an PSXS Device that I could rename. Adding the SSDT didn't have any effect either.

 

If it's only about the device-id (or device-id spootf), injecting the wifi card via device properties might be an option as well.

Edited by cankiulascmnfye
Link to comment
Share on other sites

Hi Guys, great effort here from you

 

Congrats 

 

If help someone my Broadcom Card from Lenovo is this, and work fine with OCLP 0.6.9 Rooting Patcher

 

 

image.png.decdf69d17e0ae4de2afaf522c66cd15.png

 

 

image.thumb.png.4c3e61708a7af9f564d3c869616afbcb.png

 

But on Hackintool shows up pci14e4,43a0, im think is because my DSDT was edited by @MaLd0n and works fine like always!! 

 

Im not use SSDT, just DSDT since 2018

 

 

 

 

 

 

 

  • Like 3
Link to comment
Share on other sites

This may be off topic not sure.
I’m using the OCLP patcher posted in the dummies guide thread and it is offering me to update OCLP. Should I do it? Are the modern wireless patches mainline?


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

×
×
  • Create New...