AirportBrcmFixup patches Apple's Broadcom drivers for cards Apple never sold

The problem: macOS refuses Broadcom cards Apple never shipped

Most Wi-Fi hardware in a MacBook was made by Broadcom, and Apple shipped several generations of the same silicon under its own names. Third-party cards built on those chips often carry a PCI device id that Apple's driver stack does not recognise, so the machine sees a radio it refuses to talk to. AirportBrcmFixup is an open source kernel extension that supplies the patches such non-native Airport Broadcom cards need, and the project states that it currently requires macOS 10.10 or newer.

The audience is narrow and technical: people who put a Broadcom-based card into a Mac, or who own a machine whose original card has died. It is not a general networking utility and it cannot add Wi-Fi hardware the machine does not have. Its scope is the Apple Broadcom driver stack, the kext it patches, and the loader behaviour around it.

What the patch set actually changes

The project's feature list reads like a list of specific error messages, which says something useful about how concrete the work is. One patch handles the chip identifier check, noted as identifier 0xaa52, which the project says was required for a successful driver start in macOS 10.12 and earlier. Another covers the "Failed PCIe configuration patch" error that shows up on some cards. A third makes the "Third Party Device" response carry the vendor name Apple, and a fourth removes the white-list check that would otherwise reject a card outright.

The rest of the list is behaviour tuning rather than simple enablement. There is a 5GHz and country code patch, with the United States as the default, a WoWLAN disabler that is on by default to avoid low speed after wake, a patch that disables an LPO panic in AirPortBrcmNIC, and a transmit chain match that enables full transmit power on the BCM94360. These are patches applied to an Apple driver running inside the kernel, which is why the project works through a kernel extension loader rather than an ordinary application.

Which kext loads depends on the macOS version table

A Broadcom card in a Mac is handled by one of several AirPort kexts, and the names and device ids shift from release to release. The project publishes a table per macOS version, and each row gives the kext name, the device ids that kext handles, and an IOProbeScore value used to pick a matching driver.

The block below is the 10.15 row, taken from that list:

[10.15]
- AirPortBrcm4360: 4331, 4353, IOProbeScore = 1400
- AirPortBrcm4331: removed
- AirPortBrcmNIC: 43ba, 43a3, 43a0, IOProbeScore = 1400
- AirPortBrcmNIC-MFG: removed

Read the table as a shrinking set. In 10.8 and 10.9 there were only AirPortBrcm4360 and AirPortBrcm4331, and the project notes that for most cases a fake id of 43a0 was enough to get working Wi-Fi. From 10.13 one family was split into AirPortBrcm4360, AirPortBrcmNIC and AirPortBrcmNIC-MFG, so a proper fake id has to be chosen to make the right kext load, and the project warns that some device ids restrict a kext in one place but not another, the 5GHz range being the example it gives. By 11 the AirPortBrcm4360 entry is marked removed, and in 12 and 13 AirPortBrcmNIC is marked as moved to a new location inside IO80211FamilyLegacy.kext. Every entry is listed as removed for 14 and later, where the project points users to OCLP.

Boot arguments are the whole control panel

The kext is configured mainly through boot arguments, which is unusual for a driver extension and means nothing takes effect until the machine boots with them. The switches come in two shapes. The leading-dash form is a set of toggles: -brcmfxdbg turns on debugging output, -brcmfxbeta enables loading on a macOS version the project does not support, -brcmfxoff disables kext loading altogether, -brcmfxwowl enables WoWLAN since that patch is off by default, and -brcmfx-alldrv allows patching for all supported drivers regardless of the current system version.

The key-value form tunes individual behaviours. brcmfx-country=XX changes the country code, with the United States, China and other values listed, and the project says it can also be injected through a DSDT or through the DeviceProperties section of a bootloader. brcmfx-aspm overrides the value used for pci-aspm-default, with 0 disabling ASPM and the remaining documented values being named constants such as kIOPCIExpressASPML0s, kIOPCIExpressASPML1, kIOPCIExpressCommonClk and kIOPCIExpressClkReq. brcmfx-delay postpones the start of the native Broadcom driver by a number of milliseconds, which the project says can solve panics or a missing Wi-Fi device in Monterey, with a starting point of 15 seconds that you then reduce until boot becomes unstable. brcmfx-driver selects a single kext to load, numbered 0 for AirPortBrcmNIC-MFG, 1 for AirPortBrcm4360, 2 for AirPortBrcmNIC and 3 for AirPortBrcm4331. brcmfx-txchain sets the tx chain core mask defaults in throttle mode to 2 or 3.

Installation: four combinations and the Lilu.kext pairing

The project lists four supported installation types, and the choice matters. The simplest is Clover Airport Fix plus AirportBrcmFixup. The project marks the second as preferable: Clover Airport Fix, plus AddProperties with a fake device id, plus AirportBrcmFixup. The third adds a FakePCIID kext and a FakePCIID_Broadcom_WiFi.kext, and the fourth drops Clover Airport Fix altogether and relies on AirportBrcmFixup with those two FakePCIID components.

The pairing requirement is not optional. The project states in bold that a debug version of Lilu.kext has to sit in the same folder as AirportBrcmFixup and that the two must be used together, and it credits vit9696 for Lilu.kext and for help implementing some of the features. It credits PMheart with the initial idea and implementation, names al3xtjames for the LPO panic disabling in AirPortBrcmNIC, and lists darkvoid and RehabMan for the FakePCIID implementation that is partly used here. lvs1974 is credited with writing the software and maintaining it.

One further trap sits around the injector kexts. The project warns that in macOS 11 and later AirPortBrcm4360 was completely removed, and that using an injector kext with that class name and matching vendor-id and device-id blocks loading of the original airport kext. The answer given is that the injectors for AirPortBrcm4360 and AirPortBrcmNIC were taken out of the main Info.plist and deployed in the PlugIns folder as AirPortBrcm4360_Injector.kext and AirPortBrcmNIC_Injector.kext, and that you have to block or remove AirPortBrcm4360_Injector.

Patching the driver instead of renaming the card

The project itself lays out the difference between two ways of making a card work, and it is the clearest argument for what this kext adds. Until macOS 10.13 there were only two kexts, and for most cases a fake id of 43a0 was enough to get working Wi-Fi, because the driver stack had a single place to match. From 10.13 the family split, a proper fake id has to be picked so the right kext loads, and device ids that limit one kext do not limit another.

Renaming the card changes what the system believes it is talking to. AirportBrcmFixup goes further in and changes what the driver does once it has loaded: it satisfies the chip identifier check, works around the failed PCIe configuration patch, turns the third party device response into the Apple vendor name, removes the white-list check, and then adjusts country code, WoWLAN, the LPO panic and transmit chain behaviour. For a card that Apple did not certify, matching by identity alone stopped being enough at 10.13, and the patch set exists to cover the rest.

Where the kext stops, and what an upgrade costs

The clearest limits are in the version table itself. From macOS 14 onwards every entry is marked removed and the project directs users to OCLP for that generation, so on a current system this kext is not what makes a card work. The supported set is narrow as well: the feature list names AirPort_Brcm4360, AirPort_BrcmNIC and AirPort_BrcmNIC_MFG, so a Broadcom generation outside those three is out of scope by definition. The -brcmfxbeta argument exists to enable loading on an unsupported macOS version, which says plainly that the kext was written against particular releases and the rest is best effort. Operationally, most options live in boot arguments, so any change costs a reboot, and the project ships -brcmfxoff so a badly matched kext can be backed out of.

The licence is BSD-3-Clause, with LICENSE.txt in the repository root. The last push was on 2026-09-27, the same day release 2.2.1 was tagged, after 2.2.0 in July 2025 and 2.1.9 in October 2024. The upgrade cost is less about code churn than about the moving target: because the driver table changes with every macOS release, a card that worked on one version may need a different fake id on the next, and the kext, the matching Lilu.kext build and the boot arguments all have to be revisited together.

Editorial conclusion

Adopt AirportBrcmFixup if you have a Broadcom-based card that macOS will not recognise, you are on a macOS release the project still supports, and you are willing to keep a debug build of Lilu.kext beside it and reconfigure the machine through boot arguments on every change. Skip it if your card is a supported Broadcom family on macOS 14 or later, where the project directs you to OCLP instead, or if you need a card that Apple never supported at all. Verify first that your PCI device id appears in the project table for your exact macOS version, and that the Lilu.kext you plan to use is the debug build the project requires.

Frequently asked questions

Official sources

1. acidanthera/AirportBrcmFixup on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases