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

[kgp]

 

 

 

This thread provides setup guidelines, general troubleshooting notes for OCLP on macOS Tahoe (26.x), and discussion for stable and fully working OCLP patchsets based on the experimental OCLP 3.0.0 Nightly patchset originally forked from Dortania by lzhoang2801.

 

The focus of this thread is strictly Hackintosh systems.

 

This is NOT a general unsupported-Mac patching project and is not intended for legacy Intel Macs requiring graphics acceleration patches or broader root patch support.

 

The maintained patchsets intentionally remain as close as possible to the original OCLP 3.0.0 Nightly Tahoe baseline released by the OCLP developers and later preserved by lzhoang2801.

 

No new experimental root patch logic has been introduced.

 

The fork only enables and preserves the original Tahoe patch functionality already implemented by the OCLP developers.

 

The original fork by lzhoang2801 is still publicly available, but is no longer maintained as a fully working release by its original author. This thread preserves and maintains reproducible and fully working reference environments.

The respective patchsets currently restore the following functionality on supported Hackintosh configurations:

a.) modern audio (AppleHDA) -- functional 
b.) modern Wi-Fi -- functional 
c.) AWDL stack:
- AirDrop -- fully functional, bidirectional 
- AirPlay -- functional, bidirectional 
- Screen Mirroring -- functional, bidirectional 

- Continuity Camera -- functional

- Personal Hotspot -- functional 

d.) Continuity:
- Handoff -- functional (e.g. Mail, Notes, Safari) 
e.) Sidecar -- currently not functional 

 

---

Table of Contents

---

1.) Status (April 2026)
2.) Repositories
- OCLP 3.0.0 Nightly – amfipassbeta Edition
- OCLP 3.0.0 Nightly – Preserved Reference Edition
3.) AMFI Configurations
4.) Important (KDK Requirement)
5.) macOS Compatibility
6.) Technical Background
7.) Important Notes
8.) Credits

---

9.) Prerequisites and Setup
9.1.) Prerequisites 
9.2.) EFI-Folder Distribution
9.3.) Broadcom Wi-Fi Configuration
9.4.) Intel Wi-Fi Configuration
9.5.) Important Compatibility Notes
- RTL8125 Ethernet
- IntelMausi.kext v1.0.8
9.6.) OpenCore-Patcher Installation
9.7.) Root Patching

---

10.) Verified Functional Results
10.1.) Wi-Fi
10.2) AirDrop
10.3) AirPlay
10.4) Screen Mirroring
10.5) AppleHDA

---

11.) General Troubleshooting Notes for OCLP on macOS Tahoe (26.x)
11.1.) Safe testing of EFI / OCLP configurations
11.2.) Recovering a non-booting system
11.3.) Wi-Fi connects as hidden network
11.4.) Wi-Fi or AirDrop not working at all
11.5.) AirDrop works only in one direction
11.6.) Sporadic AirDrop issues after wake
11.7.) Avoid FileVault
11.8.) Optimized Sleep/Wake settings
11.9.) Sequential OTA Updates
11.10.) Fully automated OCLP root patching during OTA Updates

11.11.) General OCLP Behavior Notes 

---

12.) Intel Wi-Fi (Configuration / Results / History)
13.) Thread Updates and Changelog

 

---

1.) Status (April 2026)

The Tahoe patch ecosystem currently consists of three distinct branches:

 

a.) Stable reference environment
OCLP 3.0.0 Nightly – Preserved Reference Edition

 

b.) Recommended modern setup
OCLP 3.0.0 Nightly – amfipassbeta Edition

c.) Active development branch:

OCLP 3.1.x Nightly → Experimental Tahoe development continues outside this thread (see OCLP-Plus and its thread)

 

This thread focuses on maintaining patcher variants that remain as close as possible to the original Dortania OCLP 3.0.0 Nightly baseline.

 

The included modifications are intentionally minimal and limited primarily to:

- preservation of working Tahoe functionality

- AppleHDA support

- modern Wi-Fi and AWDL support

- AMFIPass compatibility

 

No additional graphics acceleration patches or unsupported-Mac specific root patch frameworks are provided or maintained here.

 

The Broadcom and Intel EFI distributions and setup guidelines linked in this thread remain applicable to all current Tahoe OCLP variants, including OCLP-Mod and OCLP-Plus.

 

---

 

2.) Repositories

 

a.) OCLP 3.0.0 Nightly – amfipassbeta Edition

 

Recommended modern Tahoe setup maintained by kgp

 

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

Configuration:
- AMFIPass.kext 
- boot-arg: -amfipassbeta 

Advantages:
- no need for amfi=0x80 
- no application launch issues 
- clean and stable baseline 
- fully working AppleHDA, Wi-Fi and AWDL 
 

---

b.) OCLP 3.0.0 Nightly – Preserved Reference Edition

 

 

Historical reference environment maintained by kgp

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

This repository restores a reproducible working state of the original OCLP 3.0.0 Nightly Tahoe snapshot.

 

Characteristics:

- preserved original Tahoe snapshot

- original AMFI configuration (amfi=0x80)

- restored AppleHDA functionality

- only original Tahoe root patches enabled

- no additional patch frameworks introduced

 

---

 

3.) AMFI configurations

Recommended:
- OCLP 3.0.0 Nightly - amfipassbeta Edition
→ AMFIPass.kext + -amfipassbeta 

Legacy (historical):
- OCLP 3.0.0 Nightly - Preserved Reference Edition
- OCLP 3.1.x Nightly 
→ amfi=0x80 
→ ipc_control_port_options=0 
Note: Legacy AMFI configurations may cause application compatibility issues.

 

---

 

4.) Important (KDK requirement)

macOS 26.4 beta 1–3 have no usable KDK — avoid these versions.

For all other Tahoe versions (26.0–26.5), a matching or closest available KDK works fine.

A suitable KDK is required for OCLP root patching.
 

---

5.) macOS compatibility

macOS Tahoe 26.0 – 26.3 
→ fully working with recommended setup 

macOS Tahoe 26.4 (beta 1–3) 
→ not compatible (no usable KDK) 

macOS Tahoe 26.4 (beta 4 / RC / release) 
→ working with Kernel Debug Kit 26.4 build 25E246 (macOS 26.4)

macOS Tahoe 26.4.1 (25E253)
→ working with Kernel Debug Kit 26.4.1 build 25E253 (manual installation) or Kernel Debug Kit 26.4 build 25E246 (automatic closest match) 

macOS Tahoe 26.5 beta 1 (25F5042g) 
→ working with Kernel Debug Kit 26.5.1 build 25F5042g (macOS 26.5 beta 1)

macOS Tahoe 26.5 (beta 2) 
→ working with Kernel Debug Kit 26.4 build 25E246 (macOS 26.4) 

 

macOS Tahoe 26.5 beta 3 (25F5058e) 
→ working with Kernel Debug Kit 26.5 Build 25F5058e (macOS 26.5 beta 3)

 

macOS Tahoe 26.5 beta 4 25F5068a 
→ working with Kernel Debug Kit 26.5.4 Build 25F5068a (macOS 26.5 beta 4)

 

macOS Tahoe 26.5 RC (25F71)
→ working with Kernel Debug Kit 26.5 build 25F71 (macOS 26.5 RC)

 

macOS Tahoe 26.5(25F71)
→ working with Kernel Debug Kit 26.5 build 25F71 (macOS 26.5)

 

macOS Tahoe 26.6 beta 1 (25G5028f) 

→ working with Kernel Debug Kit 26.5.4 build 25F5068a (macOS 26.5 beta 4)

 

macOS Tahoe 26.5.1 (25F80)
→ working with Kernel Debug Kit 26.5.1 build 25F80 (macOS 26.5.1)

 

macOS Tahoe 26.6 beta 2 (25G5043d) 

→ working with Kernel Debug Kit 26.5.4 build 25F5068a (macOS 26.5 beta 4)

 

---

6.) Technical background

Earlier macOS 26.4 beta issues were caused by:
- temporary HFS+ mounting bug (fixed in beta 2) 
- missing KDK (available from beta 4) 

With a suitable KDK installed, all patchsets operate normally.

 

---

7.) Important notes

 

- this fork only enables and preserves the original Tahoe patch functionality already implemented by the OCLP developers

- intended exclusively for advanced Hackintosh configurations

- only modern audio (AppleHDA) and modern Wi-Fi + AWDL functionality are expected to work

- no additional graphics acceleration or unsupported-Mac root patch frameworks are included

- always keep a bootable backup before applying root patches

 

---

 

8.) Credits

 

- Dortania OCLP Team (development)

- lzhoang2801 (original Tahoe fork)

- kgp (preservation, maintenance, AMFIPass integration, AppleHDA restoration, testing and documentation)

- laobamac_yyds (amfipassbeta PatcherSupportPkg)

- YBronst / MakAsrock (OCLP 3.1.5–3.1.7 Nightly development)

- badbrain (boot-arg ipc_control_port_options=0 support)

- InsanelyMac community

 

---

 

9.) Prerequisites  and Setup:

 

9.1.) Prerequisites

 

a.) For OCLP 3.0.0 Nightly (amfipassbeta Edition), OCLP-Mod 3.1.9 and OCLP-Plus 3.1.9 enable AMFIPass.kext and use boot argument "-amfipassbeta".

     For OCLP 3.0.0 Nightly (Preserved Reference Edition) enable or disable AMFIPass.kext but always use boot arguments "amfi=0x80" and "ipc_control_port_options=0 "

 

b.) Securebootmodel = disabled

 

c.) csr-active-config = 03080000

 

d.) AppleVTD disabled, i.e. DisableIOMapper=true

 

e.) Same com.apple.iokit.IOSkywalkFamily replacement like under Sequoia

 

 

 

f.) Ensure the following NVRAM entries are present under:

NVRAM → Add → 7C436110-AB2A-4BBB-A880-FE41995C9F82

• bluetoothExternalDongleFailed = 00
• bluetoothInternalControllerInfo = 00000000 00000000 00000000 0000

 

 

All settings above [a.) to f.)] can also be gathered from my EFI-Folder distribution.

 

---

 

9.2.) EFI-Folder Distribution

 

 

The Zip-file contains three EFI-Folders:
a.) EFI-KGP-public-v.1.1.5-BCMC
b.) EFI-KGP-public-v.1.1.5-OCLP-Broadcom
c.) EFI-KGP-public-v.1.1.5-OCLP-Intel

 

For OCLP 3.0.0 Nightly with Broadcom-Wi-Fi, use EFI-KGP-public-v.1.1.5-OCLP-Broadcom. 

For OCLP 3.0.0 Nightly with Intel-Wi-Fi, use EFI-KGP-public-v.1.1.5-OCLP-Intel.

 

---

 

9.3.) Broadcom Wi-Fi Configuration

 

For Broadcom-WiFi to be working with OCLP, EFI-KGP-public-v.1.1.5-OCLP-Broadcom further implements:

- SSDT-DTPG.aml @kgp

- SSDT-X299-Slot1-Slot3-PC02-BR2A-SL05-RadeonVII-HDAU-ARPT.aml @kgp (adopt your ACPI path based on the information provided by Hackintool -> PCI and remove everything GPU/HDAU related).

 

Hackintool -> PCI:

 

 

IOREG:

 

System Information -> PCI:

 

---

 

9.4.) Intel Wi-Fi Configuration

 

For Intel-WiFi to be working with OCLP, EFI-KGP-public-v.1.1.5-OCLP-Intel further implements:

- AirportItlwm.kext v2.3.0 (Ventura) @openintelwireless

- Spoofing of IOName to pci14e4,43a0 under DeviceProperties (adopt your device path based on the information provided by Hackintool -> PCI)

- BlueToolFixup.kext v2.7.2 @acidanthera

- IntelBluetoothFirmware.kext v2.5.0-d2 @lshbluesky

- IntelBTPatcher.kext v2.5.0-d2 @lshbluesky

- SSDT-DTPG.aml @kgp

- SSDT-X299-Slot5-PC01-BR1A-SL01-ANS3-ARPT.aml @kgp (adopt your ACPI path based on the information provided by Hackintool -> PCI and remove everything NVMe related).

 

Important Note:

a.) For macOS 26.5 and later use IntelBTPatcher.kext fixed by Z3cOld.

Download from here: https://github.com/Vinhts/IntelBluetoothFirmware/actions/runs/26730492997

b.) For Intel BE200 use AirportItlwm 2.3.0 (Ventura) from https://github.com/OpenIntelWireless/itlwm/issues/955 or just download Ventura.zip.

 

Hackintool -> PCI:

 

IOREG:

 

System Information -> PCI:

 

AirportItlwm driver stack implemented by AirportItlwm.kext & OCLP:

 

---

 

9.5.) Important Compatibility Notes

 

a.) RTL8125 wired network cards 

 

 

If you have an RTL8125 wired network card, you must go to Kernel -> Block and block com.apple.driver.AppleEthernetRL so that IOSkywalkFamily is loaded (set it to Exclude). Otherwise, the system will crash during boot.
Credits to @laobamac_yyds for this finding.

 

 

b.) Intel I21x/I219 Ethernet controllers with IntelMausi.kext v1.0.8

 

 

IntelMausi.kext v1.0.8 may cause compatibility issues together with the legacy com.apple.iokit.IOSkywalkFamily replacement used for modern Wi-Fi/AWDL support under macOS Tahoe.

 

This primarily affects onboard Intel I21x/I219 Ethernet controllers commonly found on Intel 5xx/6xx-series chipsets and many older Intel desktop platforms.

 

If Wi-Fi fails to work properly, networking behaves inconsistently, or your system fails to boot, replace:

 

- IntelMausi.kext v1.0.8

 

with:

 

- IntelMausiEthernet.kext v3.0.0

 

This solved the issue immediately on multiple tested systems.

 

c.) Intel I225-V, Intel I225-LM, Intel I226-V, Intel I226-LM Ethernet controllers with AppleIGC.kext

 

 

Use: https://github.com/SongXiaoXi/AppleIGC.

 

---

 

9.6.) OpenCore-Patcher Installation

 

a.) Download OpenCore-Patcher.pkg and OpenCore-Patcher-Uninstaller.pkg from Github: 

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

 

 

 

b.) Disable Gatekeeper:

 

xattr -cr ./OpenCore-Patcher-Uninstaller.pkg
xattr -cr ./OpenCore-Patcher.pkg

 

or use drag and drop with Sentinel:

 

 

You can use also use Xattr-remove:

 

 

c.) Install OpenCore-Patcher

 

---

 

9.7.) Root Patching

 

Run "Post-Install Root Patch" -> "Start Root Patching"

 

 

 

and you are done! 

 

---

 

10.) Verified Functional Results

 

a.) Broadcom: Bluetooth, Wi-Fi, Apple Wireless Direct Link (AWDL - Airdrop, Airplay, Screen Mirroring, Continuity Camera, Personal Hotspot) and Continuity (Handoff) successfully tested with BCM943602CDP, but should also work with BCM943602CS, BCM94360CD, BCM94360CS, etc.)

 

b.) Intel: Bluetooth, Wi-Fi, Airplay, Screen Mirroring and Handoff successfully  tested with AX210, AX201 CNVW, 3165, 7260, but should also work with other Intel Wi-Fi chipsets. 

 

Important (macOS Tahoe 26.5 and later):

Recent re-testing with Intel AX210 (Wi-Fi 6 / Bluetooth 5.3) and Intel BE200 (Wi-Fi 7 / Bluetooth 5.4) using the latest IntelBluetoothFirmware package provided by Vinhts indicates that Intel Bluetooth is now functioning correctly again under macOS Tahoe 26.5 and later.

 

Bluetooth controller detection, device pairing and connections (including Magic Keyboard and Magic Mouse) have been successfully verified on both chipsets.

 

However, Apple Wireless Direct Link (AWDL) remains unavailable on both AX210 and BE200. The awdl0 interface is currently not being created, preventing AWDL-dependent services such as AirDrop, Personal Hotspot and Continuity Camera from functioning correctly.

 

Recent testing also revealed significant behavioural differences between AX210 and BE200:

- AX210 currently provides stable Bluetooth and Wi-Fi connectivity. AirPlay, Screen Mirroring and Handoff are working correctly; however, AirDrop, Personal Hotspot and Continuity Camera are currently unavailable.

- BE200 is detected correctly and Bluetooth works reliably, but Wi-Fi functionality remains incomplete and is still under investigation.

 

Detailed troubleshooting results, screenshots and logs can be found in the dedicated AX210 and BE200 test reports.

 

Related ongoing investigations:

• AirportItlwm issue #1062: Intel AWDL (AirDrop, Personal Hotspot and Continuity Camera) under macOS Tahoe
• AirportItlwm issue #955: Intel BE200 support under macOS Tahoe
• IntelBluetoothFirmware issue #505: Intel Bluetooth Low Energy (BLE) fixes for macOS Tahoe 26.5 and later

Additional test results, logs and feedback from Intel Wi-Fi users are highly appreciated.

 

 

 

 

---

 

10.1.) Wi-Fi:

 

 

 

 

Hackintosh Real-world Network Performance (80 Mbps DSL)

 

 

 

LAN (IntelLucy/X550-AT2):

 

 

Wi-Fi (OCLP/BCM943602CDP):

 

The results show virtually identical real-world internet performance over Ethernet and 5 GHz mesh Wi-Fi on the same Hackintosh.

 

AX210 Wi-Fi performance under Tahoe is virtually indistinguishable from my BCM943602CDP:

 

 

---

 

10.2.) Airdrop:

 

 

 

---

 

10.3.) Airplay:

 

 

 

---

 

10.4.) Screen Mirroring:

 

 

 

 

---

 

10.5.) AppleHDA:

 

 

 

 

 

---

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

 

---

11.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.
 

---

 

11.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.

 

---

 

11.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 by entering your Wi-Fi password. 

This typically restores normal Wi-Fi behavior.
 

---

 

11.4.) Wi-Fi or AirDrop not working at all

 

If Wi-Fi or AirDrop does not work at all:

 

- Delete the Wi-Fi service in Network Settings -> right click on Wi-Fi -> Delete Service

 

 

- Re-add it (Add Service → Wi-Fi)

 

 

This often restores full Wi-Fi or AirDrop functionality.

 

---

 

11.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, apply now point 11.4.):

 

- 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.

 

---

 

11.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: 

 

 

Alternative workaround:

 

Developer @Mirone implemented a fix in BlueToolFixup.kext v2.7.3 for Bluetooth wake-related issues. The fix is enabled via the boot argument: -btlfxwakecrash

 

Testing under macOS Tahoe 26.5 and 26.6 indicates that this approach achieves a similar result to the SleepWatcher-based workaround and appears to automatically reinitialize the Bluetooth stack after wake.

 

Successfully tested so far on:

• Broadcom BCM4352 (Mirone)
• Broadcom BCM943602CDP FullMac (kgp)

 

The fix remains under evaluation and additional user feedback is encouraged. According to Mirone, a future pull request to BrcmPatchRAM may be considered once broader testing has been completed.

 

Special thanks to @Mirone for implementing and sharing this solution with the community.

---

 

11.7.) Avoid FileVault

 

None of the currently available OCLP versions — not even OCLP 2.4.1 under macOS Sequoia — work reliably with FileVault enabled on macOS Tahoe.

 

It is therefore strongly recommended to avoid enabling FileVault when installing or updating to macOS Tahoe. 

This can ideally be achieved by using the corresponding Kernel Patch by Max.1974 implemented in the config.plist of my EFI-Folder distribution.

 

---

 

If FileVault is already enabled:

 

It must be manually disabled (decrypted) before proceeding, otherwise boot or login issues may occur.

 

This can be done from macOS Recovery using Terminal.

 

---

 

How to revert FileVault (APFS encryption):

 

Requirements

- Valid user account password or FileVault recovery key

- Access to macOS Recovery (recommended)

 

Step 1 – Boot into Recovery

Boot into macOS Recovery and open Terminal from the Utilities menu.

 

Step 2 – Identify the encrypted APFS volume

Run:

diskutil apfs list

 

Locate your system volume (e.g. disk1s1) and verify:

Encrypted: Yes

 

Step 3 – Get the user UUID

Run:

diskutil apfs listcryptousers /dev/diskXsY

 

Example:

diskutil apfs listcryptousers /dev/disk1s1

 

Note the UUID of the “Local Open Directory User”.

 

Step 4 – Unlock the volume

Run:

diskutil apfs unlockVolume /dev/diskXsY

 

You will be prompted to enter your user account password or the FileVault recovery key.

 

Step 5 – Start decryption 

Run:

diskutil apfs decryptVolume /dev/diskXsY -user ABCD-1234-XXXX-XXXX

 

Note:

Replace diskXsY with your DATA volume (e.g. disk1s4).
Do not use the System volume (e.g. disk1s1).

 

Authentication will be required again.

 

Important:

Decrypting the DATA volume will automatically trigger decryption of the corresponding System volume in parallel, since both volumes are part of the same APFS volume group.

 

Step 6 – Monitor progress

Run:

diskutil apfs list

 

Current state will show:

Decryption in progress: XX%

 

Important:

Do NOT shut down the system while decryption is in progress.

 

---

 

11.8.) Optimized Sleep/Wake settings:

 

On some systems, macOS Tahoe may show unwanted wake-ups or prevent proper sleep due to active background services (e.g. AirDrop, AWDL, network activity) or incorrect USB port configuration.

Typical symptoms:
- System wakes up immediately after sleep 
- Random wake events during idle 
- Sleep is prevented by bluetoothd or sharingd 
- Bluetooth devices may behave inconsistently after wake 
 

---

 

USB configuration (important)

For proper sleep/wake behavior under macOS Tahoe, the internal Bluetooth USB port must be correctly defined in USBMap.kext.

Both properties must be set to:

UsbConnector = 255 (internal) 
usb-port-type = 255 

and NOT:
UsbConnector = 3 (external) 
usb-port-type = 3 

 

 

Incorrect configuration may cause:
- unwanted wake events 
- instant wake after sleep 
- sleep being prevented by bluetoothd 
- inconsistent Bluetooth / AirDrop (AWDL) behavior 

Note:
Under Tahoe, setting only one of the two properties is not sufficient — both must be set to 255 for reliable behavior.
 

---

 

Power management adjustments

You can verify current power management settings with:

 

pmset -g

If you experience unwanted wake behavior, the following adjustments may help:

Disable Power Nap:

sudo pmset -a powernap 0

Disable TCP keepalive (network wake activity):

sudo pmset -a tcpkeepalive 0

Optionally disable Wake on LAN:

sudo pmset -a womp 0

These settings reduce background network activity and prevent unintended wake events.

 

Optimized  Power management adjustment should look like this:

 

System-wide power settings:
Currently in use:
autorestart          0
Sleep On Power Button 1
hibernatefile        /var/vm/sleepimage
powernap             0
gpuswitch            2
networkoversleep     0
disksleep            0
sleep                0 (sleep prevented by bluetoothd, sharingd)
hibernatemode        0
ttyskeepawake        1
displaysleep         10
tcpkeepalive         0
womp                 0

 

---

 

Debugging wake reasons

To analyze wake sources, use:

pmset -g log | grep -e "Wake" -e "DarkWake"

This helps identify the origin of wake events (e.g. network, USB, Bluetooth, RTC).
 

---

 

Note:
- Disabling these options may affect features such as remote wake, iCloud sync timing, or network-based services. 
- Bluetooth wake (e.g. via keyboard or mouse) typically remains functional if USB mapping is correct. 
- These settings have proven to significantly improve sleep stability on X299 systems. 

 

 

---

 

11.9.) Sequential OTA Updates (Important!)

 

After applying root patches, the system volume seal is broken.
As a result, macOS will no longer perform delta (sequential) OTA updates and will instead download the full installer (~18 GB).

 

Typical behavior:

• Root patched system → Full installer download (~18 GB)
• Unpatched (sealed) system → Sequential OTA update (~3–4 GB)

 

Recommended workflow:

1. Revert root patches in OCLP
2. Reboot (system volume becomes sealed again)
3. Perform the OTA update (now ~3–4 GB instead of full installer)
4. Reapply root patches after the update

 

This is expected macOS behavior and not an OCLP bug.

 

---

 

11.10.) Fully automated OCLP root patching during delta and full macOS OTA Updates

 

During macOS OTA updates (delta and full installers), OCLP can automatically detect the pending installation, download the matching KDK and prepare/reinstall root patches fully automatically in the background. Manual post-update root patching is therefore not always required, but still preferable in situations where OCLP may automatically select or download an inadequate or non-optimal KDK.

 

Further details and screenshots regarding this automated OTA workflow can be found here:
 

 

---

 

11.11.) General OCLP Behavior Notes:

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 

----

If despite the extensive guidelines you still need help and support for successfully implementing OCLP on your system, please upload your EFI-Folder, IOREG.save, SystemInformation.save and a txt export of Hackintool’s PCI section to WeTransfer and send me the respective download link via PM.

 

I will then revise everything carefully and come back with possible solutions.

 

 

Good luck 

 

 

---

 

12.) Intel Wi-Fi (Configuration / Results / History)

 

a.) Apparently, the modern WIFI patch works with the Intel 7260 - see this post, this post and this post! Congrats and many thanks to @carlo_67 

b.) Also my Intel AX210S is now flawlessly working with the experimental fork of OCLP 3.0.0 Nightly! Special thanks for help by @carlo_67, @FirstCustomac, @schrup21 and @deeveedee! See this post!

c.) For my Intel AX210S with OCLP 2.4.1 under Sequoia see this post!  

d.) OCLP 3.0.0 Nightly (amfipassbeta variant) is now also working with the Intel 3165! See this post! 

e.) Intel BE200 not supported by AirportItlwm.kext! See this post!   

f.) First successful Intel BE200 Wi-Fi 7 connection under macOS Tahoe using a modified AirportItlwm (Ventura build) with OCLP. Network scanning and Bluetooth functionality are still under investigation. See this post! 

g.) Success with OCLP Nightly and AirportItlwm.kext (Ventura) on Lenovo P17 gen 1 with Intel AX201 CNVW under Tahoe 26.5! See this post! 

 

 

---

 

13.) Thread Updates and Changelog

 

Update: Thanks to @laobamac_yyds , Broadcom Wi-Fi and Intel Wi-Fi root patching as well es AppleHDA root patching now also works with OCLP-Mod 3.1.4 with AMFIPass.kext 1.4.1 and boot-arg "-amfipassbeta" instead of boot-arg "amfi=0x80" with boot-arg "ipc_control_port_options=0"!!!!

 

Update  - 19 February 2026:
Reworked introduction and usage guidance. The thread now distinguishes between the preserved OCLP 3.0.0 reference snapshot and the actively developed YBronst OCLP Nightly 3.1.6+ patcher, including current macOS 26.4 root patch restrictions.

 

Update post #1 - 19 March 2026: implementing description of new OCLP 3.0.0 Nightly patchset working with -amfipassbeta.

 

Update post #1 - 21 March 2026: reflect current project structure and clarify recommended setup. 

 

Update - 17 April 2026: Major update of Post #1 of this thread.

 

Update - 21 April 2026: Adding Section: General Troubleshooting Notes for OCLP on macOS Tahoe (26.x)

 

Update - 24 April 2026: Post #1 has been fully revised and now reflects all settings, recent findings, fixes and optimisations — including AWDL/AirDrop behavior, sleep/wake improvements and FileVault guidance.

 

Update - 6 May 2026: Post 1, repository structure and GitHub README files completely reworked and synchronised. The project scope is now clearly defined as a preserved Hackintosh-focused Tahoe patch environment based on the original OCLP 3.0.0 Nightly baseline.

 

Update - 9 May 2026: document IntelMausi.kext v1.0.8 compatibility issue with IOSkywalkFamily replacement - use IntelMausiEthernet.kext v3.0.0 instead!

 

Update - 26 May 2026: Indexing and Table of Contents

Edited Monday at 05:58 PM by kgp
macOS 26.6 beta 2

[LockDown]

Success here.

Also need IO80211FamilyLegacy.kext.

i dont need to disable AppleVTD. 

[fabiosun]

Thank you for creating a new thread!

 

Is there some AMD users and Broadcom WIFI who had success?

In my rig i have tried all and previously my WIFI was well supported with OCLP without any different kexts of these ones:

IOSkywalkFamily.kext

IO80211FamilyLegacy.kext

IO80211FamilyLegacy.kext/Contents/PlugIns/AirPortBrcmNIC.kext

AMFIPass.kext

 

in OSX like Ventura with zero kexts

BCM 4360 wifi inserted in my X870E hero motherboard replacing default one

tested with amfi=0x80

tested all quirks (DisableIOMapper and the other related to VTD)

i see on wifi exclamation mark and without the possibility of activating it

 

SO my request if some users had success with AMD rigs

 

it works

 

i had to enable a tahoe amd kernel patch about 10Bit i didnt use before

 

edit

as side note for the devs, my system does not need of AppleHDA patch because it has usb working audio by default

OCLP patches it the same

 

Edited December 4, 2025 by fabiosun
Edit for audio part

[kgp]

53 minutes ago, LockDown said:

Success here.

Also need IO80211FamilyLegacy.kext.

i dont need to disable AppleVTD. 

 

Interesting.. With my BCM943602CDP and AppleVTD enabled,  the Modern Audio patch works, but Modern Wifi doesn't, although e.g. BCMC works with AppleVTD enabled on my system. What might be the difference in our settings?

[XanthraX]

No success here. After applying root patch, the system won't boot. Rebooted in verbose mode, the last line is something with "tracing disabled, aborting....", and immediately restarts. I had to reinstall Tahoe. Good not needed to do a clean install.

Edited December 4, 2025 by XanthraX

[deeveedee]

I'll defer to the majority opinion... the link provided for downloading "OCLP 3.0.0" is not Open Core Legacy Patcher from the original developers here.  When the "official" OCLP 3.0.0 nightly builds are available, we're going to have two different products with the same name.

 

Should this alternative "nightly" still be referred to as OCLP-Mod?

 

Also, when we do have an "official" OCLP nightly, we've been asked by the original OCLP Devs not to provide direct links to the nightly download.

 

On this page:  Do not share any links to these binaries in forums; please link to this document only.

[LockDown]

1 hour ago, KGP-iMacPro said:

 

Interesting...

What might be the difference in our settings?

I have to verify my setting in DisableIOMapper tomorrow, but pretty sure VT-D is enabled in bios.

You didn't install  IO80211FamilyLegacy.kext?

[kgp]

1 minute ago, LockDown said:

I have to verify my setting in DisableIOMapper tomorrow, but pretty sure VT-D is enabled in bios.

You didn't install  IO80211FamilyLegacy.kext?

Sure, I did install  IO80211FamilyLegacy.kext and IOSkywalkFamily.kext. See additional information in post 1 to avoid misunderstandings. 

[vrondena]

Hello, please can someone clearly detail how to make the intel wifi card (8265/8275...) work on Tahoe 26.1/2 many say it can work but they explain it in a different way and I haven't succeeded yet. Thank you

[kgp]

23 minutes ago, deeveedee said:

I'll defer to the majority opinion... the link provided for downloading "OCLP 3.0.0" is not Open Core Legacy Patcher from the original developers here.  When the "official" OCLP 3.0.0 nightly builds are available, we're going to have two different products with the same name.

 

Should this alternative "nightly" still be referred to as OCLP-Mod?

 

Also, when we do have an "official" OCLP nightly, we've been asked by the original OCLP Devs not to provide direct links to the nightly download.

 

On this page:  Do not share any links to these binaries in forums; please link to this document only.

 

I created this thread with best intention, as for me OCLP-Mod refers to laobamac_yyds . However I can remove, rename or modify the thread at any time. May I ask the moderators to clarify how to proceed in this issue?

Edited December 4, 2025 by KGP-iMacPro

[deeveedee]

@KGP-iMacPro I am not questioning your intentions - I am sure they are always good.  The directive from the original OCLP Developers is clear about not providing direct links to their nightly binaries and the name "OCLP 3.0.0" is already taken by the "official" product.  

 

In my mind, there's no question that the product being offered in this thread should be named something other than "OCLP 3.0.0" and thus the name of this thread should be changed.  I don't think there is any ambiguity that makes this is a moderator call, but I'll leave that to you.

[kgp]

10 minutes ago, deeveedee said:

@KGP-iMacPro I am not questioning your intentions - I am sure they are always good.  The directive from the original OCLP Developers is clear about not providing direct links to their nightly binaries and the name "OCLP 3.0.0" is already taken by the "official" product.  

 

In my mind, there's no question that the product being offered in this thread should be named something other than "OCLP 3.0.0" and thus the name of this thread should be changed.  I don't think there is any ambiguity that makes this is a moderator call, but I'll leave that to you.

 

I am open to any suggestion for a new title of this thread and would change it asap. However, see the title of the app itself:

 

 

Edited December 4, 2025 by KGP-iMacPro

[luxinhaus]

Name it Midnight 😁

[deeveedee]

Yes - I'm sure that this developer who created their own fork from the official source is using the same name.  Laobamac was courteous enough to change the name.  This particular developer was not.

[LockDown]

3 hours ago, KGP-iMacPro said:

Prerequisites  and Setup:

1.) AMFIPass.kext with boot-arg "amfi=0x80"

btw @KGP-iMacPro

System seems snappier w/o AMFIPass when i did a comparison earlier.

Or probably just me 🤔

Edited December 4, 2025 by LockDown

[bestal]

Hello friends, I can't patch my AMD RX560 graphics card, it doesn't install root.

[kgp]

3 minutes ago, bestal said:

Hello friends, I can't patch my AMD RX560 graphics card, it doesn't install root.

 

I don't think that this forked version contains any GPU patches yet. Up to my knowledge it is Wi-fi and AppleHDA only.  

[deeveedee]

Leaving my post below for historical purposes, but older platforms do require root patches for RX 560.  See @FirstCustomac's post here and  @strangeron 's post here.

-------------------------

@bestal root patches are not required for RX 560 graphics card in Tahoe.

Edited December 4, 2025 by deeveedee

[jsl]

Thanks and it works in my Asus H97M-E Hackintosh for modern wireless and modern audio.

Edited December 4, 2025 by jsl

[bestal]

I see, will there be any support for this over time?

[deeveedee]

Leaving my post below for historical purposes, but older platforms do require root patches for RX 560.  See @FirstCustomac 's post here and  @strangeron 's post here.

 

------------------------------------

 

@bestal Off-topic for this thread... RX 560 is natively supported by macOS Tahoe.  It is supported now.

 

EDIT: One of my hacks here has an RX 560 with macOS Tahoe.

Edited December 4, 2025 by deeveedee

[bestal]

7 minutes ago, deeveedee said:

@bestal Off-topic for this thread... RX 560 is natively supported by macOS Tahoe.  It is supported now.

Thank you, I was asking about the graphics accelerator's OCLP support. My apologies.

[FirstCustomac]

1 hour ago, bestal said:

Thank you, I was asking about the graphics accelerator's OCLP support. My apologies.

You are going to need the patch since your ivy bridge does not support avx2.

[strangeron]

1 hour ago, deeveedee said:

Off-topic for this thread... RX 560 is natively supported by macOS Tahoe.  It is supported now.

Please correct me if it is wrong.

RX400/500 series will not work without OCLP on SandyBridge and IvyBridge processors that do not support AVX2. (Ventura-Sonoma-Sequoia-Tahoe)

 

[deeveedee]

@strangeron and @FirstCustomac I stand corrected - you are correct that there are patches required for older platforms.  Tahoe natively supports RX 560, but that doesn't mean that the PC supports it.  Good catch!  I have added notes to my previous posts.  Sorry about my confusion.

 

@bestal You don't owe me an apology - it is I who owe you an apology.  I should have checked your signature to check your hardware platform.  Please accept my apology for incorrect advice.

 

EDIT: For those who need amfi=0x80, instead try using boot-arg -amfipassbeta with AMFIPass.kext (without amfi=0x80) to see if that resolves the AMFI issues with unofficial OCLP forks.

Edited December 4, 2025 by deeveedee