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

[MakAsrock]

6 hours ago, carlo_67 said:

And who says this? OCLP-MOD 3.1.4 works great with 26.2/3 and already has the features to download the KDK. We just have to wait for the 26.4 beta release.

 

 

So why allow this patch? My checkpoint is unchecked by default.

[carlo_67]

because on 26.1/2/3 it makes appleHDA work, it just needs to be removed on 26.4 beta and once KDK 26.4 is released it will also work fine on 3.1.5 -MOD

[kgp]

@carlo_67, @MakAsrock, I may be misunderstanding the discussion, but I think you might be talking past each other.

OCLP-Mod 3.1.5 and OCLP Nightly 3.1.6 should both work on 26.4 beta 1 when the AppleHDA patch is disabled. Once the appropriate KDK becomes available (likely with beta 2), the modern audio patch should also work on both patchsets. Both patchsets are fully backwards-compatible with macOS 26.0 to 26.3. 

@carlo_67, have you had a chance to look at the recent changes we introduced regarding the fork of OCLP 3.0.0 Nightly? The details are summarised on page 1 of this thread.

I’m not sure this line of discussion is moving us forward.

 

Cheers, KGP 👍

Edited February 22 by KGP-iMacPro

[cloudy]

Hello,

What would be the solution if VMWareFusion throws an error when option "amfi=0x80" is added to boot-arg? 

"ipc_control_port_options=0" boot-arg option has nothing to do with this issue.

Thank you.

[xenophon]

7 hours ago, cloudy said:

Hello,

What would be the solution if VMWareFusion throws an error when option "amfi=0x80" is added to boot-arg? 

"ipc_control_port_options=0" boot-arg option has nothing to do with this issue.

Thank you.

IIRC, the Secure Boot Model is the issue with VMWare; please have a look here: https://github.com/cgrazy/OC_EFI_Gigabyte_Z690_AlderLake_I9_12900K

[cloudy]

Thank you for your reply, xenophon. Secure Boot, as you mentioned, doesn't seem to be relevant at the moment, as VirtualBox works normally.

[Komar aka Kali]

Hi my friends...!!!🙂

Long time that I´m not write in this site.

Just wanted to say thanks again for all the information gathered in this site. 
All on my machine is working perfectly with Tahoe 26.3.
Good job...!!!

 

[kgp]

Hi folks,

By testing different OpenCore / OCLP configurations on macOS Tahoe (26.x), I encountered a number of recurring issues. 
The following troubleshooting notes summarize proven fixes that may help others facing similar problems, regardless of the exact OCLP version or fork used.

--------------------------------------------------------------------
General Troubleshooting Notes for OCLP on macOS Tahoe (26.x)
--------------------------------------------------------------------

1.) Safe testing of EFI / OCLP configurations

When testing different OpenCore / OCLP setups (e.g. different patchsets, boot arguments such as amfi=0x80 or -amfipassbeta, or enabling/disabling AMFIPass.kext), the safest approach is to use a separate EFI on a USB stick or secondary disk.

Boot your system disk using the test EFI via the BIOS boot menu (e.g. F8 on ASUS boards). 
This allows you to quickly switch back to a known working configuration if something goes wrong.

This approach makes recovery straightforward in case of a non-booting system due to an incorrect EFI configuration.

----

2.) Recovering a non-booting system (sealed snapshot)

If patching goes wrong and the system no longer boots, you can revert to the last sealed system snapshot from Recovery Mode.

 

Example:

mount -uw "/Volumes/Sequoia-Test"
bless --mount "/Volumes/Sequoia-Test" --bootefi --last-sealed-snapshot

Replace “Sequoia-Test” with the actual name of your macOS system volume.

 

Note: 
This restores the last sealed snapshot. Any system modifications performed after that snapshot (e.g. root patches or updates) will be reverted.

This is often the fastest and most reliable way to recover from a failed root patch or incompatible configuration.

----

 

3.) Wi-Fi connects as hidden network

If your Wi-Fi network suddenly appears as a hidden network:

- Go to Wi-Fi settings 
- Choose “Forget This Network” 
- Reconnect normally 

This typically restores normal Wi-Fi behavior.
 

----

 

4.) AirDrop not working at all

If AirDrop does not work at all:

- Delete the Wi-Fi service in Network Settings 
- Re-add it (Add Service → Wi-Fi) 

This often restores full AirDrop functionality.

----

 

5.) AirDrop works only in one direction

Symptom: 
- Hackintosh sees other devices 
- Other devices do NOT see the Hackintosh 

If a test user works but your normal user does not, the issue is usually caused by corrupted user-level AirDrop / IDS state and reboot your system:

 

Reset the corresponding user data (IdentityServices / IDS / Sharing related preferences) and reboot your system:

killall sharingd
killall Finder

rm -rf ~/Library/IdentityServices
rm -rf ~/Library/Sharing
rm -rf ~/Library/Application Support/com.apple.ids
rm -rf ~/Library/Application Support/com.apple.sharingd

rm -f ~/Library/Preferences/com.apple.ids*
rm -f ~/Library/Preferences/com.apple.im*
rm -f ~/Library/Preferences/com.apple.sharingd*

sudo reboot

If the Hackintosh is still not visible to other devices afterwards:

 

- Delete the Wi-Fi service in Network Settings 
- Re-add it (Add Service → Wi-Fi) 

After doing this, AirDrop should work again for both sending and receiving.

 

----

 

6.) Sporadic AirDrop issues after wake (AWDL state)

After wake from sleep, AirDrop may behave inconsistently:

- nearby devices may not appear 
- the Hackintosh may not be discoverable by other devices 

Typical observations:
- Wi-Fi is fully functional 
- Bluetooth is powered on and connected devices remain active 
- awdl0 is up and reports "status: active" 
- AirDrop UI is available, but discovery is incomplete 

Key difference:
- Non-working state: Schedule State = Idle 
- Working state: Schedule State = Unknown (44) 

This indicates that AWDL is not fully re-initialized after wake, even though the interface itself is active.

Temporary workaround:
- Toggle Bluetooth off/on via menu bar, or 
- Run: 

sudo killall -9 bluetoothd 

This forces a reinitialization of the Bluetooth/AWDL stack.

After doing this, AirDrop works again normally and nearby devices become visible.

A fully automated workaround using SleepWatcher is described here: 

 

 

----

 

General notes on OCLP behaviour:

During testing, all major OCLP patchsets proved to be generally functional on macOS Tahoe (26.x), including:

- AppleHDA 
- Wi-Fi 
- AirDrop 
- AirPlay 
- Screen Mirroring 

However, behavior may vary depending on:
- selected boot arguments (e.g. amfi=0x80 vs. -amfipassbeta) 
- AMFIPass.kext usage 
- AppleVTD / DisableIOMapper configuration 
- the specific OCLP fork and its patching logic 

----

 

Cheers,
KGP 👍

Edited April 23 by kgp
Post conversion to General Troubleshooting Notes for OCLP on macOS Tahoe (26.x)

[MakAsrock]

6 hours ago, KGP-iMacPro said:

Hi folks,

By testing the different available OCLP forks during the last days on my system, I ran into a few issues that might also help others. Here are a few troubleshooting tips that solved real problems on my system.

----

1.) If you mix up with AMFI boot-args during experiments with OCLP 3.0.0, OCLP 3.1.6 or OCLP-Mod 3.1.5:

If you play with boot-args such as amfi=0x80, -amfipassbeta, or enable/disable AMFIPass.kext, always keep a known-good EFI on an alternative bootable device.

This makes it easy to recover if the system no longer boots due to an incorrect EFI-configuration.

----

2.) If patching goes wrong and the system no longer boots:

You can revert to the last sealed snapshot from Recovery Mode.

Example:

mount -uw "/Volumes/Sequoia-Test"
bless --mount "/Volumes/Sequoia-Test" --bootefi --last-sealed-snapshot

Replace “Sequoia-Test” with the actual name of your macOS system volume.

Note: This command restores the last sealed system snapshot. Any system modifications made after that snapshot (for example root patches or recent updates) will be reverted.

----

3.) Wi-Fi suddenly connects as a hidden network:

If your Wi-Fi network suddenly appears as a hidden network:

Go to Wi-Fi settings

Choose Forget This Network

Reconnect normally

This immediately restored normal Wi-Fi behaviour in my tests.

----

4.) If Airdrop does not work at all, try to remove and re-add the Wi-Fi service in Network Settings.

----

5.) AirDrop works only in one direction:

Symptom:

Hackintosh sees other devices

Other devices do not see the Hackintosh

If a test user works but your normal user does not, the issue is caused by corrupted user AirDrop / IDS state.

Reset the following user data:

killall sharingd
killall Finder

rm -rf ~/Library/IdentityServices
rm -rf ~/Library/Sharing
rm -rf ~/Library/Application Support/com.apple.ids
rm -rf ~/Library/Application Support/com.apple.sharingd

rm -f ~/Library/Preferences/com.apple.ids*
rm -f ~/Library/Preferences/com.apple.im*
rm -f ~/Library/Preferences/com.apple.sharingd*

Reboot afterwards.

 

If AirDrop still does not start, remove and re-add the Wi-Fi service in Network Settings in addition. 

After doing this, AirDrop worked again for sending and receiving.

----

During all my recent tests, I focused on both OCLP 3.0.0 and OCLP-Mod 3.1.5 under macOS Tahoe 26.3.1. Both patchsets are fully working on my system, including AppleHDA, Wi-Fi, AirDrop, AirPlay and Screen Mirroring. OCLP 3.0.0 works with AMFIPass.kext enabled in line with boot-arg "amfi=0x80". OCLP-Mod 3.1.5 works with AMFIPass.kext enabled in line with boot-arg "amfi=0x80" or "-amfipassbeta". On my system and in contrary to the claims of the author, OCLP-Mod 3.1.5 does not work with AppleVTD enabled (DisableIOMapper=false). My system boots, but WI-Fi would be unavailable.     

 

Missing: detailed tests of OCLP 3.1.6 functionality on my system.  

 

Cheers,
KGP 👍

I tried enabling the boot argument -amfipassbeta amfi=0x80 ipc_control_port_options=0 revpatch=sbvmm,auto revcpu=1 ctrsmt=full and putting EFI/CLOVER/kexts/26/AMFIPass.kext into Clover. After that, AirDrop stopped working for me.
Had to return everything back. 🙁
I have Clover revision: 5170 (master, commit 97c403d95) as the main bootloader. It allows you to block any kext by pressing space and selecting the desired one in the main menu if loading ends in a kernel panic.
Since Open Core can't do this, I didn't dare try it. 🤔

Edited March 7 by MakAsrock

[kgp]

Update to Post #1: macOS Tahoe 26.4 Beta 4

 

With the release of the matching Kernel Debug Kit (KDK) for macOS 26.4 beta 4, root patching works normally again.

 

Earlier patching issues observed in 26.4 beta 1 were most likely caused by a temporary HFS+ mounting bug, which Apple already fixed in beta 2, combined with the absence of a matching KDK in the following betas.

 

With the correct KDK now available, the AppleHDA root patch can again be built against valid kernel symbols, and modern Wi-Fi (AirDrop, AirPlay, Screen Mirroring) as well as AppleHDA audio work normally again.

 

All patchers are confirmed working:

OCLP 3.0.0 Nightly (reference snapshot)

OCLP-Mod 3.1.5

OCLP 3.1.6 Nightly

 

Booting works with:

amfi=0x80
with AMFIPass.kext enabled or disabled.

 

OCLP-Mod 3.1.5 can also boot using:

-amfipassbeta

instead of amfi=0x80.

 

Post #1 of this thread has been updated accordingly to reflect the current understanding of macOS 26.4 behavior and KDK requirements.

So in hindsight, the whole “26.4 HFS+ drama” turned out to be a short-lived beta hiccup rather than something that would have required a fundamental change in the patching workflow.

Edited March 20 by KGP-iMacPro

[D-an-W]

Not had time to update in a while, looks like I missed the issues so maybe a good thing!

 

All working well on beta 4 

[Alpha22]

OCLP-YBronst 3.1.7 audio and Wi-Fi working

 

@MakAsrock AMFIPass cannot be used with OCLP 3.1.7 due to a persistent kernel panic. Instead, use the amfi=0x80 boot argument.

If I don’t use AMFIPass.kext in Clover/kext/26, OCPL 3.1.7 doesn’t work

 

If I use AMFIPass.kext in Clover/kext/26, OCPL 3.1.7, the audio and Wi-Fi work

  

[jmmc]

Is it better using AMFIPass.kext than the boot arguments?

 

I'm on 26.3.1 with OCLP 3.1.6, which way would you recommend me to use?

 

Thanks!

[MakAsrock]

6 hours ago, Alpha22 said:

OCLP-YBronst 3.1.7 audio and Wi-Fi working

 

@MakAsrock AMFIPass cannot be used with OCLP 3.1.7 due to a persistent kernel panic. Instead, use the amfi=0x80 boot argument.

If I don’t use AMFIPass.kext in Clover/kext/26, OCPL 3.1.7 doesn’t work

 

If I use AMFIPass.kext in Clover/kext/26, OCPL 3.1.7, the audio and Wi-Fi work

  

I wrote about using it with Open Corpe, but when you using it in Clover, you need both AMFIPass.kext and amfi=0x80.
To solve the problem of launching Firefox and some other applications, pc_control_port_options=0 is required.

Edited March 15 by MakAsrock

[MakAsrock]

52 minutes ago, jmmc said:

Is it better using AMFIPass.kext than the boot arguments?

 

I'm on 26.3.1 with OCLP 3.1.6, which way would you recommend me to use?

 

Thanks!

With Clover — both.

Edited March 15 by MakAsrock

[kgp]

Also with OpenCore, one can use both, AMFIPass.kext (enabled) with boot argument “amfi=0x80”. Alternatively one can also boot with boot argument “amfi=0x80” only (AMFIPass.kext disabled). 

Edited March 15 by KGP-iMacPro

[jmmc]

16 hours ago, KGP-iMacPro said:

Also with OpenCore, one can use both, AMFIPass.kext (enabled) with boot argument “amfi=0x80”. Alternatively one can also boot with boot argument “amfi=0x80” only (AMFIPass.kext disabled). 

Is it true that AMFIPass.kext is considered safer than using the amfi=0x80 boot-arg, particularly in terms of app compatibility and system integrity?

[LockDown]

Only use amfi=0x80 if amfipass.kext does not work

[kgp]

40 minutes ago, jmmc said:

Is it true that AMFIPass.kext is considered safer than using the amfi=0x80 boot-arg, particularly in terms of app compatibility and system integrity?

Yes.. AMFIPass.kext is safer in terms of app compatibility and system integrity. However, only OCLP-Mod allows one to use AMFIPass.kext with boot argument “-amfipassbeta”. With OCLP you must use boot argument “amfi=0x80” and you can disable AMFIPass.kext or leave it enabled. 

[MakAsrock]

In all cases except OCLP-Mod

AMFIPass Alert: Do NOT use AMFIPass.kext standalone. In macOS Tahoe, this version causes persistent kernel panics during boot.

Solution: You must use AMFIPass.kext (v1.4.1 or later) in combination with the boot argument amfi=0x80 to successfully bypass Apple Mobile File Integrity checks.

Note: If you experience issues with third-party browsers (like Firefox) or camera/mic permissions, consider adding ipc_control_port_options=0 to your boot-args as well.
Cheers. 🥂

[kgp]

OCLP 3.0.0 Nightly (lzhoang2801) working on macOS Tahoe with -amfipassbeta (AppleHDA + full AWDL)

 

Hi folks,

after implementing and testing this approach today, I would like to share a clean and reproducible setup based on the final OCLP 3.0.0 Nightly snapshot (lzhoang2801), adapted to work reliably on macOS Tahoe using AMFIPass.kext with the boot argument -amfipassbeta.

 

What this is

This is not a new patcher, but a preserved OCLP 3.0.0 snapshot with one crucial adjustment:

➡️ The PatcherSupportPkg source has been replaced with a restored version that includes complete Universal-Binaries (most importantly AppleHDA).

No root patch logic has been modified.

 

Result

With this setup, I can confirm fully working:

AppleHDA (modern audio)

Wi-Fi

AWDL stack:

- AirDrop (fully functional, bidirectional)

- AirPlay

- Screen Mirroring

Continuity:

- Handoff works (e.g. Mail, Notes, Safari)

- Sidecar is currently not functional.

 

Everything has been tested on:

macOS 26.4 public beta 4 and macOS 26.4 RC

 

Boot argument

This setup uses AMFIPass.kext with:

-amfipassbeta

No need for amfi=0x80.

 

Repositories

OCLP (amfipassbeta variant)

https://github.com/kgp-macPro/OCLP-lzhoang2801-amfipassbeta

PatcherSupportPkg (restored Universal-Binaries incl. AppleHDA)

https://github.com/kgp-macPro/PatcherSupportPkg-laobamac

 

Notes

• This is a preserved reference implementation, not an official Dortania release
• No experimental patch logic has been introduced
• The goal is to restore the original Tahoe patchset functionality in a reproducible way

 

Background

With the correct PatcherSupportPkg in place, the original patchset also works with AMFIPass.kext using:

-amfipassbeta

This enables modern audio (AppleHDA) and restores full AWDL functionality as originally intended.

 

Final thoughts

I hope this helps others who were struggling with:

Apps not working due to the previous boot argument amfi=0x80

missing AppleHDA

broken AirDrop

inconsistent AWDL behavior

This setup finally provides a stable and reproducible baseline again.

 

Cheers,
kgp 👍

Edited March 20 by KGP-iMacPro

[Alpha22]

I've tested this version of OCLP 3.0.0 Nightly (lzhoang2801) running on macOS Tahoe with the -amfipassbeta flag, and it works

 

       

 

Edited March 19 by Alpha22

[MakAsrock]

 

[MakAsrock]

I want to ask you friends: Should I continue to refine the OCLP-Plus Tahoe Patch Set or freeze it in its current form?

[XanthraX]

Why not to continue? I tried it and Firefox works for me. I have problems with Microsoft Teams, but I think is something in my system and is not dependent to OpenCore or OCLP. VMWare Fusion not working, but Parallels Desktop works. 

Unfortunately I have read a not promissing rumor. I hope to be just a rumor. It is in French, but they said the original OCLP may be stopped. Also they asked for the enthusiasts to stop donate money. If this is true, so your team and laobamac can be the only hope. 

https://www.reddit.com/r/OpenCoreLegacyPatcher/comments/1s0mbo6/oclp_et_macos_tahoe_entre_stagnation_technique_et/?share_id=TdApEFfxfUZLkOkopMtzu&utm_content=2&utm_medium=ios_app&utm_name=ioscss&utm_source=share&utm_term=1