macOS Sonoma Wireless Issues Discussion.

[SavageAUS]

20 minutes ago, deeveedee said:

 

... and I wish I had a BCM 94360 to help figure out why some are unable to get Wi-Fi working in Sonoma.

Ok install went flawless except I couldn't Sign in with Apple ID, I suspect due to not having WiFi yet.

 

So I am in a virgin environment with all the necessary OCLP mods done (kexts, amfi, secure boot etc.

This is the ioreg path of my BCM4352

IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP14@1D,5/IOPP/PXSX@0

Here is path

PciRoot(0x0)/Pci(0x1D,0x5)/Pci(0x0,0x0)

Here is name and rest of info

 

If I am correct I need to add PciRoot(0x0)/Pci(0x1D,0x5)/Pci(0x0,0x0)in device properties with the properties closest to my chip like so.

 

Reboot and apply OC 0.6.9 patches?

[deeveedee]

@SavageAUS Yup.  Looks good.  Give it a try with that config.

Note that my statement "closest to ..." is very ambiguous.  In the Table of OCLP officially supported Wi-Fi devices attached here, your BCM4352 is actually "closest" to BCM4350 (with device id 0x43a3), so according to my instructions, your IOName would be "pci14e4,43a3" ...

 

But I don't think it matters.  I am beginning to suspect that you can choose any OCLP supported Wi-Fi and spoof that IOName to trick OCLP into patching your Wi-Fi.  OCLP patches my BCM 94352HMB Wi-Fi when I spoof IOName "pci14e4,43a3" and "pci14e4,4353" - it doesn't seem to matter.

 

 

Edited August 6, 2023 by deeveedee

[SavageAUS]

I’ll try what I have it set too first then yours if any issues.
I’ll update this post with results.

 

EDIT:

Test with my IOName did not go so well, WiFi couldn't turn on from settings.

So I changed to pci14e4,43a3 as you suggested with the same results.

I then remembered I was using AirportBrcmFixup.kext on this machine so I added -brcmfxbeta to my boot args and rebooted and here I am in Sonoma with working WiFi.

So I suspect WiFi would have worked with the initial IOName spoof if I had the boot arg set from the get go.

 

Well done on all your research for this to work for most people.

Sent from my iPhone using Tapatalk

Edited August 6, 2023 by SavageAUS

[deeveedee]

@SavageAUS Congratulation!  Good detective work on the boot-arg and a good lesson for everyone.  If you're not using boot-arg -lilubetaall, then you must use -brcmfxbeta until Acidanthera updates AirportBrcmFixup.kext for Sonoma.

 

Well done!

 

EDIT: Note that I prefer to use boot-arg -brcmfxbeta which applies only to AirportBrcmFixup.kext.  The boot-arg -lilubetaall applies to all Acidanthera Lilu-based kexts.  According to Acidanthera, the -lilubetaall boot-arg should be used with caution and since the other Acidanthera kexts I'm using have all been updated for Sonoma, I don't want to use -lilubetaall.

 

Acidanthera warning about -lilubetaall boot-arg

Spoiler

 

 

Edited August 6, 2023 by deeveedee

[ANTIKO]

15 hours ago, deeveedee said:

Also, whenever macOS gets stuck in "the middle of the progress bar," enable verbose boot to see where it's stuck.

I followed your advice, if it's not difficult - advice, what did I do wrong?opencore-2023-08-07-014947.txt

[deeveedee]

@ANTIKO You're saying that you can disable AMFIPass.kext and add amfi=0x80 boot-arg, and booting is normal, but when you enable AMFIPass.kext and remove amfi=0x80 boot-arg, boot halts at the location in your verbose log?  No other config.plist differences?

 

EDIT: Have you tried a clean macOS install with AMFIPass.kext (without amfi=0x80) to see if the new macOS installation with AMFI fully enabled is working for you?

 

EDIT2: @ANTIKO Are you resetting NVRAM after you make your config.plist change (before booting macOS)?

Edited August 6, 2023 by deeveedee

[ANTIKO]

13 hours ago, deeveedee said:

but when you enable AMFIPass.kext and remove amfi=0x80 boot-arg, boot halts at the location in your verbose log?

Yes

13 hours ago, deeveedee said:

EDIT: Have you tried a clean macOS install with AMFIPass.kext (without amfi=0x80) to see if the new macOS installation with AMFI fully enabled is working for you?

The system is already installed, is it necessary to perform a clean installation?

13 hours ago, deeveedee said:

Are you resetting NVRAM

Yes

[deeveedee]

@ANTIKO The use of AMFIPass.kext 1.3.1 is still experimental for me (although working fine), so I don't have more advice.  If your hack works best with AMFI disabled (amfi=0x80 boot-arg), then keep it that way.  With AMFI disabled, you are operating with the OCLP devs' recommended configuration, so your hack is more compliant than mine is.  I'll continue to experiment and if I have any suggestions, I'll post here.

 

Since your boot progress stopped at [EB|LOG:EXITBS:START], this might offer some clues, but I'm not sure.

 

@ANTIKO If you are able to post your config.plist that results in the halted boot, I'd like to take a look at it.  Remove your private Platform Info before posting.

Edited August 6, 2023 by deeveedee

[miliuco]

@deeveedee

Tried AMFIPass.kext 1.3.1 (latest sonoma nightly build), no amfi boot arg.

It happens to me like @ANTIKO, boot also stops in the same way.

If I wait approx. 1', I see the Desktop. But there is no wifi BCM and AMFIPass.kext doesn't seem to be loaded. I do not know why. I have added the kext in the Kexts folder and in config.plist, I have tried changing the order of the kext putting it just after Lilu, or after the sonoma-wifi related kexts, or the last one... No success.
As soon as I remove AMFIPass and add amfi=0x80, everything works fine again.

🙁

 

Edited August 6, 2023 by miliuco

[eSaF]

9 minutes ago, miliuco said:

@deeveedee

Tried AMFIPass.kext 1.3.1 (latest sonoma nightly build), no amfi boot arg.

It happens to me like @ANTIKO, boot also stops in the same way.

If I wait approx. 1', I see the Desktop. But there is no wifi BCM and AMFIPass.kext doesn't seem to be loaded. I do not know why. I have added the kext in the Kexts folder and in config.plist, I have tried changing the order of the kext putting it just after Lilu, or after the sonoma-wifi related kexts, or the last one... No success.
As soon as I remove AMFIPass and add amfi=0x80, everything works fine again.

🙁

 

Bro - I also tried with this kext using the same method you described and got the same unfavorable results.

My assumption is that our T-919 Card (BCM4360) is a different animal compared to what is working with this method.

[FirstTimeCustomac]

52 minutes ago, eSaF said:

Bro - I also tried with this kext using the same method you described and got the same unfavorable results.

It was my understanding from the previous posts that AMFIPass.kext does not work in Sonoma yet without its beta boot-arg.

Edited August 6, 2023 by FirstTimeCustomac

[eSaF]

2 minutes ago, FirstTimeCustomac said:

It was my understanding from the previous posts that AMFIPass.kext does not work in Sonoma yet without its beta boot-arg.

Unless I was mistaken it was my understanding that with the kext in place, the boot-arg was not needed.

[deeveedee]

@miliuco @eSaF @ANTIKO - @FirstTimeCustomac is correct!  must use -amfipassbeta

 

I completely forgot that this was required for Sonoma (until AmfiPass.kext is updated for Sonoma)

[eSaF]

41 minutes ago, deeveedee said:

I completely forgot that this was required for Sonoma (until AmfiPass.kext is updated for Sonoma)

Thanks - As it stands, it wouldn't make much sense to change what is working for me right now until the kext is updated because it means replacing a boot-arg with another as well as adding an extra kext to an already loaded kext folder.

Until the situation is more formalized, I think I will stay with what is working unless some major beneficial solution is offered up.

[miliuco]

1 hour ago, deeveedee said:

@miliuco @eSaF @ANTIKO @FirstTimeCustomac is correct!  must use -amfipassbeta.

I completely forgot that this was required for Sonoma (until AmfiPass.kext is updated for Sonoma)

Ok, with -amfipassbeta boot arg macOS boots fine, sonoma wifi is working and OCLP doesn't ask for re-applying root patches or any other warning.

So, the new AMFIPass.kext replaces amfi=0x80 boot arg, and I can boot Sonoma without disabling AMFI but with OCLP root patch properly applied. Is it correct?

Do you know any way to check AMFI status? Something easy as csrutil status?

I suppose that you keep csr-active-config=03080000 and SecureBootModel=Disabled as required by OCLP root patches.

Thanks for your suggestion, learning one more thing 🙂

[FirstTimeCustomac]

To be clear, I think there is a difference between amfi=0x80 and -amfipassebeta, that is, they are not exactly a replacement of one another.  amfi=0x80 is for completely disabling AMFI. On the other hand, -amfipassbeta is associated with AMFIPass.kext and is a boot-arg that would allow the AMFIPass.kext to be functional in unsupported OS before the kext gets proper update, just like how we would need -lilubetaall when testing the new version of macOS that just got released. In other words, with amfi=0x80 you are disabling AMFI but with AMFIPass.kext, you are fully enabling AMFI and library validation for enhanced security plus this would avoid problems with some apps not working if AMFI is disabled.

[miliuco]

@FirstTimeCustomac

The way you say it is how I understood it in the posts by @deeveedee. You certainly explain it very well.

[eSaF]

Ok maybe I will give it another shot and see how it goes.

[deeveedee]

13 hours ago, miliuco said:

Do you know any way to check AMFI status? Something easy as csrutil status?

@FirstTimeCustomac is spot-on with his explanation. One of the most noticeable behaviors affected by AMFI is macOS  permission prompts for privacy-related elements like Camera and Microphone.  With AMFI disabled, you will not be able to grant/deny these privacy-related permissions via standard macOS prompts.  With AMFI disabled, you will need to grant camera and microphone permissions manually (e.g., use tccplus).  When AMFI is fully enabled, you will be able to grant permissions via standard macOS prompts.  

 

For example, if you install Zoom for video conferencing, you will not be able to grant camera and microphone permissions to Zoom via standard macOS prompts when AMFI is disabled.  With AMFI enabled, you will be able to grant camera and microphone permissions to Zoom via standard macOS privacy prompts.

 

I do not know of a way to 'check AMFI status' other than examining an AMFI-related macOS behavior like this.

 

EDIT: See @mnfesq observations here.

Edited August 7, 2023 by deeveedee

[ANTIKO]

18 hours ago, deeveedee said:

-amfipassbeta

I checked with -amfipassbeta is running. Wi-Fi and Bluetooth are working. Thanks 

[jsl2000]

On 8/3/2023 at 10:35 PM, deeveedee said:

@jsl2000 Glad you at least have a working solution and am pleased to see that you have mastered Wi-Fi ACPI patching!  Well done.  Here are a few things I observed/questioned:

• You have rtcfx_exclude=00-FF paired with RTCMemoryFixup.kext.  My experience is that excluding the entire 00-FF range breaks power management (maybe other things).  It would be better for you to change RTC memory length to 0x2 (the way CLOVER fixes RTC) and to eliminate RTCMemoryFixup.
• What is your AirportBrcmFixup Min/MaxKernel strategy.  I don't understand the Min/Max limits you are imposing
    Reveal hidden contents

  

• Is OpcodeEmulator.kext helping you with anything?
• You shouldn't need these kernel patches anymore after you use AMFIPass.kext 1.3.1 (with boot-arg -amfipassbeta for Sonoma)
    Reveal hidden contents

  

• You shouldn't need boot-arg -lilubetaall since you're using -brcmfxbeta
• After applying OCLP post-install patches, I must remove Wi-Fi ACPI patches for proper operation of Wi-Fi.  I only use Wi-Fi spoofing to apply the patches and not during normal operation.  I keep one config.plist with Wi-Fi spoofing (to be used when applying OCLP post-install patches) and one config.plist without Wi-Fi spoofing (for normal operation).  This is one thing that I miss from CLOVER - the ability to select config.plist at boot time would be a great feature in Open Core.

After modified my config.plist either SSDT-ARPT.aml method or Add IOName to DeviceProperties method all can enable BCM4352 WiFi adapter in Z77 hackintosh now !

I still need modified OCLP 0.6.9 to patch its Modern Wireless, otherwise no actual WiFi connection.

Big thanks to your advice and help again !

Edited August 7, 2023 by jsl2000

[deeveedee]

@jsl2000  Sounds like good news, but a bit confusing.  

 

The modified OCLP is only necessary if you don't spoof IOName with SSDT or DeviceProperty.  The purpose of the Wi-Fi IOName spoofing is only to eliminate the need to modify OCLP - it has nothing to do with the normal operation of Wi-Fi.  See explanation here for why IOName has nothing to do with Wi-Fi operation and is only required for OCLP patching (using the official unmodified Dortania OCLP downloaded from here).

 

But I am glad it is working for you! 😁

 

For those who are still struggling with OCLP patching of Wi-Fi, here is what we learned so far:

• If OCLP is not detecting your Wi-Fi for patching, spoof IOName using SSDT or DeviceProperty as explained here and here.
• If OCLP still doesn't detect your Wi-Fi after spoofing Wi-Fi IOName (or you don't want to spoof IOName for some reason), modify OCLP as described here.  Credit to @acquarius13 for figuring out how to modify OCLP to force Wi-Fi patching.  EDIT: Follow acqarius13's post to force OCLP's modern_wifi patching.  See my post here to force OCLP's legacy_wifi patching.
• At the time of this post, if your hack needs AirportBrcmFixup.kext, include boot-arg -brcmfxbeta so that AirportBrcmFixup.kext works in Sonoma.  This boot-arg will no longer be necessary when AirportBrcmFixup.kext is updated for Sonoma.
• At the time of this post, OCLP Devs are recommending that we disable AMFI  (use boot-arg amfi=0x80) for Wi-Fi patches.  If you want to run with AMFI enabled, use AMFIPass.kext 1.3.1 without amfi=0x80 boot-arg.  At the time of this writing, AMFIPass.kext has not been updated for Sonoma, so you need boot-arg -amfipassbeta for AMFIPass.kext to work in Sonoma.  Eventually, enabling AMFI will be a recommended operating mode with a future version of OCLP.  Credit to @AppleBreak here for -amfipassbeta boot-arg.  See here and here for why you might not want to disable AMFI.
• SIP must be partially disabled for OCLP post-install patches.  Set csr-active-config as shown in the attached sample plist.

 

Note: If you are already using boot-arg -lilubetaall, you don't need to add boot-arg -brcmfxbeta.  Here is why you may not want to use -lilubetaall.

 

Note: At the time of this post, we are using a special Sonoma branch for OCLP downloaded from here. Sonoma Wi-Fi patching will eventually be part of the main OCLP branch.

 

Note: A sample config.plist that includes the pertinent configuration for OCLP post-install patching is attached.  Copy the items you need from the attached config.plist into your own.  The attached sample plist injects AMFIPass.kext (with boot-arg -amfipassbeta) so that AMFI can be fully enabled.  If you would prefer to disable AMFI, add boot-arg amfi=0x80, remove boot-arg -amfipassbeta and disable AMFIPass.kext.

sample-oclp-config.plist.zip

Edited August 10, 2023 by deeveedee

[miliuco]

@deeveedee

Excellent summary!!! To be saved, next to different texts posted last days. 

[miliuco]

13 hours ago, eSaF said:

Ok maybe I will give it another shot and see how it goes.

If you read @deeveedee and @FirstTimeCustomac explanations, having AMFI enabled seems to be a good thing, and we can have wifi at the same time with OCLP root patch.

[jsl2000]

52 minutes ago, deeveedee said:

@jsl2000  Sounds like good news, but a bit confusing.  

 

The modified OCLP is only necessary if you don't spoof IOName with SSDT or DeviceProperty.  The purpose of the Wi-Fi IOName spoofing is only to eliminate the need to modify OCLP - it has nothing to do with the normal operation of Wi-Fi.  See explanation here for why IOName has nothing to do with Wi-Fi operation and is only required for OCLP patching (using the official unmodified Dortania OCLP downloaded from here).

 

But I am glad it is working for you! 😁

 

 

 

 

Thanks for your comments.

Yes, I still need modify OCLP to patch WiFi even IOName was spoof with SSDT or DeviceProperties, otherwise only Ivy Graphics was patached without Modern Wireless option.

Without IOName spoof with SSDT or DeviceProperties my BCM4352 can not be shown at Peripherals of Hacintool.

Can you check whether my spoof was correct ?

1520200897_Jin-ShinsiMac.ioreg