Broadcom FullMAC Wi-Fi support on macOS Sonoma, Sequoia and Tahoe without root patches

[kgp]

29 minutes ago, Mac Hosehead said:

Actually, the BCM43602CDP has different size antenna connections so it will not work in the same card adapter.

 

Some things about the photo: If the shield really says BCM43602CS then a different card has been put in the adapter. I assume it can be swapped with the right card. Another thing is that the photo shows no wires hooked up to the antenna connections on the card. I don't know how that is supposed to work. Kinda screwy all around.

you are right, I was just assuming that he confused BCM4360CS with BCM43602CS. Looking now closely to the image of  his originating post, it rather seems, that he has been cheated by the seller:

 

 

A BCM43602CDP would certainly not be compatible with this adapter, as it needs 4 antennas. The BCM43602CS would have been the right card for swapping anyway. Thanks for your correction. Appreciated!

Edited November 12, 2025 by KGP-iMacPro

[schrup21]

6 hours ago, Mac Hosehead said:

BCM43602CDP

 

The CDP might eventually fit in a Fenvi T919? The BCM94360CD within the Fenvi has MHF1 Connectors (while a BCM94360CS has MHF4)

Spoiler

 

MHF1 vs MHF4

 

Spoiler

 

Although wikidevi.wi-cat.ru says BCM943602CDP has also MHF4

Spoiler

 

Edited November 12, 2025 by schrup21

[kgp]

1 hour ago, schrup21 said:

 

The CDP might eventually fit in a Fenvi T919? The BCM94360CD within the Fenvi has MHF1 Connectors (while a BCM94360CS has MHF4)

  Reveal hidden contents

 

MHF1 vs MHF4

 

  Reveal hidden contents

 

Although wikidevi.wi-cat.ru says BCM943602CDP has also MHF4

  Reveal hidden contents

 

 

I purchased this PCIe adapter for my BCM943602CDP on Ebay Germany quite some time ago. The antenna connectors fit perfectly, and the BCM943602CDP module sits solid, even though there are no dedicated holes to secure it with screws:

 

[Jessy Lou]

I pull out the metal box which was covering the device, and oh surprise surprise: KGP-iMacPro you are right, I've been nicely cheated by the reseller. My device is not a BMC943602CS but a BMC94360CS.

 

So, while I'm waiting for the real card to arrive, I'm going to read carefully your advices concerning my config.plist.

Without waiting any longer, I can tell you that I didn't cleaned-up my config.plist with the MinKernel on:
 

a.) Lilu.kext MinKernel 10.0.0

b.) VirtualSMC.kext MinKernel 10.0.0

c.) WhateverGreen.kext MinKernel 12.0.0

d.) AppleALC.kext MinKernel 12.0.0

e.) IntelMausi.kext MinKernel 13.0.0

As for Tahoe, I'm working with another config.plist dedicated to Tahoe with a proper SMBIOS.
I'm going also check whether IntelMausi.kext works under Tahoe with DisableIOMapper= false, i.e. AppleVTD enabled (which is the case for the actual Sequoia config.plist).

Anyway: thank you to all of you.

@eSaF: don't be upset, I wanted first to ensure I had the right device, which now is not a point anymore.

[kgp]

32 minutes ago, Jessy Lou said:

I pull out the metal box which was covering the device, and oh surprise surprise: KGP-iMacPro you are right, I've been nicely cheated by the reseller. My device is not a BMC943602CS but a BMC94360CS.

 

So, while I'm waiting for the real card to arrive, I'm going to read carefully your advices concerning my config.plist.

Without waiting any longer, I can tell you that I didn't cleaned-up my config.plist with the MinKernel on:
 

a.) Lilu.kext MinKernel 10.0.0

b.) VirtualSMC.kext MinKernel 10.0.0

c.) WhateverGreen.kext MinKernel 12.0.0

d.) AppleALC.kext MinKernel 12.0.0

e.) IntelMausi.kext MinKernel 13.0.0

As for Tahoe, I'm working with another config.plist dedicated to Tahoe with a proper SMBIOS.
I'm going also check whether IntelMausi.kext works under Tahoe with DisableIOMapper= false, i.e. AppleVTD enabled (which is the case for the actual Sequoia config.plist).

Anyway: thank you to all of you.

@eSaF: don't be upset, I wanted first to ensure I had the right device, which now is not a point anymore.

 

Well, I configured for you a config.plist, that is universal and works with any version of macOS, including Tahoe. You can take it or leave it.. 😉. I don't catch the point why to use different EFI's or config.plists with different versions of macOS, if not deemed necessary. Using a different SMBIOS for Sequoia and Tahoe would even implement, that you register two different machines at Apple...  I propose to use SMBIOS MacPro7,1 or one SMBIOS of your choice for all macOS versions.  

 

And yes, please let me know, if IntelMausi.kext works under Tahoe with DisableIOMapper= false, i.e. AppleVTD enabled. It is important for my summary. 👍

Edited November 12, 2025 by KGP-iMacPro

[Jessy Lou]

Thanks KGP-iMacPro for your config.plist: on top of the that it does work perfectly also for my HW, it is going to simplify my life.
My next step is now to use (as you wrote) Mac7,1 for SMBIOS so that I can use only one EFI folder.

To explain why I have (until now) two EFI folders: just because I struggled so much to install Tahoe on its earlier beta version that I didn't want to put the mess on my running Sequoia (which used on my daily personal business).

Some the USBMap: one was dedicated to older macOS version while with Tahoe the USB Map changed, and the second was dedicated to Tahoe based on SMBIOS suppored by this new macOS. At this time, the new release of Hackintool wasn't available to do it on an easier way, as the solutions we can find easily nowadays regarding AppleHDA for Tahoe.
 

Next steps:
1). setting the proper SMBIOS on the good config.plist you provided me with, using Mac7,1. BTW: my understanding is kernel (min or max) for Tahoe is 24. I see in your config.plist you're using 25 to activate BCMC (on which I was struggling on another EFI folder, but now it is going to become an old story thanks to your help).
2). test IntelMausi.kext to work properly under Tahoe with DisableIOMapper= false, i.e. AppleVTD. I might need to Enable IOMMUs and Activate AppleVTD (based on the documentation linking to Dortania's Guide).
3). Once I receive my real BMC943602CS card, to check and run everything from the documentation to proceed with the native WiFi.

My HW BIOS has been check especially on the V-TD I recently activated.

So far everything is perfect. 👍

[Jessy Lou]

Step 1: OK.
Step 2: Ethernet KO. I'm not that surprised due to the info I read in this forum. The only things working correctly is BT... and my previous config for the sound 🙂.

I have to read the forum to see if I can get some workaround to get back Ethernet.

What is extremely comfortable for me: only one EFI folder. This changes my life! 😃

[kgp]

55 minutes ago, Jessy Lou said:

Step 1: OK.
Step 2: Ethernet KO. I'm not that surprised due to the info I read in this forum. The only things working correctly is BT... and my previous config for the sound 🙂.

I have to read the forum to see if I can get some workaround to get back Ethernet.

What is extremely comfortable for me: only one EFI folder. This changes my life! 😃

 

1.) I suggested SMBIOS MacPro7,1 and not Mac7,1. Hopefully we refer to the same SMBIOS 😉 BTW... with SMBIOS MacPro7,1, you need to use RestrictEvents.kext and boot args "restrict=1 revpatch=pci,sbvmm"!

 

2.) With respect to IntelMausiEthernet.kext, you have to wait for a fix by the developer of the kext, which is on the way. Unfortunately, there is no native macOS alternative for the Intel I21x/I219. Until implementing BCMC, you can use IntelMausiEthernet.kext with DisableIOMapper=true under Tahoe though, i.e. AppleVTD disabled. There is no other fix for this issue you would find in the forum.   

 

For your investigation rather focus on BCMC for now and on what I wrote that needs still to be implemented from your side to make it work once you have the adequate card and PCIe adapter 😉 Everything else anyway is OOT here, as this is a thread about BCMC only.  For any other system relevant question you are invited to post here, although this thread has it's focus on X299. 

Edited November 12, 2025 by KGP-iMacPro

[Jessy Lou]

My mistake: this is MacPro7,1 not Mac7,1.
I'm going to add the instructions to the boot args, RestrictEvents.kext.is already mounted as I kept your config.plist instructions. 🙂

I would happy to test the new release when available. Until then (receiving my real BCM card), I stay on Sequoia.

Thank you for everything! 👍

[kgp]

Status of AWDL under macOS 26 Tahoe

 

BCMC:
Provides working Wi-Fi under Tahoe, but AWDL/Continuity remains unavailable. This appears to be due both to missing AWDL support in the BCMC firmware and to the removal of the AWDL/Continuity frameworks in Tahoe.

 

OCLP:
IOSkywalkFamily and IO80211FamilyLegacy do load, but without OCLP they offer no Wi-Fi functionality. At the moment, Wi-Fi cannot be enabled under Tahoe, since OCLP does not yet provide patches for Tahoe’s redesigned IO80211Family structure. Restoring AWDL would likely require reintroducing the removed AWDL/Continuity frameworks, which may be non-trivial.

 

@Austere.J, I’d be very interested in your thoughts on this and whether you see any potential direction for Tahoe with AWDL in the future. 

[kgp]

2 hours ago, eSaF said:

As a layperson who has ZERO idea how anything works let alone all this WIFI LAN/connection saga, my thinking is, as WIFI is available in one but not the other then on the opposite side Ethernet is available on OCLP but not WIFI, why can't the two be somehow gelled to achieve both functions.

As far as my limited thinking and knowledge goes, yes it would involve a lot of rehashing of code (my idea of a technical term) to make it happen, surely it can be done if the Devs of both OCLP and BCMC hacks put their heads together??!!

 

My thinking is the one likely to come through with the solution will be @Mieze.

Not throwing shade at the other Devs or trying to create an air of competition as I am sure they are all working diligently to find a viable working solution.

 

Cheers.

 

One important step for the use of BCMC is to have the Lucy Kext Family working with AppleVTD enabled under Tahoe. Regarding AWDL, however, I am very pessimistic about both BCMC and OCLP (if it will be available at all in the near future).

Edited November 15, 2025 by KGP-iMacPro

[deeveedee]

5 hours ago, KGP-iMacPro said:

I am very pessimistic about both BCMC and OCLP (if it will be available at all in the near future).

 

It's easy to forget that the Devs who are building BCMC and OCLP are volunteers who contribute out of the goodness of their hearts while they live lives outside of the hackintosh community.  There's no need to manufacture an artificial deadline for Tahoe support when Sequoia works perfectly well and there's nothing new in Tahoe for Intel users.

 

Relax.

[kgp]

55 minutes ago, deeveedee said:

 

It's easy to forget that the Devs who are building BCMC and OCLP are volunteers who contribute out of the goodness of their hearts while they live lives outside of the hackintosh community.  There's no need to manufacture an artificial deadline for Tahoe support when Sequoia works perfectly well and there's nothing new in Tahoe for Intel users.

 

Relax.

i don’t remember that I constructed recently any deadline or put pressure on any developer. I deeply appreciate and estimate their work. I just summarized, why it might be difficult to make AWDL work under Tahoe at all either with BCMC or OCLP and asked @Austere.Jabout his personal opinion. And please don’t blame me that you and @eSaF only quoted half of my post and sentence, which entirely reads: Regarding AWDL, however, I am …😉. Admittedly, my second post doesn't sound very optimistic anyway, but not because of the developers' work, but because of what Apple has changed and is presenting again in Tahoe.

Edited November 15, 2025 by KGP-iMacPro

[schrup21]

On 11/5/2025 at 5:19 PM, dracon said:

SparkLAN adapters

Out of curiosity I ordered a WNFB-266AXi. Bad news: the module has an M-Key plug, my M.2 slot is A-Key. Normally M.2 Wifi modules have A+E and thus fit in an A slot - but not an E-Key module. I was able to find a "Riser" adapter with A+E plug and apparently M slot (I ordered) but I doubt that it works that way
 

Here the comparison 

Spoiler

 

Spoiler

 

[fspkwonx86]

just in! with a crash report tahoe anything if your system is exceeding the speed limit my assumption is wifi included

so if it like also writes to disk at the same time ex installing a steam game you have to go into settings and throttle the download to like

4mbps or w/e is safe or else it reboots/crashes to login

[miliuco]

On 11/12/2025 at 4:38 PM, KGP-iMacPro said:

with SMBIOS MacPro7,1, you need to use RestrictEvents.kext and boot args "restrict=1 revpatch=pci,sbvmm"!

 

I had never heard restrict=1 boot arg, are you sure that is a valid boot arg?

[kgp]

1 hour ago, miliuco said:

 

I had never heard restrict=1 boot arg, are you sure that is a valid boot arg?

 

Many thanks for the hint!

restrict=1 must be some relic I picked up somewhere on the internet a long time ago, and I simply kept using it without ever questioning it. After checking the Acidanthera documentation, it’s indeed not a valid boot argument for RestrictEvents.

The only arguments that matter here are the rev* flags — in my case revpatch=pci,sbvmm.

 

If somebody needs more information:

 

"pci" enables the PCI / Memory / Board-ID patch. It disables the MacPro7,1-specific PCI and memory validation checks (such as unsupported RAM warnings and PCI configuration checks).

 

"sbvmm" enables the Sidecar / Virtual Machine / VMM patch. It removes various virtualization- and Sidecar-related checks on unsupported hardware.

Edited November 15, 2025 by KGP-iMacPro

[FirstCustomac]

35 minutes ago, KGP-iMacPro said:

"sbvmm" enables the Sidecar / Virtual Machine / VMM patch. It removes various virtualization- and Sidecar-related checks on unsupported hardware.

Thus, sbvmm is not strictly necessary — it’s optional and only relevant if you need the Sidecar/VMM-related patches. For fixing the MacPro7,1 PCI and memory checks, "pci" alone might be sufficient.

Hi, off topic but to my knowledge, vmm patch is necessary for getting OTA updates since Sonoma for those with T2 SMBIOS. Also required for install or update macOS on unsupported SMBIOS since Big Sur 11.3? 

[kgp]

23 minutes ago, FirstCustomac said:

Hi, off topic but to my knowledge, vmm patch is necessary for getting OTA updates since Sonoma for those with T2 SMBIOS. Also required for install or update macOS on unsupported SMBIOS since Big Sur 11.3? 

 

Oops, I totally forgot about OTA updates and clean install of macOS. You are totally right! sbvmm bypasses the platform and virtualisation checks, making the system compliant.

Edited November 15, 2025 by KGP-iMacPro

[Jessy Lou]

Success!

Finally I received my real BCM743602CS and with no surprise, thanks to the documentation, I succeeded in using the Apple Broadcom Wi-Fi Companion.
Thanks to the support from KGP-iMacPro I have now the exact same config.plist with the relevant (updated) kexts working with no limitation at all on Sequoia, and with the known limitations on Tahoe 26.0.

Next step for me: upgrading Tahoe to 26.1 and run the same tests to confirm what others did already: success with the known limitations.
I may try to work on a proper DMAR table, which is not the case right now. 

Many thanks 1st to the author Austere.J, many thanks for the time and the support on the EFI configuration to KGP-iMacPro, without forgetting eSaF.

Let me know if anyone need further information that could help the team.
Cheers

[kgp]

14 minutes ago, Jessy Lou said:

Success!

Finally I received my real BCM743602CS and with no surprise..

I hope it is just a typo and you finally received a BCM943602CS ☺️

[Jessy Lou]

You're right! BCM943602CS. I guess there's no BCM743602CS.

[Jessy Lou]

As other already experimented: when waking-up from sleep no possibility to get the control of inputs.
I also experimented a couple of KP before entering in sleep mode, crashing two old HD formatted in HFS+: this drove me to reformat them on APFS.
I still have to work on the proper DMAR table that could possibly help getting some more stable system.

 

[kgp]

46 minutes ago, Jessy Lou said:

As other already experimented: when waking-up from sleep no possibility to get the control of inputs.
I also experimented a couple of KP before entering in sleep mode, crashing two old HD formatted in HFS+: this drove me to reformat them on APFS.
I still have to work on the proper DMAR table that could possibly help getting some more stable system.

 

you can upload BCMC related kernel panic logs for the developer. I don’t think that a modified DMAR table will help much in this issue. 
 

Good luck,

 

KGP

[Jessy Lou]

Next time I test something on Tahoe, I will. But so far, two complete days to recover the two disks... made me taking the decision to remain on Sequoia.