All Activity

AirportItlwm, OCLP, AWDL and AirDrop on Intel AX210 What actually works, what this experimental branch implemented, what is still missing, and why complete Intel AirDrop support 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 working Intel AWDL or AirDrop. 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 remaining technical work. It did not produce a user-ready Kext, remote AirDrop visibility of the Hackintosh, or an AirDrop file transfer. 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. 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 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 completely missing? - How much development effort would the remaining milestones realistically require? The central conclusion is that the system already contains much more Apple AWDL infrastructure than one might expect. The missing part is not “all of AirDrop.” The missing part is a coherent and production-safe AirportItlwm bridge between Apple’s existing AWDL upper plane and Intel’s firmware-facing scheduling, station, queue, TX ownership, completion, and RX delivery mechanisms. That bridge is still a substantial long-term driver-development project. 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 not a coherent end-to-end bridge. This experimental branch added many missing management-plane components and diagnostics, but the complete bridge still does not exist. 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 peer-specific AWDL Intel station existed - no peer-specific AWDL data queue existed - no Apple packet dequeue/ownership/completion bridge existed - no RX demultiplexer delivered AWDL packets to awdl0 - awdl0 had no usable L2 data path 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. 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 exist. - Isolated experiments exist. - No stable production owner maps Apple’s schedule to recurring safe Intel channel occupancy. Repeated management advertisements: - Earlier experimental source existed. - It was later constrained and suppressed for safety. - No production advertisement loop exists. Remote visibility of the Hackintosh: - NOT ACHIEVED. awdl0 L2 packet path: - PRESENT BUT NOT FUNCTIONAL. AWDL IPv6: - A link-local address exists. - No proven bidirectional AWDL packet transport exists. mDNS over AWDL: - NOT FUNCTIONAL because the underlying L2/IPv6 path is absent. 8.4 Not implemented Apple peer lifecycle adapter: - NOT IMPLEMENTED as a coherent Intel path. Peer-specific Intel firmware station: - NOT IMPLEMENTED. Peer-specific Intel data queue and TID mapping: - NOT IMPLEMENTED. Native Apple packet dequeue and ownership: - NOT IMPLEMENTED. - Only bounded diagnostic probes were performed. Native TX completion reporting back to Apple: - NOT IMPLEMENTED for AWDL data packets. RX peer/context demultiplexing: - NOT IMPLEMENTED. packet_info_tag construction: - NOT IMPLEMENTED; exact private ABI remains unresolved. IO80211P2PInterface input delivery: - NOT IMPLEMENTED as an Intel AWDL bridge. AirDrop discovery of the Hackintosh: - NOT IMPLEMENTED as a complete working path. One-way or bidirectional AirDrop file transfer: - NOT IMPLEMENTED. Personal Hotspot through Intel AWDL: - NOT IMPLEMENTED. Continuity Camera through Intel AWDL: - NOT IMPLEMENTED. 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 is included in the attached evidence dossier. 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 The first remote-visibility milestone would require 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. The subsequent data plane would require: - 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. AirportItlwm still needs the adapter that makes those facilities usable with Intel firmware. 11. WHAT CAN BE REUSED AND WHAT MUST BE DEVELOPED 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 Must still be developed in AirportItlwm: - 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 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. REALISTIC ENGINEERING EFFORT The following estimates are not promises. They are ranges for one experienced developer with hardware access. They are not mechanically additive, and later stages depend on undocumented Intel behavior and private Apple ABI. Milestone A — One controlled receive-only channel-6 dwell Required: - a manually authorized bounded Session Protection/ROC operation - generation/reset safety - start/end notification evidence - MAC1/channel-6 RX attribution - no TX Optimistic concentrated time: - 2–5 days Likely concentrated time: - 1–2 weeks Pessimistic: - 3–4 weeks Intermittent calendar time: - 1–6 weeks Milestone B — Reliable AWDL receive scheduling Required: - recurring Apple schedule to Intel grant mapping - infrastructure/AWDL coexistence - expiration and reset handling - profile changes and notification ownership Optimistic: - 2–4 weeks Likely: - 1–2 months Pessimistic: - 3–5 months Intermittent calendar: - 2–6 months Milestone C — One confirmed management advertisement Required: - valid scheduler window - accepted Time Event response - nonzero UID - matching Event Start - Station 3/TXQ4 submission - matching completion Optimistic after a working dwell: - 1–3 weeks Likely: - 1–2 months Pessimistic: - 3–4 months Intermittent calendar: - 1–6 months after Milestone A Milestone D — Repeated advertisements and remote visibility Required: - recurrence - template/sequence/timestamp refresh - safe backoff - Apple-peer acceptance Optimistic: - 2–4 weeks Likely: - 1–3 months Pessimistic: - 3–6 months Intermittent calendar: - 2–9 months Milestone E — Apple peer-lifecycle adapter Required: - safe PeerManager lifecycle - presence/absence/IPv6 presence - traffic registration - data mode - reset/removal ordering Optimistic: - 3–6 weeks Likely: - 2–4 months Pessimistic: - 6–12 months Intermittent calendar: - 3–15 months Milestone F — Peer-specific Intel station and queue Required: - station add/remove - queue/TID mapping - resource and generation management - teardown Optimistic: - 2–4 weeks Likely: - 1–3 months Pessimistic: - 4–8 months Intermittent calendar: - 2–10 months Milestone G — Native Apple dequeue and completion reporting Required: - correct Apple data-mode activation - dequeue - mbuf ownership - backpressure - exactly-once success/failure completion Optimistic: - 4–8 weeks Likely: - 2–5 months Pessimistic: - 6–12 months Intermittent calendar: - 4–18 months Milestone H — RX demultiplexing and awdl0 input Required: - Intel context/peer mapping - decapsulation policy - validated packet_info_tag - correct mbuf handoff - IO80211P2PInterface input Optimistic: - 4–8 weeks Likely: - 2–5 months Pessimistic: - 6–12 months Intermittent calendar: - 4–18 months Milestone I — AWDL IPv6 and mDNS Required: - bidirectional L2 - IPv6 peer traffic - multicast behavior - service activation Optimistic after TX/RX bridges: - 1–3 weeks Likely: - 1–2 months Pessimistic: - 3–6 months Milestone J — One-direction AirDrop transfer Required: - stable discovery - AWDL IPv6/mDNS - service negotiation - sustained ownership and teardown in one direction Optimistic after working IPv6/mDNS: - 2–6 weeks Likely: - 2–4 months Pessimistic: - 6–12 months Intermittent calendar: - 3–15 months after the IP/service layer Milestone K — Bidirectional AirDrop transfer Required: - both discovery roles - symmetric TX/RX - initiator/responder state - concurrent service traffic - robust peer removal Optimistic: - 1–3 months after one direction works Likely: - 4–9 months Pessimistic: - 12–24 months Intermittent calendar: - 6–30 months after one-direction transfer Milestone L — Daily-driver stability Required: - reset and restart - sleep/wake - association coexistence - station/queue teardown - peer churn - timeout and race handling - long-duration transfer - memory and mbuf validation Optimistic: - 3–6 months Likely: - 9–18 months Pessimistic: - 24 months or more Intermittent calendar: - 1–3 years or longer Milestone M — Maintenance across later macOS releases Required: - track private IO80211/PeerManager/Skywalk ABI - track OCLP payload availability - adapt to capability and security changes - repeat regression testing Typical compatible minor release: - 2–6 concentrated weeks Major release: - likely 2–6 months Worst case: - substantial redesign or no safe migration path This is ongoing maintenance, not a one-time completion task. 13. DOES ONE MORE SMALL EXPERIMENT MAKE SENSE? The smallest defensible next experiment would be one manually authorized, receive-only, bounded channel-6 dwell. Its value would be narrow but real: - prove that the AX210 firmware grants the intended P2P/AWDL window - prove whether MAC1/channel-6 frames reach the RX path during that window - separate scheduling failure from peer silence - avoid entering management TX or the data plane It would not prove AirDrop. It would not eliminate the months of remaining work. It would not turn the current branch into a usable release. For that reason, this experiment is best understood as a final feasibility check, not as the beginning of a short path to completion. 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 - the complete peer/data bridge remains absent - private Apple ABI risk grows sharply in the later milestones - stable daily-driver support and macOS maintenance would require a long-term development commitment 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 the full data plane would require - realistic time and risk estimates 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 it is now correctly classified as a substantial long-term driver project, not 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. The coherent Apple-to-Intel peer and data bridge is still missing. The remaining work is not one patch. It spans: - 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 working Intel AirDrop was achieved, but the architecture, proven milestones, failure boundaries and remaining implementation effort are now documented in enough detail that future work no longer has to begin from the vague statement that “AWDL is missing.”

SSDT Maintenance — SSDT Generator + macOS-Support Suite for Hackintosh Free · Open Source (MIT) · by Lumina Dev Apps WHAT IT IS SSDT Maintenance is a native macOS app that generates clean, OpenCore-ready SSDTs and compiles them to .aml locally with iasl — no manual DSL editing. On top of the usual device SSDTs, it includes a full set of macOS-support "maintenance" tables (AWAC, PMC, USBX, EC, SBUS-MCHC and more) that most Alder Lake / Raptor Lake (Z690 / Z790) builds need to boot and stay stable. You pick your ACPI paths and hardware, tick the tables you want, hit Generate ALL SSDTs, and drop the resulting .aml files into EFI/OC/ACPI/. WHAT IT GENERATES Device SSDTs: - SSDT-PLUG — CPU power management, auto-sized to core count - SSDT-DTPG — DTGP helper method - SSDT-HDEF — onboard audio (layout-id injection) - SSDT-IGPU — Intel iGPU (Alder/Raptor Lake, headless) - SSDT-GPU — discrete GPU + HDAU (AMD RDNA2 / Vega) - SSDT-LAN — Aquantia AQC107 / Realtek / Intel I225-I226 - SSDT-WIFI — Intel (itlwm) / Broadcom - SSDT-TB3 — Thunderbolt (Titan Ridge / Maple Ridge) - SSDT-XHCI — USB port maps (15 / 20 / 25 / 30 / Type-C) - SSDT-SATA / SSDT-NVME — storage controllers Maintenance SSDTs (macOS support) — on by default: AWAC, PMC, USBX, EC, SBUS-MCHC. Optional: PNLF, GPRW, RHUB, ALS0, BRG0. - SSDT-AWAC — system clock fix (RTC/AWAC), required on Z690/Z790 - SSDT-PMC — native NVRAM for 300-series and newer - SSDT-USBX — USB sleep/wake power properties - SSDT-EC — fake Embedded Controller - SSDT-SBUS-MCHC — SMBus + Memory Controller Hub - SSDT-PNLF — backlight (iGPU display) - SSDT-GPRW — instant-wake-from-sleep fix - SSDT-RHUB — USB root-hub reset - SSDT-ALS0 — fake ambient light sensor - SSDT-BRG0 — PCI bridge _ADR template (advanced) REQUIREMENTS - macOS 13.0 or later - iasl (the ACPI compiler): brew install acpica HOW TO USE IT 1. Install iasl: brew install acpica 2. Open the app. In the Generator tab, set the ACPI paths for your board. Defaults target the _SB.PC00 layout (Alder/Raptor Lake). Always confirm these against your own disassembled DSDT — if your PCI root is PCI0, or your iGPU is GFX0 instead of IGPU, adjust accordingly. 3. Choose your hardware presets (iGPU, dGPU, LAN, Wi-Fi, TB, USB, SATA, NVMe) and set your audio layout-id. 4. Scroll to Maintenance (macOS Support) and enable the tables you need. The essential five are on by default. 5. Click Output Folder (bottom bar), pick a destination, then Generate ALL SSDTs. Use Show Log / Copy Log to check the iasl output — every table should report 0 Errors. 6. Copy the generated .aml files into EFI/OC/ACPI/ and add each under config.plist → ACPI → Add (ProperTree "Snapshot" does this automatically). REQUIRED ACPI RENAMES Add these under config.plist → ACPI → Patch (Base empty, Count 0): SSDT-EC — only if your board's real EC device is named "EC": Comment : Rename EC to EC0 Find : 45435F5F Replace : 45433000 SSDT-GPRW — required for the instant-wake fix: Comment : Rename _GPRW to XGPW Find : 5F47505257 Replace : 58475057 RECOMMENDED SET For most Z790 builds, install AWAC + PMC + USBX + EC + SBUS-MCHC (add PNLF / ALS0 if wanted). Only add GPRW / RHUB with their renames/edits, and treat BRG0 as a template — edit its path and _ADR before using it. Generating all ten is fine; only deploy the ones your build actually needs. Note: injected SSDTs change how macOS sees your PCI tree. Verify device paths against your own DSDT and test before relying on them. Use at your own risk. DOWNLOAD - Release (DMG): https://github.com/luminadevapps/SSDTMaintenance/releases/tag/v1.1.0 - Source: https://github.com/luminadevapps/SSDTMaintenance First launch: the app is currently unsigned, so macOS Gatekeeper will block it the first time. Right-click the app and choose Open (once), or run: xattr -dr com.apple.quarantine /Applications/SSDTMaintenance.app FEEDBACK Bug reports, board-specific path issues, and suggestions are welcome — reply here or open an issue on GitHub. Mentioning your motherboard model + macOS version helps others too. SSDT Maintenance v1.1.0 · © 2026 Lumina Dev Apps · MIT License

Nice..enjoy

I found a bug and am fixing it. (cpu freq) I'll soon release a new version in the first post, marked as b2. https://github.com/Lorys89/App-test/raw/refs/heads/main/SiliconMonitorCenter 1.0 b2.zip

@lorys89 Great app and very nice UI design. It works very well. And translated to a lot of languages. Thanks.

@Slice Installation of VoodooHDA.kext 3.6.4 running macOS Tahoe 26.6 Beta 5(25G5065a) Perfect, the audio works and sounds great No HDMI aud

Thanks a lot @lorys89 nice app my friend!!

Working fine, thanks !!

Hi everyone, I’m developing this app for Macs with Apple Silicon processors. If you’d like to try it out and give me some feedback... https://github.com/Lorys89/App-test/raw/refs/heads/main/SiliconMonitorCenter 1.0 b2.zip

Thanks, I’ll give it a go later

VoodooHDA is finished with a help oh AI Qwen. But I checked every line of code didn’t allowed fantastic workarounds and allowed only right codes. It works!

There were a lot of posts about it way back then. Gave it a try but didnt work

Never exists

Hello everyone, it's a pleasure to announce that I've updated the main post with new information to keep you up-to-date with the changes... also, I wanted to let you know that the app now has a website. https://toshllm.com Thanks to everyone who has been testing the app since I first released it.

Thanks for this feature. Im too lazy to test layouts 😁

closed, gave permission

Final Release 3.6.4 I got clear sound on my AMD RX570 on TV Samsung. https://github.com/CloverHackyColor/VoodooHDA/releases/tag/Release364 If you hear a noise then open Info.plist and change InhibitCache option. Layout 0 will be traditional autodetect, other values same as AppleALC. But PciRoot(0x0)/Pci(0x1F,0x3) voodoo-layout-id <0C000000>

Close and re-open....I'm fixing that bug

version 1.0.5 shows nothing, only the safari icon

Give me some feedback, and I'll tweak or improve it if necessary.

i prefer this Features: Scans /Applications, /System/Applications, and ~/Applications Adaptive SwiftUI grid with native app icons Search by app name or bundle identifier One-click app launching Drag-and-drop folder organization Context menu actions: Open and Show in Finder Organize app icons without deleting or modifying installed apps Native macOS visual effect background Asset catalog with app icon and accent color LaunchPadBasic_1.0_b1.zip

Fixed is latest version 1.0.5: https://github.com/vbored/Launchback/releases/tag/v1.0.5 Just press ⌘Q while the grid is open to quit LaunchBack entirely and you good to go.

Working on this

Not at the moment