Experimental Fork of OCLP 3.0.0 Nightly – modern Wi-Fi, AWDL and AppleHDA Fully Working under Tahoe

[mick3lson]

I just installed it on my Dell XPS 9570 with Intel AX200 wifi card and everything works fine except airdrop. Thank's MakAsrock for your effort. I wanted to know if airdrop works with Intel wifi card.

Edited January 7 by mick3lson

[kgp]

1 hour ago, mick3lson said:

I just installed it on my Dell XPS 9570 with Intel AX200 wifi card and everything works fine except airdrop. Thank's MakAsrock for your effort. I wanted to know if airdrop works with Intel wifi card.

 

Good observation! I hardly ever use AirDrop, but I gave it a try now with my AX210:

 

OCLP Nightly 3.0.0 (MakAsrock)
– Builds from 31-12-2025 and 06-01-2026: AirDrop not functional

OCLP Nightly 3.0.0 (Izhoang2801)
– Build from 11-12-2025: AirDrop not functional

 

 

OCLP-Mod 3.1.3 (laobamac)
– One-directional only (from Hackintosh to iPhone 16 Pro), sometimes with a significant delay

 

 

– With none of the available patches is my Hackintosh visible on the iPhone 16 Pro under AirDrop

 

In all my previous tests with my BCM943602CDP, AirDrop worked flawlessly in both directions. Sooner or later, I will return to using my Broadcom. If anyone would like me to run further tests with the AX210, please let me know as soon as possible:
@laobamac_yyds ?  @MakAsrock?

 

Edited January 7 by KGP-iMacPro

[deeveedee]

I am going to be installing a BCM943602CS in my hack for OCLP testing.  Am I correct in my understanding of the following?

• If I want to use boot-arg amfi=0x80, I use Experimental Fork of OCLP 3.0.0 Nightly (this thread)
• If I want to use AMFIPass.kext with boot-arg -amfipassbeta, I use OCLP Mod

Is that correct?  Is there any other reason to choose one OCLP solution over the other?

Edited January 7 by deeveedee

[mick3lson]

Thanks for your clarification, I will try to do some tests. Same situation, my other hack Z790+BCM94360 AirDrop work flawlessly. 

Edited January 7 by mick3lson

[kgp]

1 hour ago, MakAsrock said:

Update: I finally got the PCIe adapter with the BCM943602CDP and tried it on my Hack. Unfortunately, the airdrop sometimes doesn't work with this particular card +OCLP 3.0.0 Nightly and OCLP Mod.

 

I initially performed all tests of airdrop with my BCM943602CDP with OCLP 3.0.0 Nightly of izhoan2801 and everything worked flawlessly in both ways. By then, others confirmed the same for BCM43602CS and Fenvi. As soon I am at home later at night or maybe sometimes tomorrow, I will remove my AX210 and will continue testing my BCM43602CDP with all available methods. Stay tuned. 

 

Best regards,

 

KGP

Edited January 7 by KGP-iMacPro

[kgp]

As promised here are my tests with my BCM943602CDP under Tahoe 26.2!

 

 

OCLP Nightly 3.0.0 (MakAsrock)
Build from 05-01-2026: AirDrop fully functional and 100% reliable in both ways (Hackintosh -> iPhone 16 Pro and iPhone 16 Pro -> Hackintosh)

 

OCLP-Mod 3.1.3 (laobamac)

AirDrop fully functional and 100% reliable in both ways (Hackintosh -> iPhone 16 Pro and iPhone 16 Pro -> Hackintosh)

 

 

 

Airdrop behaves absolutely flawlessly with my BCM943602CDP under Tahoe 26.2 with all available methods! NO issues at all! All Issues with Airdrop are restricted to the Intel AX210.

 

Important note: After replacing my AX210 with my BCM943602CDP, I had to delete and re-add "Wi-Fi" under "System Settings" -> "Network" to make Wi-Fi work at all.

 

@laobamac_yyds, @MakAsrock, anything we could do to make Airdrop reliably work with the AX210, too? In any case, Airdrop works 100% reliable with my BCM943602CDP. I would also have a OSX WIFI BCM 94360CD for testing. However, I suppose that the results would be the same. 

Edited January 8 by KGP-iMacPro

[kgp]

22 minutes ago, MakAsrock said:

I started testing the new PCIe adapter with Bluetooth WIFI Card BCM943602CDP For iMac 21.5 and the patches that were in the original OCLP 3.0.0 set, and firedrop doesn't work every time after sleep. But one thing is good, I found out that it was all problems related to sleep.

 

I am still facing issues with sleep/wake (instant wake on sleep) also with my BCM943602CDP. This did not happen before. Something must have changed on my system. However, everything continues working flawlessly after instant wake from sleep. Debugging is on the way. 👍

 

BTW.. did you see my latest post above? Airdrop 100% reliably working with my BCM943602CDP and your latest OCLP 3.0.0 Nightly or OCLP-Mod 3.1.3!  

Edited January 8 by KGP-iMacPro

[fredouille]

19 hours ago, KGP-iMacPro said:

 

Apparently you also misunderstood the reason for my reply to @fredouille above.

 

In post 

@D-an-W sent me a screenshot of his Kernel section and asked me to order his kexts based on his screenshot. It is obvious that the order of kexts can be changed easily by OCAT or OCC with a config.plist available, which however was not the case. Due to the screenshot, I had to list and reorder all kexts manually within the text editor for post

 

All this just to avoid further confusion or misunderstandings. 😉 

  

Hello friend,

In fact there is a misunderstood, because Xanthrax answer that was for me also the method, just a bit different, I use rignet click in the line of the kext in kernel section of OCAT, just like this:

 

Just now, fredouille said:

Hello friend,

In fact there is a misunderstood, because Xanthrax answer that was for me also the method, just a bit different, I use rignet click in the line of the kext in kernel section of OCAT, just like this:

 

and I have to add also that since I use the Mieze kext for 2.5 GB ethernet in addition of appleGC.kext, I loose my USB port (keyboard an mouse) afeter wake from sleep !so I revert back to my classic config!!

Thank you KGP-iMacPro for your constant help ! much appreciated.

Have a nice day !

regards

fred

[kgp]

7 hours ago, MakAsrock said:

Finished a clean install of Tahoe. Everything works, including Airdrop. I don't know what that was. The only thing I did was move the Wi-Fi kexts up a few notches, placing them right after AppleALC.kext while maintaining sequence.

UP: With Clover, there were no glitches before.

 

Are we talking about your new BCM943602CDP? What about sleep/wake? I am still facing instant wake on sleep and continue debugging... for testing purposes, I simply unplugged my BCM943602CDP and my system sleeps flawlessly. Maybe it is my PCIe adapter?https://www.ebay.de/itm/264398686452

Edited January 8 by KGP-iMacPro

[kgp]

2 hours ago, MakAsrock said:

Yes, it's pretty much the same, only from AliExpress. Everything works, including sleep mode and airdrop. I don't know what's wrong, but Wi-Fi/Bluetooth card from an iMac21. At first, I had a hard time getting it all to work. PCIe is unlikely to have any effect, it’s just a simple adapter.

 

sleep/wake issue solved by simply changing the USB port. sleep/wake now works flawlessly also with the BCM943602CDP. Remaining issue: Airdrop does not find any device after wake from sleep (although bluetooth and wi-fi remain fully functionally). After toggling bluetooth off/on after wake from sleep, also Airdrop continues working flawlessly.   

Edited January 8 by KGP-iMacPro

[kgp]

On 1/9/2026 at 6:24 AM, MakAsrock said:

I'm not sure, but perhaps adding BlueToolFixup.kext and two keys to config.plist like as described here.
You will need to set the following NVRAM variables through your bootloader for at least Intel Bluetooth to work:

7C436110-AB2A-4BBB-A880-FE41995C9F82:bluetoothExternalDongleFailed — 00
7C436110-AB2A-4BBB-A880-FE41995C9F82:bluetoothInternalControllerInfo — 00000000000000000000000000000

I encountered a problem with the Wireless Module BCM943602CDP 4.2 and opened a dispute with the seller regarding a return or exchange. The module stops working 15 minutes after turning on the computer, and I was temporarily forced to switch back to my old FENVI FV-HB1200 (BCM94360).

 

Thanks for the suggestion, but I think there is a small misunderstanding here 🙂

 

In my last post above, I was referring solely to my BCM943602CDP.

I already use BlueToolFixup.kext and the mentioned NVRAM keys for my AX210 as a fixed part of my Intel EFI folder distribution. To my knowledge, BlueToolFixup.kext is neither required nor applicable for Broadcom cards such as the BCM943602CDP/CS or BCM94360, which rely on Apple’s native Bluetooth and Wi-Fi stacks.

 

Current state of my BCM943602CDP:

 

- Bluetooth and Wi-Fi remain fully functional after wake

Update:

- The only issue was that AirDrop did not discover any devices after wake until Bluetooth was toggled off/on once. This issue was USBMap.kext related and has been removed now. Also Airdrop is now fully functional after wake.  

Edited January 16 by KGP-iMacPro
Update: airdrop connectivity fixed after wake from sleep

[Dragster27]

Hi there folks! Thank you so much for making this possible. 

 

I'm having issues with Tahoe 26.2 after root patching it with OCLP 3.0.0 ß... I managed to patch Audio and Wireless but after patching it and making the proper changes (i.e. removing intel--->bcm spoofing), macOS Tahoe won't boot. It gets stuck during the boot process.

 

The machine boots with the same config.plist to MacOS Sequoia (patched with OCLP 2.4.1..working intel wifi AX210)... so, wonder if anyone is willing to take a look at my config.plist.

 

Thank you,

D.

config.plist

Edited January 9 by Dragster27

[kgp]

OMG... this will never work such, my friend. 🤔

 

This config.plist is seriously misconfigured.

 

Please strictly follow the respective guidelines in post #1 (and the linked posts therein) and use my Intel EFI folder distribution as the baseline. You may also start from the attached config.plist, where I reduced the kexts and boot-args to the absolute minimum required. 

 

Also make sure you:

- create a proper USBMap.kext

- apply correct IOName spoofing

 

At this point, there is unfortunately not much more I can do to help. Once you have things sorted out, I’ll be happy to provide further assistance.

 

Suerte y animo! 🤗

 

KGP

config.plist

[Dragster27]

3 hours ago, KGP-iMacPro said:

 

OMG... this will never work such, my friend. 🤔

 

This config.plist is seriously misconfigured.

 

Please strictly follow the respective guidelines in post #1 (and the linked posts therein) and use my Intel EFI folder distribution as the baseline. You may also start from the attached config.plist, where I reduced the kexts and boot-args to the absolute minimum required. 

 

Also make sure you:

- create a proper USBMap.kext

- apply correct IOName spoofing

 

At this point, there is unfortunately not much more I can do to help. Once you have things sorted out, I’ll be happy to provide further assistance.

 

Suerte y animo! 🤗

 

KGP

 

config.plist 42.09 kB · 0 downloads

Thanks buddy, clearly not an expert here... or willing to spend much time with it.. .but I'll follow your recommendations and start from scratch with yours as baseline.

 

Cheers,

D.

[D-an-W]

Spoiler

 

 

Thank you, do you mean I can now enable Whatevergreen?

 

 

Spoiler

 

[kgp]

31 minutes ago, D-an-W said:

  Hide contents

 

 

Thank you, do you mean I can now enable Whatevergreen?

 

 

  Hide contents

 

 

Yes, with WhateverGreen v1.7.1d7 you should be able to keep WhateverGreen enabled during both a clean installation and OTA updates. This is the only difference compared to the regular 1.7.1 release.

As a first step, you can try booting from a USB installer. If you are able to reach the macOS installer GUI, everything should also work fine for the OTA update.

[D-an-W]

10 hours ago, KGP-iMacPro said:

 

Yes, with WhateverGreen v1.7.1d7 you should be able to keep WhateverGreen enabled during both a clean installation and OTA updates. This is the only difference compared to the regular 1.7.1 release.

As a first step, you can try booting from a USB installer. If you are able to reach the macOS installer GUI, everything should also work fine for the OTA update.

 

Can't actually boot with it enabled!

[kgp]

9 minutes ago, D-an-W said:

 

Can't actually boot with it enabled!

Which boot issue are you referring to?

Can you boot with the official 1.7.1 release?

Did you try using the boot argument agdpmod=pikera?

In any case, this is getting quite off topic here. 😉

 

[Sicole1811]

Hey guys 

I’m having a problem running the experimental oclp. Running the patcher seems normal until towards the end, see photo. Something about usb 

[Max.1974]

I prefer to use NootRX with agdpmod=pikera and BRG0 together 😉 

I’m not sure whether, with the new OCLP, using WEG is mandatory. 

If it is, I apologize—please disregard that information. 

Some manufacturers made their RX 6900 cards using the same Device ID as Apple’s original one, but in my case the Gigabyte AORUS RX 6900 XT Rev. 2 is not 100% native and requires a patcher.

[kgp]

2 minutes ago, Max.1974 said:

 

I prefer to use NootRX with agdpmod=pikera and BRG0 together 😉 

I’m not sure whether, with the new OCLP, using WEG is mandatory. 

 

If it is, I apologize—please disregard that information. 

 

WEG is not mandatory at all for OCLP. It just might help with HDAU, but the latter also can be configured via a SSDT. Everything off topic here anyway 😉

Edited January 10 by KGP-iMacPro

[Max.1974]

Just now, KGP-iMacPro said:

 

WEG is not mandatory at all for OCLP. Everything off topic here 😉

 

Sorry about it.  

[kgp]

5 minutes ago, Max.1974 said:

 

Sorry about it.  

 

Never mind, my friend. A little bit of off-topic discussion can sometimes be good for a thread.  

I also provide NootRX as an alternative to WEG in my EFI-Folder distribution. The advice from @MakAsrock regarding the 6900 XT is more than appreciated as well. After all, six hands work better than two.  

[Sicole1811]

3 hours ago, Sicole1811 said:

Hey guys 

I’m having a problem running the experimental oclp. Running the patcher seems normal until towards the end, see photo. Something about usb 

Update

 

turned out it was a USBMap issue.. well not the usbmap kext.. I was using utbmap kext so I reverted to the usbmap kext I had and the patcher ran without issue. Now have working WiFi and audio.

[kgp]

1 hour ago, MakAsrock said:

I don't know if everyone needs this, but just in case.

For all users with RTL8125 wired network cards using OCLP Nightly 3.0.0 or OCLP-Mod 3.1.1:

Add new entry in  Kernel/Block com.apple.driver.AppleEthernetRL  25.0.0  Exclude  Enabled

 

You might want to mention that this was discovered and proposed by our friend, @laobamac_yyds already some time ago:

 

 

Edited January 12 by KGP-iMacPro