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

[kgp]

Hi guys, for anybody interested in the current Intel awdl0 / AirDrop debugging status, functionality and remaining limitations with AirportItlwm-Ventura, I posted a technical update here: https://github.com/OpenIntelWireless/itlwm/issues/1062#issuecomment-4925166580

[LockDown]

HI @kgp

which Heliport repo are you using?

[kgp]

1 hour ago, LockDown said:

HI @kgp

which Heliport repo are you using?

 

Hi @LockDown ,

for my earlier itlwm/HeliPort tests, I used HeliPort 1.5.0 from the official OpenIntelWireless repository:

https://github.com/OpenIntelWireless/HeliPort

 

Just to avoid any confusion: my current experimental OCLP/AirportItlwm setup described here does not use HeliPort. HeliPort is only required when using itlwm.kext.

 

I am currently working privately on my own AirportItlwm development branch, using @DexterSLamb’s itlwm/AirportItlwm fork merely as the initial code base:

https://github.com/DexterSLamb/itlwm

My own work specifically focuses on AWDL/AirDrop functionality. These modifications are not part of Dexter’s fork, and none of my own development work has been published yet.

[LockDown]

Keep it coming @kgp 👌

If I recall, there was a fork of itlwm trying to merge all the patches into a single AirportItlwm. can't seem to find it anymore

Edited Tuesday at 04:54 AM by LockDown

[meg2014]

So, I feel obligated to let you all know that I tried installing this on Tahoe 6.6-B5 and it locked up my computer, hard.  It would not boot at all, so I had to restore from backup (from another installation-Ventura, to be exact).

 

I installed - OCLP 3.0.0 Nightly – amfipassbeta Edition and my frustration with this is that I could not recover, or uninstall as my computer would not boot.

 

The computer is an Asus Z790 D5, with 64G of DDR5 Ram, 6800XT video card, and the disk was a WD SN850X

Edited Thursday at 04:50 PM by meg2014

[kgp]

1 hour ago, meg2014 said:

So, I feel obligated to let you all know that I tried installing this on Tahoe 6.6-B5 and it locked up my computer, hard.  It would not boot at all, so I had to restore from backup (from another installation-Ventura, to be exact).

 

I installed - OCLP 3.0.0 Nightly – amfipassbeta Edition and my frustration with this is that I could not recover, or uninstall as my computer would not boot.

 

The computer is an Asus Z790 D5, with 64G of DDR5 Ram, 6800XT video card, and the disk was a WD SN850X

 

@meg2014, I am sorry to hear that you experienced this problem.

 

However, without your complete EFI folder and further diagnostic information, it is impossible for me to determine what caused the system to become unbootable. Simply stating that the OCLP 3.0.0 Nightly – amfipassbeta Edition was used is not sufficient, since the result also depends on the complete EFI configuration, the actual Wi-Fi and audio hardware, the KDK used, and the existing macOS installation.

 

Before drawing any conclusions or assigning responsibility to the patcher, please provide your complete EFI folder, exact details of the Wi-Fi and audio hardware involved, and, if available, a photo showing where verbose boot stopped.

 

My guide provides clear instructions on setup, EFI folder configuration, necessary precautions, and recovery procedures in the event of failed root patching. I honestly do not know what further instructions or safeguards I could provide beyond those already documented to prevent such a failure - or such a drastic conclusion before the actual cause has been established.

 

Without examining the actual configuration, I cannot determine whether the patcher itself was responsible or what may have gone wrong in this particular case.

 

If you have already concluded that this patcher is responsible before allowing the actual configuration and circumstances to be examined, I would honestly recommend using a different patcher in the future.

Edited Thursday at 05:50 PM by kgp

[meg2014]

1 hour ago, kgp said:

 

@meg2014, I am sorry to hear that you experienced this problem.

 

However, without your complete EFI folder and further diagnostic information, it is impossible for me to determine what caused the system to become unbootable. Simply stating that the OCLP 3.0.0 Nightly – amfipassbeta Edition was used is not sufficient, since the result also depends on the complete EFI configuration, the actual Wi-Fi and audio hardware, the KDK used, and the existing macOS installation.

 

Before drawing any conclusions or assigning responsibility to the patcher, please provide your complete EFI folder, exact details of the Wi-Fi and audio hardware involved, and, if available, a photo showing where verbose boot stopped.

 

My guide provides clear instructions on setup, EFI folder configuration, necessary precautions, and recovery procedures in the event of failed root patching. I honestly do not know what further instructions or safeguards I could provide beyond those already documented to prevent such a failure - or such a drastic conclusion before the actual cause has been established.

 

Without examining the actual configuration, I cannot determine whether the patcher itself was responsible or what may have gone wrong in this particular case.

 

If you have already concluded that this patcher is responsible before allowing the actual configuration and circumstances to be examined, I would honestly recommend using a different patcher in the future.

 

Well, just like you, KGP, I'm not fond of posting my "complete" EFI folder, and I didn't ask for help, did I?  I just reported what happened, that's all, and that's all I'm going to do at this time.  This is not an attack on you or the patcher, actually.  It just didn't work.  I will report that on Sequoia, with the Oclp standard package (2.4.1), it all worked fine, but that was Sequoia, a different OS, but on the same hardware.  So, please, go have a beer or three.......(actually, that sounds good...)

 

Later!

[kgp]

AirportItlwm, OCLP, AWDL and AirDrop on Intel AX210

What actually works, what this experimental branch implemented, what remains unresolved,
and why reproducible Intel AirDrop is not a small patch

Experimental-fork technical status report and conclusion
KGP — July 2026

 

IMPORTANT NOTE
This is not a release announcement and it does not claim a complete, reliable or reproducible Intel AWDL or AirDrop implementation.
The work described below produced a detailed source- and runtime-grounded map of the
existing Apple/OCLP/AirportItlwm architecture, implemented and validated several
isolated Intel AWDL building blocks, and identified the principal unresolved areas and
plausible paths toward a clean implementation. The controlled Builds 2.3.131–2.3.195 did not produce a user-ready Kext, remote AirDrop visibility of the Hackintosh, or reproduce a reliable AirDrop file transfer. This does not erase an earlier isolated one-time Hackintosh-to-MacBook Pro transfer observed under a different OCLP-modified AirportItlwm state.
The current experimental branch should therefore be treated as research code, not as a
daily-driver replacement for the official AirportItlwm releases.

 

1. WHY I AM PUBLISHING THIS REPORT
Over the past weeks I have been investigating why AirportItlwm can operate inside an
OCLP-restored modern macOS wireless environment, why macOS already creates an active
awdl0 interface with Intel Wi-Fi, and why AirDrop nevertheless remains nonfunctional as a reliable and reproducible Intel feature.
The project grew far beyond a simple trace or a single missing callback. The final
experimental Build 2.3.195 is 100 commits beyond the exact DexterSLamb baseline from
which this work began. The aggregate retained source delta is approximately 11,636
insertions and 171 deletions across 11 files. A total of 65 numbered builds, from
2.3.131 through 2.3.195, were used to decompose the problem into independently
observable layers.
That effort deserves a clear public result even though it did not end with reproducible
working AirDrop.
This report is intended to answer the questions that are usually obscured by the
simplified statement “AirportItlwm does not support AWDL”:
- Why does an OCLP configuration with Intel Wi-Fi work as far as it does?
- What exactly is supplied by OCLP?
- What is Apple code rather than OCLP code?
- What already existed in stock/OpenIntelWireless/Dexter AirportItlwm?
- What was added in this experimental KGP branch?
- Which parts were genuinely proven at runtime?
- Which parts exist only in source or as diagnostic laboratory code?
- What remains unresolved, incomplete, or not reproducibly demonstrated?
- Why can no credible completion schedule currently be given?
The central conclusion is that the system already contains much more Apple AWDL
infrastructure than one might expect. The controlled source and runtime investigation
did not identify or demonstrate a coherent and production-safe AirportItlwm bridge
between Apple’s existing AWDL upper plane and Intel’s firmware-facing scheduling,
station, queue, packet-ownership, completion, and RX-delivery mechanisms.

The earlier isolated transfers show, however, that parts of an effective outbound path
can arise transiently through a system state that has not yet been identified.
Stabilizing that transient path—or replacing it with an explicit and reproducible
bridge—may still require substantial driver development. The available evidence does
not establish which of those two paths is necessary.

 

2. TEST AND SOURCE CONTEXT
The final controlled runtime described here used:
- Intel AX210 Wi-Fi
- AirportItlwm Ventura target
- macOS 26.5.2, build 25F84
- OpenCore with the OCLP 3.0.0 amfipassbeta compatibility environment
- an active infrastructure Wi-Fi connection
- a separate working Intel Bluetooth stack
- Apple devices used as references: MacBook Pro M1, iPhone 16 Pro and iPad Pro M4
- a Broadcom BCM943602CDP configuration as the known-working OCLP/AWDL reference
Authoritative source identities:
Exact pre-KGP Dexter baseline:
  51543d6cfecf8aae3f66792b0699f5a1bb16a368
Final experimental AirportItlwm commit:
  0b17225dfbe1b7810b114f8fa9148b09f56d4efd
Final branch:
  kgp-awdl-manual-gated-multi-transaction-2.3.195
Final tag:
  active-awdl-manual-gated-multi-transaction-2.3.195
Final Kext UUID:
  814E8EE1-E63F-3C13-B4B9-78F208CC1450
Final executable SHA-256:
  5928a759458f9a33ed4b85a95abc448894e9bc5eef7cd1cc9a8d5cd165251970
OCLP-amfipassbeta source inspected read-only:
Branch:
  main
HEAD:
  b0840696ce6f3fa9dc8892bd3ec5e4c597f24537
Tag:
  3.0.0-amfipassbeta-tahoe
Tag target:
  b0bd23b37c623d310bdca02c6225cdd32a39bb3f

 

3. THE MOST IMPORTANT DISTINCTION: OCLP, APPLE, AIRPORTITLWM AND THE HARDWARE
The word “OCLP” is often used for several different layers at once. That makes the
current Intel behavior sound more mysterious than it actually is.
The architecture must be divided into at least four separate responsibilities.

 

3.1 What OCLP itself contributes
The OCLP patcher is primarily a deployment and compatibility tool.
It detects the operating system and hardware situation, selects patch sets, routes
payloads, restores compatible components, applies root patches, and creates an
environment in which legacy or removed Apple networking components can run on a newer
macOS release.
For the modern wireless environment relevant here, that includes restoration or
enablement of components such as:
- wifip2pd
- IO80211.framework
- WiFiPeerToPeer.framework
- version-appropriate CoreWiFi/CoreWLAN components
- IOSkywalkFamily
- IO80211FamilyLegacy
- related compatibility components selected by the patch set
OCLP does not execute Intel MAC/PHY commands. It does not allocate an AX210 station or
queue. It does not request an Intel Time Event. It does not submit a frame to TXQ4. It
does not receive an Intel RX descriptor and deliver the resulting packet to awdl0.
In other words:
OCLP restores and enables the environment. It is not the runtime AX210 AWDL driver.

 

3.2 What Apple contributes at runtime
Most of the higher-level AWDL and AirDrop machinery is Apple code, not code written by
OCLP and not code written by AirportItlwm.
The restored Apple environment includes or exposes:
- wifip2pd, Apple’s peer-to-peer/AWDL daemon
- IO80211.framework
- WiFiPeerToPeer.framework
- CoreWiFi/CoreWLAN integration
- IOSkywalkFamily networking infrastructure
- IO80211FamilyLegacy
- IO80211AWDLPeerManager
- IO80211 virtual-interface and P2P interface classes
- Finder and AirDrop service logic
- peer lifetime and data-mode machinery
- native flow queues
- packet preparation
- AWDL SNAP/header handling
- multicast policy
- transmit status/completion interfaces
- receive-input interfaces
- higher-level IPv6, mDNS and service behavior once a usable lower data path exists
Exact analysis of the restored IO80211FamilyLegacy binary confirms that Apple already
contains substantial generic AWDL peer and packet machinery. This is not merely a
collection of empty method names. The binary contains peer lifetime, data mode, flow,
packet preparation, multicast, dequeue, RX and completion behavior.
That is one of the most important positive findings of this project:
We do not need to reimplement the complete Apple AWDL peer and service stack from
scratch.
However, Apple’s upper plane still expects the hardware driver below it to perform the
driver-specific work correctly.

 

3.3 What the Broadcom spoof does — and what it does not do
The Broadcom-oriented matching and compatibility environment can help macOS and OCLP
select or expose the expected Apple wireless components and properties. Depending on
the exact EFI and patching arrangement, a Broadcom-style device identity or property
may therefore be useful as an enablement mechanism.
It is not a command translator.
It does not turn the AX210 into a Broadcom chipset, and it does not cause Broadcom
firmware commands to become Intel commands.
AirPortBrcmNIC is inseparably tied to Broadcom-specific assumptions, including:
- Broadcom PCI register behavior
- Broadcom firmware loading and initialization
- Broadcom DMA and ring structures
- Broadcom wl/wlc/d11 structures
- Broadcom IOVARs
- Broadcom event and completion paths
- private Broadcom driver object state
Changing a device ID or provider match would only make Broadcom code inspect Intel
hardware through the wrong hardware ABI. A “thin wrapper” beneath AirPortBrcmNIC would
have to emulate most of a Broadcom chipset and firmware contract. That would be larger,
more fragile, and less defensible than implementing the required Apple-facing behavior
directly in AirportItlwm.
The useful Broadcom contribution is therefore not reusable hardware code. It is a
behavioral reference:
- ordering
- lifecycle
- peer presence and removal
- queue ownership
- completion semantics
- channel scheduling behavior
- RX delivery behavior
Broadcom can be used as an A/B behavioral oracle. Linux iwlwifi can be used as the
primary reference for Intel firmware mechanics. Neither implementation can simply be
copied wholesale into AirportItlwm.

 

3.4 What AirportItlwm contributes
AirportItlwm remains the actual AX210 hardware driver.
The runtime path is conceptually:
  Finder / AirDrop / wifip2pd
          |
          v
  Apple frameworks and IO80211FamilyLegacy
          |
          | Apple controller, VIF, peer and packet contracts
          v
  AirportItlwm
          |
          | Intel MAC / PHY / binding / station / queue /
          | Session Protection / Time Event / TX / RX commands
          v
  Intel AX210 firmware and hardware
For normal Wi-Fi, AirportItlwm already performs the required Intel driver work.
For AWDL, the baseline contained useful scaffolding and generic Intel primitives, but
no coherent end-to-end bridge was identified. This experimental branch added many
management-plane components and diagnostics, but no complete, understood and
reproducible bridge was identified or demonstrated in the inspected source and
controlled runtime. The earlier one-time transfer indicates that some functional
equivalent can nevertheless arise transiently.

 

4. WHAT STOCK/DEXTER AIRPORTITLWM ALREADY PROVIDED
The exact pre-KGP Dexter baseline was not an empty project and it was not missing all
ingredients.
It already provided:
- working ordinary Intel infrastructure Wi-Fi
- scanning, authentication and association
- the normal Intel command transport
- generic TX and RX ownership
- reset and lifecycle infrastructure
- generic Intel Time Event mechanisms
- generic Session Protection mechanisms used by normal association
- virtual-interface scaffolding
- Apple method declarations and partial AWDL callback surfaces
- basic P2P/AWDL placeholders
The important limitation was that these pieces were not assembled into a working AWDL
implementation.
Examples of the baseline boundary included:
- Ventura AWDL VIF creation was incomplete or rejected
- several AWDL callbacks were shallow stubs, logs, or state copies
- requestPacketTx did not execute a native AWDL packet path
- peer registration did not create coherent Intel peer state
- P2P scan/listen/GO operations remained stubbed
- no dedicated and coherent peer-specific AWDL Intel station lifecycle was identified
- no dedicated and coherent AWDL peer-data queue mapping was identified
- no complete and reproducible Apple packet-dequeue/ownership/completion bridge was identified
- no explicit and reproducible RX demultiplexer delivering AWDL packets to awdl0 was identified
- no reliable and reproducible awdl0 L2 data path was demonstrated
The baseline nevertheless mattered greatly because it already contained the reliable
ordinary Wi-Fi driver and the generic Intel building blocks on which all experiments
depended.

 

5. WHAT THE KGP EXPERIMENTAL BRANCH ADDED
This branch should be understood as a research branch containing several different
kinds of work:
- functional lower-plane additions
- source-present but runtime-unproven paths
- bounded active experiments
- diagnostic instrumentation
- safety infrastructure
- superseded experiments retained for evidence or later reuse
It would be misleading to classify all 11,000-plus added lines as working AWDL support.

 

5.1 AWDL virtual-interface lifecycle
The branch enabled and validated the Ventura AWDL virtual-interface path:
- creation of IO80211P2PInterface
- assignment of the AWDL role
- attachment
- enable/disable handling
- link-state publication
- reset/state integration
Runtime proof:
- awdl0 was created
- awdl0 was UP
- awdl0 was RUNNING
- awdl0 reported active
- an IPv6 link-local address was assigned
This is a real improvement over the baseline.
It is not proof of a usable AWDL packet path. An interface can exist, have link state,
and receive an IPv6 link-local address while no bidirectional L2 traffic is possible.

 

5.2 Apple upper-plane callback capture
The branch made the Apple upper-plane interaction observable and coherent.
It captured or tracked:
- OOB requests
- synchronization parameters
- synchronization sequence
- channel sequence
- profile data
- AF_TX_MODE
- management-frame templates
- template generations and refresh
- requestPacketTx demand
- interface and peer-registration-related callbacks
These runtime callbacks prove that the restored Apple upper plane is not merely sitting
unused on disk. Apple is actively trying to configure and use the driver.
They do not prove that AirportItlwm correctly translates every request into Intel
firmware behavior.

 

5.3 Exact Apple AWDL RX classification and timing
The branch added bounded early and late RX classification for:
- management frames
- action frames
- vendor-specific action category 0x7f
- Apple OUI 00:17:f2
- AWDL OUI type 0x08
- frame length and bounded copies
- TLV parsing
- TLV 0x04 channel-sequence/timing information
- peer source address
- local-MAC rejection
- channel and frequency
- MAC/PHY context
- generation and reset generation
- TSF and GP2/host timing
This path produced genuine runtime results in earlier controlled builds and in Build
2.3.193.
The project therefore did not merely infer AWDL traffic from a Finder window. It
captured and parsed exact Apple AWDL action frames when the radio and driver actually
received them.

 

5.4 Intel P2P lower context
The branch implemented a staged Intel lower context for the AWDL/P2P device role:
- PHY1
- P2P Device MAC1
- binding of MAC1 to PHY1
- channel 6 configuration
- generation tracking
- coherent partial-prefix handling
- broadcast Station 3
- management TXQ4
- reset and teardown state
- a failed-closed latch for incoherent partial setup
Build 2.3.195 proved that the complete configured and bound context could be created
successfully and without a generation change:
  phy_modified = 1
  mac_added = 1
  binding_added = 1
  sta_added = 1
  queue_enabled = 1
  Station ID = 3
  TXQ = 4
  ready = 1
This is a meaningful lower-plane result.
It proves configuration and binding. It does not prove that the shared radio was
actually scheduled onto channel 6 during the later receive window.

 

5.5 Session Protection and channel scheduling experiments
The branch used Intel Session Protection as a bounded P2P/AWDL scheduling mechanism.
Earlier Build 2.3.166 produced:
- a successful Session Protection command
- a successful start notification
- an explicit channel-6 receive opportunity
Build 2.3.167 then recorded several valid channel-6 Apple AWDL timing entries from
multiple peers.
A separate Build 2.3.193 runtime also recorded one Session Protection command and one
successful start.
These results prove that the Intel firmware contains a usable scheduling mechanism.
They do not yet provide a stable production scheduler that continuously translates
Apple’s AWDL timing requirements while safely coexisting with infrastructure Wi-Fi.

 

5.6 Management-frame template, Station 3/TXQ4 submission and completion
Apple supplied a synchronization/management template through its upper callbacks. The
branch captured, validated, refreshed, and used the template to prepare an Apple
vendor-action management frame with:
- broadcast destination ff:ff:ff:ff:ff:ff
- management action subtype
- category 0x7f
- Apple OUI 00:17:f2
- AWDL type 0x08
- Intel broadcast Station 3
- Intel management TXQ4
Earlier Builds 2.3.168 and 2.3.169 proved isolated, bounded management submissions and
matching TX completions through TXQ4.
That is genuine TX evidence.
It is not proof of a complete AWDL advertisement. Those submissions were isolated
experiments, not the final sequence of:
  scheduler window
  -> accepted Time Event response
  -> nonzero UID
  -> matching Event Start
  -> correctly timed management submission
  -> completion
  -> repetition
  -> remote Apple-device visibility

 

5.7 GP2 timing, peer anchor and next-AW reservation
Build 2.3.188 added coherent peer phase/TLV capture. Subsequent builds connected that
information to timing correlation and a bounded next-AW reservation.
The most important positive runtime milestone was Build 2.3.193.
It recorded:
- a genuine Apple AWDL frame on channel 6
- presence mode 4
- AW period 16 TU
- 63 TU to the next availability window
- coherent Apple callback/profile state
- coherent driver and reset generations
- all required technical predicates true
- approximately 2 microseconds from RX classification to reservation
- approximately 63.805 milliseconds of forward command lead
- reservation return 0
- task_add return 1
- entry into the real worker/command stage
This proved that the branch could take a real peer timing frame and transform it into
a coherent Intel-side reservation decision.
The attempt still did not produce:
- a valid firmware UID
- an accepted Event Start
- management TX through the final pipeline
- remote visibility

 

5.8 Correct Intel Time Event response parsing
Build 2.3.194 corrected a fundamental host-side interpretation error.
The previous path treated numeric status zero as success. Analysis of the Intel
firmware contract showed that success requires:
- documented success bit 0 set
- no documented error bits
- exact response payload length
- a nonzero UID
Build 2.3.194 corrected the relevant helpers and added immutable transaction evidence.
This correction is source- and model-proven.
It remains runtime-unproven because Build 2.3.195 stopped before entering the Time
Event helper and therefore never exercised the corrected response parser.

 

5.9 Build 2.3.195 manual safety and diagnostic framework
After earlier automatic active experiments caused uncertainty around resets, timing,
and system stability, Build 2.3.195 deliberately converted the current path into a
strictly controlled laboratory experiment.
It added:
- a 300-second continuous quiet/stability period
- READY-FOR-MANUAL-TRIGGER state
- a private privileged userspace command
- an exact version and monotonic nonce
- one-shot semantics
- LOWER-SETUP-IN-PROGRESS
- a bounded five-second lower-setup stage
- a fresh three-second post-setup peer window
- automatic-attempt suppression
- no automatic retry
- no automatic reservation
- no automatic Time Event
- no automatic TX
- eight immutable transaction slots
- bounded explicit STATUS publication
- reset-preserved evidence
- a helper utility for status and trigger control
These mechanisms worked as designed in the final test.
They are not a production AWDL architecture. They are laboratory safety and evidence
machinery.

 

6. WHAT THE FINAL BUILD 2.3.195 TEST ACTUALLY PROVED
The final controlled test is easy to misdescribe, so the exact boundary matters.
Build 2.3.195 successfully proved:
- the intended Kext and UUID were loaded
- ordinary infrastructure Wi-Fi remained operational
- Bluetooth remained operational
- IOSkywalkFamily and IO80211FamilyLegacy were loaded
- wifip2pd/IO80211 user-client activity occurred
- awdl0 was UP, RUNNING and active
- the 300-second quiet period completed
- the state reached READY-FOR-MANUAL-TRIGGER
- exactly one privileged trigger was accepted
- lower setup ran
- PHY1, MAC1, Binding1, Station 3 and TXQ4 were successfully created
- the complete lower-context predicate returned ready
- no transaction slot was consumed during setup
- the state entered ARMED-WAITING-FOR-POST-TRIGGER-PEER
- the attempt failed closed and safely when its peer window expired
- all automatic background attempts remained suppressed
The final test did not prove or test:
- an active channel-6 scheduling grant during the three-second peer window
- the corrected Time Event response parser
- a valid firmware UID
- Event Start
- management TX
- TX completion
- remote visibility
- the Apple peer data plane
- AirDrop transfer
The final failure was:
  POST-TRIGGER-PEER-TIMEOUT
It was not:
- a Station 3 failure
- a TXQ4 failure
- a Time Event failure
- a firmware-response-parser failure
- a TX failure
- a completion failure
Those later stages were never entered.

 

7. WHY THE MACBOOK CAN BE VISIBLE ON THE HACK WHILE INTEL AWDL IS STILL INCOMPLETE
The Hackintosh could see Apple devices in its AirDrop window before this project began.
That observation was never presented as a new Build 2.3.195 success.
The final runtime contained thousands of management frames, but only two action frames.
Both were category 0x03 on the infrastructure context and channel 36.
During the relevant final window:
- exact Apple category 0x7f count remained zero
- Apple OUI count remained zero
- AWDL OUI type 0x08 count remained zero
- early exact AWDL count remained zero
- late exact AWDL count remained zero
- genuine peer commit count remained zero
- timing-anchor count remained zero
The AirDrop UI can be influenced by information outside this exact current Intel AWDL
RX path, including retained/cached service state, BLE-assisted discovery, or another
Apple discovery source. The preserved evidence does not identify which source produced
the local MacBook entry.
Therefore the correct conclusion is:
The local AirDrop UI proves that macOS had enough discovery state to display the
MacBook. It does not prove that the AX210 received a fresh exact AWDL synchronization
frame during the controlled window, and it does not prove a usable AWDL data path.

 

7.1 IMPORTANT HISTORICAL EXCEPTION: ISOLATED ONE-TIME AIRDROP TRANSFERS
Before the controlled Builds 2.3.131–2.3.195 were developed, I completed one real AirDrop transfer from the Hackintosh to a MacBook Pro under an earlier OCLP-modified AirportItlwm configuration. The Hackintosh was not visible as an AirDrop destination on the MacBook Pro, but the MacBook Pro was visible on the Hackintosh and the Hackintosh-to-MacBook Pro transfer completed once. A comparable isolated one-time AirDrop result was also reported by another user in OpenIntelWireless/itlwm Issue #1062 under the OCLP amfipassbeta environment.

This also demonstrates that normal reverse visibility of the Hackintosh is not necessarily a prerequisite for an outbound transfer when the Hackintosh already knows and can select the receiving Apple device.

These observations are technically important. They demonstrate that, under a particular transient system state, enough of Apple’s restored AirDrop upper plane and the existing Intel driver path can apparently become operational to complete at least one outbound transfer. However:
- the result was not reproducible;
- the exact system state and transport path were not identified;
- the Hackintosh still lacked normal reverse discovery and visibility;
- no reliable bidirectional AWDL operation was established;
- and the later controlled experimental builds did not reproduce the transfer.
The correct conclusion is therefore not that every Intel AirDrop transfer is fundamentally impossible. The correct conclusion is that current AirportItlwm does not provide a complete, understood, reliable or reproducible AWDL/AirDrop implementation. The isolated one-time transfers remain evidence of a transient partial path, not evidence of a production-capable data plane.

 

8. CURRENT FUNCTIONAL STATUS
The following summary separates ordinary networking from genuine AWDL support.

 

8.1 Working and preserved
Infrastructure Wi-Fi:
- WORKING
- Supplied by stock AirportItlwm plus Apple’s normal Wi-Fi/network stack.
Scanning, authentication, association and DHCP:
- WORKING
- These are normal infrastructure functions and were preserved throughout the final
  experiment.
Bluetooth:
- WORKING in the controlled setup
- Supplied by IntelBluetoothFirmware and Apple’s Bluetooth stack, not by the
  AirportItlwm AWDL implementation.
Sleep/wake:
- WORKING for ordinary tested use
- Full AWDL peer/station/queue recovery and long-duration stress remain unproven.
AirPlay and Screen Mirroring:
- WORKING in the tested Intel configuration
- These services can operate over infrastructure networking and therefore do not prove
  a usable Intel AWDL data plane.

 

8.2 Working as an upper plane or isolated building block
Restored Apple AWDL upper plane:
- WORKING as an active upper plane
- Apple callbacks, profiles, templates and demand are present.
awdl0 interface lifecycle:
- WORKING
- Interface creation, role, attachment, enablement and link state are proven.
Exact Apple AWDL frame classification:
- PARTIALLY WORKING
- Proven when matching frames actually reached the Intel RX path, but reliable receive
  scheduling does not exist.
TLV 0x04 parsing and peer timing extraction:
- WORKING for received matching frames.
P2P PHY1/MAC1/binding:
- WORKING as configured and bound firmware contexts.
Station 3 and TXQ4:
- WORKING as lower resources.
- Isolated bounded management submission/completion was proven in earlier builds.
Session Protection:
- PARTIALLY WORKING
- A bounded start was proven; stable integration is missing.
Next-AW reservation:
- PARTIALLY WORKING
- One coherent Build 2.3.193 reservation was proven.
Corrected Time Event response parser:
- SOURCE-IMPLEMENTED, RUNTIME-UNPROVEN.
Event Start matching:
- SOURCE-IMPLEMENTED, RUNTIME-UNPROVEN.
One bounded management TX and completion:
- PARTIALLY WORKING as an isolated experiment.
- Not proven through the final end-to-end scheduling pipeline.

 

8.3 Present but not functional as a complete feature
Reliable AWDL channel scheduling:
- Intel primitives and isolated experiments exist.
- No stable and reproducible production policy mapping Apple’s schedule to recurring,
  safe Intel channel occupancy was demonstrated.
Repeated management advertisements:
- Earlier experimental source existed and was later constrained and suppressed for
  safety.
- No reliable and reproducible advertisement loop was demonstrated.
Remote visibility of the Hackintosh:
- NOT ACHIEVED in the controlled experiments.
awdl0 L2 packet path:
- No reliable and reproducible bidirectional path was demonstrated.
- The one-time transfer means that a transient partial path cannot be excluded.
AWDL IPv6:
- A link-local address exists.
- No reliable and reproducible bidirectional AWDL packet transport was demonstrated.
mDNS over AWDL:
- No reliable or reproducible AWDL mDNS transport was demonstrated by the controlled
  experimental branch.
- The earlier one-time transfer prevents a categorical claim that no transient service
  path can ever exist.

 

8.4 Not demonstrated as coherent and reproducible implementations
Apple peer lifecycle adapter:
- No complete and reproducible Intel integration was identified or demonstrated.
Peer-specific Intel firmware station:
- No dedicated AWDL peer-station lifecycle was identified in the controlled path.
- It remains unknown whether the one-time transfer reused another existing station or
  generic path.
Peer-specific Intel data queue and TID mapping:
- No coherent AWDL-specific implementation was identified or demonstrated.
Native Apple packet dequeue and ownership:
- No reproducible end-to-end path was demonstrated.
- Bounded diagnostic probes did not obtain a native packet, but the earlier one-time
  transfer shows that another transient path cannot be excluded.
Native TX completion reporting back to Apple:
- No coherent and reproducible AWDL data-packet completion bridge was demonstrated.
RX peer/context demultiplexing:
- No explicit and reproducible implementation was identified in the inspected path.
packet_info_tag construction:
- No ABI-validated and reproducible implementation was identified; the exact private
  contract remains unresolved.
IO80211P2PInterface input delivery:
- No explicit and reproducible Intel AWDL input bridge was identified or demonstrated.
- It cannot currently be established whether every one of these functions must be
  newly implemented from scratch or whether Apple and existing generic driver paths
  transiently supplied functional equivalents during the one-time transfer.
AirDrop discovery of the Hackintosh:
- No complete and reproducible remote-discovery path was demonstrated.
One-way or bidirectional AirDrop file transfer:
- No controlled, understood and reproducible AirportItlwm path was demonstrated.
- One isolated Hackintosh-to-MacBook Pro transfer and a comparable community report
  demonstrate that a transient send-only path can occur, but its exact mechanism has
  not been identified or reproduced.
Personal Hotspot through Intel AWDL:
- No controlled, reliable or reproducible implementation was demonstrated.
Continuity Camera through Intel AWDL:
- No controlled, reliable or reproducible implementation was demonstrated.
Sidecar:
- No reliable service-specific conclusion can be drawn from the preserved evidence.

 

9. DEVELOPMENT HISTORY IN PHASES
A complete Build 2.3.131–2.3.195 ledger was compiled and retained in the private technical archive.
The following is the shorter architectural history.

Phase 1 — Initial bridge and bounded active concepts, Builds 2.3.131–2.3.139
The first builds explored whether existing Apple callbacks could be connected to Intel
Time Event and one-shot active behavior. These attempts established the scale of the
problem but did not leave a reliable working active path.

Phase 2 — Decomposing the Intel lower context, Builds 2.3.140–2.3.157
The lower plane was separated into individually testable components:
- capability and context previews
- MAC1
- PHY1
- binding
- Station 3
- TXQ4
- deferred task context
- generation/reset handling
- persistent complete lower-context hold
This phase converted a monolithic failure into a known sequence of Intel firmware
operations.

Phase 3 — Templates, RX, channel opportunity and first TX, Builds 2.3.158–2.3.168
This phase added:
- native Apple synchronization-template capture
- complete TLV capture
- bounded packet-dequeue probes
- raw management/action RX classification
- P2P Session Protection
- channel-6 peer timing records
- one bounded TXQ4 management submission and matching completion
Builds 2.3.166–2.3.168 established that the AX210 could be given a P2P scheduling
window, could receive exact Apple AWDL traffic in that development phase, and could
submit/complete a bounded management frame through Station 3/TXQ4.

Phase 4 — Apple native packet and peer-manager investigation, Builds 2.3.169–2.3.184
This side-line explored:
- manual late TX
- multicast and unicast native dequeue
- requestPacketTx selectors
- peer registration and presence
- PeerManager binary behavior
- Event 58 state transitions
- output handoff
- repeated bounded dequeue
- early/late RX classification
The key negative result was consistent:
Apple’s upper plane and pending state were visible, but no coherent native packet was
obtained for Intel data TX.
This phase also demonstrated that guessed private offsets and vtable calls are not an
acceptable production strategy.

Phase 5 — Timing, reservation, Time Event contract and manual safety, Builds
2.3.185–2.3.195
The final ancestry added:
- template coherence and refresh
- GP2 timing
- exact peer/TLV phase
- next-boundary Time Event logic
- bounded demand/anchor rendezvous
- compact publication
- immutable reservation records
- corrected Intel response status
- manual gating
- safe lower setup
- immutable transaction slots
- explicit status publication
Build 2.3.193 reached the reservation/command boundary.
Build 2.3.194 corrected the response contract.
Build 2.3.195 proved safe manual lower setup but did not receive the required fresh
post-setup peer.

 

10. MANAGEMENT PLANE VERSUS FULL DATA PLANE
It is essential not to mix the first management advertisement with the much larger
AirDrop data path.

10.1 First management advertisement
A clean and explicit path to the first remote-visibility milestone would be expected
to follow a sequence resembling:
1. Apple upper plane is active.
2. A valid Apple management template and profile exist.
3. Intel PHY1/MAC1/binding exist.
4. Station 3 and TXQ4 exist.
5. The Intel scheduler grants the correct channel/time window.
6. Timing is derived from a valid source.
7. The Time Event command is accepted.
8. A nonzero UID is returned.
9. Event Start is matched.
10. The management frame is submitted.
11. TX completion is matched.
12. Advertisements repeat at an acceptable cadence.
13. Apple peers accept the frame and display the Hackintosh.
The current frame is broadcast. It does not require a peer-specific unicast data
station merely to address a specific peer.
The current Build 2.3.195 policy nevertheless waits for a fresh inbound peer because
that peer supplies a conservative timing anchor, channel/presence state, AW phase and
GP2 correlation.
The source does not prove that a fresh inbound peer is fundamentally required before
one broadcast advertisement. It is required by the current experimental policy.

10.2 Full AirDrop data plane
Even successful remote visibility would not mean that AirDrop was nearly complete.

A clean and explicit production implementation would normally be expected to provide
the following capabilities, or functional equivalents of them. The isolated one-time
transfers mean that it cannot currently be proven that every item must be newly
implemented from scratch before any outbound transfer can occur:
- safe Apple peer-manager lifecycle
- peer presence, absence and IPv6 presence
- peer traffic registration
- Apple data-mode transition
- peer-specific Intel station
- peer-specific data queue
- TID/access-category mapping
- native Apple flow dequeue
- exact mbuf ownership
- backpressure
- transmit success/failure reported exactly once
- Intel RX context and peer mapping
- packet_info_tag
- decapsulation responsibility
- IO80211P2PInterface input
- awdl0 bidirectional L2
- AWDL IPv6
- mDNS
- service negotiation
- sustained transfer
- reset and removal
- sleep/wake
- long-duration stability
Apple already supplies significant peer, flow and packet behavior above this boundary.
No coherent and reproducible AirportItlwm adapter for these facilities was identified
or demonstrated. Whether the earlier transient path already supplied some of the
required behavior through existing generic mechanisms remains unknown.

 

11. WHAT CAN BE REUSED AND WHAT REMAINS UNRESOLVED
Reusable unchanged from the OCLP/Apple environment:
- wifip2pd
- Apple IO80211 and WiFiPeerToPeer frameworks
- relevant CoreWiFi/CoreWLAN components
- IOSkywalkFamily
- IO80211FamilyLegacy
- the Apple AWDL virtual-interface model
- much of IO80211AWDLPeerManager
- native Apple peer and flow machinery
- packet preparation and multicast policy
- Finder/AirDrop service logic
- Apple IPv6/mDNS/service layers once the lower transport works
Reusable through declared or independently validated Apple interfaces:
- virtual-interface lifecycle
- createPeerManager
- peer presence/absence operations
- native dequeue/drop/prequeue
- input/output packet methods
- data-path events
- transmit completion interfaces
Portable only as observed clean-room behavior:
- callback order
- peer lifetime
- data-mode transitions
- queue ownership
- completion semantics
- multicast policy
- RX handoff semantics
- reset/removal ordering
Not portable from Broadcom:
- AirPortBrcmNIC hardware implementation
- Broadcom PCI/register code
- Broadcom firmware
- Broadcom DMA/rings
- Broadcom IOVARs
- Broadcom wl/wlc/d11 structures
- AirportBrcmFixup as an Intel command translator
Areas likely to require further AirportItlwm development, integration or stabilization:
- stable Apple-to-Intel channel scheduling
- production-safe multi-context occupancy
- management Time Event/UID/Event Start integration
- repeated advertisement lifecycle
- Apple peer lifecycle adapter
- peer-specific Intel station/queue/TID
- native packet ownership and completion mapping
- RX demultiplexing and awdl0 delivery
- AWDL reset/sleep/wake/stability handling

These are the most plausible components of an explicit production architecture. The
isolated one-time transfers prevent a categorical conclusion that every item is wholly
absent or must necessarily be written from scratch.

No OCLP source modification is currently required for the Intel lower work.
A future OCLP change could become useful only for deployment or capability selection
if a later macOS release requires Intel-specific restoration enablement. Such a change
would not replace the missing AirportItlwm implementation.

 

12. DEVELOPMENT SCOPE AND UNCERTAINTY 

It is not possible to provide a reliable development schedule for the remaining work. 

This investigation identified the principal unresolved architectural layers, but several of the decisive interfaces remain undocumented or only partially understood. These include Intel multi-context scheduling behaviour, Apple peer and packet lifecycle contracts, native dequeue activation, packet_info_tag requirements, and RX/TX ownership across the Apple-to-Intel boundary. 

The earlier isolated one-time Hackintosh-to-MacBook Pro AirDrop transfer also shows that a transient partial path can apparently exist without the complete controlled architecture described here. Its exact system state and transport mechanism were never identified or reproduced. 

Consequently, the remaining development could follow very different paths: 

- identifying and stabilizing an already existing transient path; 
- completing only the management and discovery plane; 
- or implementing the full peer-specific TX/RX data bridge inside AirportItlwm. 

Even the smallest controlled next experiment would address only one prerequisite and
would not produce reliable AirDrop by itself. Reliable remote discovery would require
several additional scheduling and management stages. A clean and stable bidirectional
implementation would normally be expected to provide the peer lifecycle, station and
queue management, packet ownership, completion reporting, RX delivery, IPv6, mDNS,
reset and sleep/wake capabilities listed above—or functional equivalents of them. 

The work must therefore be regarded as an open-ended driver-development and reverse-engineering project, not as a one-day fix or a feature for which a credible completion date can currently be given.

 

13. WHAT WOULD BE THE MOST INFORMATIVE NEXT EXPERIMENT?
In light of the isolated one-time AirDrop transfers, the most informative next
experiment would no longer necessarily be another isolated lower-plane build.

The first priority would be to reproduce the earlier OCLP-modified system state as
closely as possible and capture the complete successful or attempted
Hackintosh-to-MacBook Pro sequence with synchronized evidence, including:
- loaded Apple and third-party components
- AirportItlwm and OCLP versions and configuration
- awdl0 state
- IORegistry state
- wifip2pd and unified-log activity
- Bluetooth and infrastructure-network state
- AirportItlwm callbacks
- packet and interface traces
- the selected recipient and transfer lifecycle

This would determine whether the earlier transfer used:
- a transient but genuine Intel AWDL path
- existing generic AirportItlwm TX/RX resources
- an Apple-managed alternative path
- or another transport transition that was not represented by the later controlled
  architecture

A manually authorized receive-only channel-6 dwell would remain a useful secondary
experiment if the transient state could not be reproduced. It would test the scheduler
and RX opportunity, but it would not explain how the earlier complete transfer
occurred.

Neither experiment would by itself establish reliable AirDrop. Their purpose would be
to distinguish between stabilizing an already existing partial path and implementing a
more complete Apple-to-Intel bridge.

 

14. PROJECT DECISION
The investigation has now reached the point where the remaining scale is sufficiently
clear.
From a practical daily-driver perspective, continuing is difficult to justify:
- the Broadcom reference already provides working AWDL and AirDrop
- the first Intel remote-visibility milestone is still not guaranteed
- no complete, understood and reproducible peer/data bridge was identified or demonstrated
- private Apple ABI risk grows sharply in the later milestones
- stable daily-driver support and macOS maintenance could require a long-term
  development commitment unless the transient path can first be understood and
  stabilized
From a research perspective, the project was still valuable and achieved more than a
simple failed patch attempt.
It established:
- which Apple components are already reusable
- why OCLP helps without implementing Intel AWDL
- why Broadcom hardware code is not portable
- which Intel mechanisms already exist
- which AirportItlwm baseline stubs were incomplete
- which lower resources can be created
- how exact Apple AWDL frames can be classified and timed
- how a next-AW reservation can be constructed
- where the current management pipeline stops
- what a clean and explicit full data plane would likely require
- the remaining development scope, uncertainty and risk
I am therefore ending the current active development phase at Build 2.3.195 and
freezing it as a research and evidence milestone.
This does not prove that Intel AWDL is impossible.
It means that achieving a controlled and reproducible implementation may require a
substantial long-term driver project unless the earlier transient path can first be
identified and stabilized. It is not correctly described as one remaining callback or
a small compatibility patch.

 

15. EVIDENCE BASE AND REPRODUCIBILITY
This report is based on archived Git history, exact source identities, source
diffs, controlled runtime captures, implementation and review reports, Intel
firmware-contract analysis, exact Apple binary evidence, and a read-only
analysis of the relevant OCLP-amfipassbeta source.
The underlying evidence has been preserved and integrity-checked, including the
exact commits, tags, Kext UUIDs, executable hashes, Build 2.3.193 and Build
2.3.195 runtime captures, and the implementation reports for the final
experimental stages.
These materials are retained as the technical archive of the investigation.
Relevant source, runtime, or implementation records can be provided where they
are useful for a concrete technical review or for a developer intending to
continue the work.

 

16. COLLABORATION AND ATTRIBUTION
This project was initiated, directed and performed by KGP.
KGP performed:
- all hardware changes
- all EFI operations
- all Kext replacements
- all reboots
- all manual AirDrop/UI observations
- all controlled runtime procedures
- final judgment over scope and safety
- validation of the observed system behavior
ChatGPT assisted with:
- architecture analysis
- experiment and safety design
- independent interpretation of source and runtime evidence
- formulation of discriminating tests
- review of conclusions
- public-report planning and drafting
OpenAI Codex performed, under KGP’s explicit instructions:
- repository and Git-history inspection
- source analysis
- implementation work
- builds
- bounded model tests
- code review
- read-only OCLP and Apple-binary analysis
- reconstruction of the final evidence dossier
ChatGPT and Codex were technical assistants, not autonomous project owners.
The final claims were checked against source, exact Git identities, existing reports,
immutable diagnostics or controlled runtime evidence. Conclusions that remain
unproven are explicitly identified as inference or unknown.
The collaboration produced substantial Intel AWDL research infrastructure and several
isolated lower-plane milestones.
The controlled KGP experimental branch did not produce reproducible working Intel AirDrop. This does not erase earlier isolated one-time send-only successes observed under other OCLP-modified configurations.

 

17. FINAL CONCLUSION
The most accurate summary is:
OCLP restores the Apple environment.
Apple supplies most of the AWDL upper plane.
Stock AirportItlwm supplies ordinary Intel Wi-Fi and generic Intel primitives.
The KGP experimental branch added and proved significant AWDL management-plane
groundwork.
No coherent, understood and reproducible Apple-to-Intel peer and data bridge has yet
been identified or demonstrated. The isolated one-time transfers prove that enough of
a partial path can nevertheless arise under an unknown transient state.
The unresolved work required for a clean and reproducible implementation is unlikely
to be one patch. It may span:
- scheduler ownership
- management advertisement
- peer lifecycle
- peer-specific firmware resources
- native packet dequeue and ownership
- completion reporting
- RX demultiplexing
- awdl0 packet delivery
- IPv6 and mDNS
- AirDrop service traffic
- reset and sleep/wake
- long-term macOS maintenance

The project therefore ends its current experimental phase with a negative product
result but a positive engineering result:

No complete, reliable or reproducible Intel AirDrop implementation was achieved. Earlier isolated one-time send-only transfers demonstrate that a transient partial path can occasionally exist, but its mechanism remains unidentified and was not reproduced by the controlled experimental branch. The architecture, proven milestones, failure boundaries and remaining implementation scope and uncertainty are now documented in enough detail that future work no longer has to begin from the vague statement that “AWDL is missing.”

Edited 2 hours ago by kgp