Intel-AX210-on-Sonoma-Sequoia-Tahoe

Intel AX210 on macOS Sonoma, Sequoia and Tahoe

macOS Sonoma removed drivers for Broadcom Wi-Fi cards found in Mac models prior to 2017. One of the affected cards is the Fenvi T-919, widely used in Hacks. OCLP developers published a fix that allows these Wi-Fi to work in Sonoma and Sequoia, adding this feature to the root patches that OCLP can apply. In order to apply root patches, OCLP requires macOS to run with some relaxed security features: SecureBootModel disabled and SIP partially disabled. This still represents a certain loss of security in macOS, as some users have noted.

Here I propose a model of Intel Wi-Fi card that by default lacks support but can be used in macOS thanks to the work of the OpenIntelWireless site. This is the Intel AX210S PCIe WiFi 6E card. This card can work with regular macOS security conditions without needing to relax Apple Secure Boot or SIP. It may be interesting for those who have lost Broadcom Wi-Fi support in macOS Sonoma+ or for those who want to keep the security of their system without resorting to OCLP patches.

What’s new in October 2026

User laobamac is working on updating itlwm.kext and AirportItlwm.kext, which had not received improvements for quite some time:

• itlwm.kext: This extension previously required the Heliport app to function, with the connection spoofing as Ethernet despite operating as Wi-Fi. Laobamac’s version works without Heliport and operates much more like native macOS Wi-Fi—using the native Wi-Fi interface for functions such as scanning, connecting, network switching, and private Wi-Fi addresses. Internet connectivity is established very early during system startup; there is no longer a need to wait on the Desktop for Heliport to establish the connection. This version of itlwm.kext is intended solely for macOS Tahoe.
• AirportItlwm.kext: Adds native support for macOS Sequoia 15.2+, a frequently requested feature on forums and GitHub.

Missing menu bar icon

If you miss the connection menu in the menu bar—the one HeliPort used to provide—I found a workaround.

The user felixblome has a project called “Easy Ethernet Icon” (no longer maintained); it is a simple, lightweight macOS menu bar app built with SwiftUI that displays the status of your Ethernet connection.

I added several features so it could serve as a replacement for the HeliPort menu bar icon, providing an icon that indicates whether the connection is active or inactive.

Designed to monitor only the system’s Ethernet interface, the app now includes a setting that lets the user choose between two Ethernet interfaces:

• Ethernet (the main built-in interface)
• Ethernet 2 (the interface created by itlwm.kext to support Intel Wi-Fi cards that lack native macOS compatibility).

The app works well and is very resource-efficient; the icon simply toggles between “on” and “off” states, and clicking it opens a simple menu for configuring parameters such as the monitored interface (Ethernet or Ethernet 2), whether to launch at startup, the icon style (macOS or Windows), and whether to display the connection speed.

Get the kexts

Get the released version of AirportItlwm.kext at: https://github.com/laobamac/itlwm/releases

For itlwm.kext, there is no released version available for download yet, so you must compile it yourself:

1.- Install Xcode and Python 3

2.- Get the itlwm project code

gh repo clone laobamac/itlwm

3.- Get version (commit) 3f75008 of MacKernelSDK in the same itlwm project folder

git clone https://github.com/acidanthera/MacKernelSDK.git
git -C MacKernelSDK checkout 3f750085caa17ec3a7880f11c11bf4f48cd6a164

4.- Compile itlwm · Tahoe

xcodebuild -project itlwm.xcodeproj -scheme itlwm \
-configuration Release ARCHS=x86_64 CODE_SIGNING_ALLOWED=NO build

5.- Compile AirportItlwm · Tahoe

xcodebuild -project itlwm.xcodeproj -scheme AirportItlwm-Tahoe \
-configuration Release ARCHS=x86_64 CODE_SIGNING_ALLOWED=NO build

6.- The results are located at

~/Library/Developer/Xcode/DerivedData/itlwm-<long_string>/Build/Products/Release/itlwm.kext
~/Library/Developer/Xcode/DerivedData/itlwm-<long_string>/Build/Products/Release/Tahoe/AirportItlwm.kext

Hardware

The card can be purchased in 2 different ways:

• fully assembled by Ziyituod and others: WiFi 6E Intel AX210S PCIe
• in 2 parts, card itself (WiFi 6E Intel AX210 NGW Bluetooth Card for Laptop with M.2/NGFF Connector) and adapter (PCIE X1 to M.2/NGFF A+E Key Adapter for WiFi Bluetooth Module).

Revert OCLP patch and config.plist changes

If you have been using Fenvi or Broadcom Wi-Fi, you must revert all the settings related to config.plist and OCLP root patch.

In config.plist:

• disable kexts (IOSkywalk.kext, IO80211FamilyLegacy.kext and AirPortBrcmNIC.kext)
• disable IOSkywalk.kext blocking
• change csr-active-config to 00000000
• change SecureBootModel to a value other than Disabled.

From OpenCore-Patcher (OCLP) >> Post-Install Root Patch >> Revert Root Patches.

Installing wifi module

The kexts are available on the OpenIntelWireless site. There are 2 ways to install Wi-Fi:

• itlwm.kext: uses IOEthernetController instead of IO80211Family so the connection spoofs as Ethernet even though it works as wifi. It does not use the macOS Wi-Fi menu, instead you have to use the HeliPort application to activate the Wi-Fi. On Ventura you need itlwm v2.2.0. On Sonoma you need itlwm v2.3.0.
• AirportItlwm.kext: uses IO80211Family so it works like the rest of the system’s Wi-Fi connections. It provides minimal Continuity features (Handoff and Universal Clipboard, not always available, no Airdrop) but cannot connect to hidden networks. No HeliPort app needed. On Ventura you need AirportItlwm v2.2.0. On Sonoma prior to 14.4 you need AirportItlwm v2.3.0 for Sonoma 14.0.

Both kexts should not be used at the same time, only one of them. I have tried both and they seem to have worked well. The card is well detected, as you can see in Hackintool.

Note about macOS 14.4 Sonoma: Apple has changed parts of the Wi-Fi stack. For this macOS you must get AirportItlwm v2.3.0 for Sonoma 14.4. itlwm.kext 2.3.0 + Heliport work fine too.

Note about macOS 15 Sequoia and macOS 26 Tahoe: itlwm.kext 2.3.0 + Heliport work fine. AirportItlwm.kext 2.3.0 for 14.4 doesn’t work, this kext must be updated by the dev.

All kexts are available in the releases page. You can get an updated version of Heliport here.

Speed up the connection

To connect before the login window, configure the network directly in itlwm.kext, without HeliPort. itlwm.kext joins the networks in the WiFiConfig dictionary of itlwm.kext/Contents/Info.plist when the kext loads during boot (IOKitPersonalities → itlwm → WiFiConfig → WiFi_1, WiFi_2, … with ssid and password strings). HeliPort detects the active connection and does not try to connect again. You can keep HeliPort for scanning and for switching networks.

Note: the passwords are stored as plain text in the kext (in your EFI partition).

Installing Bluetooth module

On Monterey and newer you have to install 3 extensions:

• IntelBTPatcher.kext, requires Lilu 1.6.2 or newer: fixes a bug in bluetoothd by correctly initializing the bluetooth module.
• IntelBluetoothFirmware.kext: load the firmware to the device and set the device name in USB Host Controller to Bluetooth USB Host Controller.
• BlueToolFixup.kext (available in Acidanthera’s BrcmPatchRAM package): on macOS Monterey IntelBluetoothInjector.kextstopped working due to changes made by Apple to the Bluetooth stack.

IntelBTPatcher.kext and IntelBluetoothFirmware.kext are inside the IntelBluetooth package available in the releases page.

Instant wake after sleep

There are users, myself included, experience this behavior of waking up immediately after sleep when using the Bluetooth module on Intel cards together with OpenIntelWireless kexts.

I reported this as an issue to the developer almost long time ago (Sleep/instant wake when using Bluetooth kexts), but he didn’t consider it a problem with the kexts.

There is a fix. Adding SSDT-GPRW.aml to the ACPI folder and config.plist, and adding the patch Change GPRW to XPRW, needs SSDT-GPRW.aml to ACPI >> Patch in config.plist, the PC properly enters sleep, but only wakes up from the power button; the ability to wake from the keyboard or mouse is lost. It’s a drawback, certainly, but preferable to losing the sleep functionality.

SSDT-GPRW

DefinitionBlock ("", "SSDT", 2, "DRTNIA", "GPRW", 0x00000000)
{
    External (XPRW, MethodObj)    // 2 Arguments

    Method (GPRW, 2, NotSerialized)
    {
        If (_OSI ("Darwin"))
        {
            If ((0x6D == Arg0))
            {
                Return (Package (0x02)
                {
                    0x6D, 
                    Zero
                })
            }

            If ((0x0D == Arg0))
            {
                Return (Package (0x02)
                {
                    0x0D, 
                    Zero
                })
            }
        }

        Return (XPRW (Arg0, Arg1))
    }
}

Change GPRW to XPRW patch

	<key>ACPI</key>
	<dict>
		<key>Patch</key>		
                <array>
			<dict>
				<key>Base</key>
				<string></string>
				<key>BaseSkip</key>
				<integer>0</integer>
				<key>Comment</key>
				<string>Change GPRW to XPRW, needs SSDT-GPRW.aml</string>
				<key>Count</key>
				<integer>0</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>R1BSVwI=</data>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data></data>
				<key>OemTableId</key>
				<data></data>
				<key>Replace</key>
				<data>WFBSVwI=</data>
				<key>ReplaceMask</key>
				<data></data>
				<key>Skip</key>
				<integer>0</integer>
				<key>TableLength</key>
				<integer>0</integer>
				<key>TableSignature</key>
				<data></data>
			</dict>
		</array>
	</dict>

You can read more deeply about this SSDT and patch at 0D/6D patch.

Summary

This hardware is a valid option for those who do not have Broadcom Wi-Fi in macOS Sonoma+ or do not want to apply OCLP root patches. It is not expensive and easy to install. As a main drawback, the features of the Apple ecosystem are lost (all with itlwm.kext and most with AirportItlwm.kext). Airdrop does not work in any way and this is the feature that I miss the most with respect to the Fenvi.

Note about Hackintool

Very small issue.

Hackintool by headkaze has an Extensions tab where it reports the installed kexts. In the list of kexts, itlwm is seen when we use itlwm and also when we use AirportItlwm. This is because, in the file /Applications/Hackintool.app/Contents/Resources/Kexts/kexts.plist, both kexts have Name=itlwm.

This is correct since the project is called itlwm. But I prefer Hackintool to show AirportItlwm when this is the active kext. This can be solved by modifying the value of the Name property in the AirportItlwm key inside the file.

By default it is like this:

But, changing to Name=AirportItlwm, Hackintool displays the active kext in a way I like better.

Bluetooth crashes/toggles off on AX200

If you have this issue: Bluetooth disconnects/toggles off during normal use (e.g. attempting to pair or use a device), requiring the toggle to be flipped off/on again — and sometimes requires a full reboot to recover, try this fix, confirmed working by davidm71:

1.-Configure the internal USB ports as 255 in the USB port mapping kext if they are not already.

2.- Edit NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82, make sure you have these keys:

<key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
<dict>
    <key>boot-args</key>
    <string>-bt4le -btlfxallowanyaddr</string>
    <key>bluetoothExternalDongleFailed</key>
    <data>
    AA==
    </data>
    <key>bluetoothInternalControllerInfo</key>
    <data>
    AAAAAAAAAAAAAAAAAAA=
    </data>
</dict>

Technical Explanation

Something has changed in the way macOS initializes hardware. According to davidm71 research, it may have been because Apple introduced stricter internal validation routines and changed how controller descriptors and firmware handoffs are cached. This resulted in macOS (especially after 13.x) to incorrectly flag internal adapters and hang on uninitialized firmware states (resulting in infinite polling loops), making these explicit NVRAM injections necessary to override the new system checks.