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

[kgp]

@Henties, if I send my Hack to sleep with the kext enabled, I directly end up with a KP. With the kext disabled sleep/wake works flawless on my system. The possibility of such flaw of the kext has been even outlined by @Austere.J in this thread. Also that the actual version is not ment for a productive system. Remember that everything is still beta. Maybe it was not a good idea to name the version of the kext 1.0.0 yet.. 😉     

Edited October 8, 2025 by KGP-iMacPro

[jlrycm]

26 minutes ago, KGP-iMacPro said:

@Henties, if I send my Hack to sleep with the kext enabled, I directly end up with a KP. With the kext disabled sleep/wake works flawless on my system. The possibility of such flaw of the kext has been even outlined by @Austere.J in this thread. Also that the actual version is not ment for a productive system. Remember that everything is still beta. Maybe it was not a good idea to name the version of the kext 1.0.0 yet.. 😉     

If you enable the kext but turn/toggle off wifi and then put the system to sleep, does it end up in KP?

[kgp]

14 minutes ago, jlrycm said:

If you enable the kext but turn/toggle off wifi and then put the system to sleep, does it end up in KP?

 

Yes it also ends up in KP... Else, the kext seems very stable now. Not even one KP within 18 hours of uptime.

Edited October 8, 2025 by KGP-iMacPro

[Henties]

@KGP-iMacPro Yes I am aware that this method is currently still in an early beta phase and that problems should be expected.

 

@jlrycm Will be testing your suggestion shortly and provide feedback on the outcome.

 

Greetings Henties

 

@jlrycm irrespective of whether I disable WiFi or set it inactive, sleep problems remain.

Only disabling the kext in the config.plist file restores sleep to full functionality, after a reboot of cause. 

Edited October 8, 2025 by Henties

[schrup21]

6 hours ago, KGP-iMacPro said:

 

@ichelash, I already posted here in this thread twice the short version of how I managed to get both working on my system. Here the link to the happy end of the long version.

Good to know, that IntelLucy works with VTD enabled in Tahoe - IntelMausiEthernet does not.

[Mieze]

@schrup21 In principle, all my drivers (IntelMausiEthernet, IntelLucy, LucyRTL8125Ethernet, RTL8111Ethernet and AtherosE2200) work with AppleVTD under Tahoe but you need a mainboard that works properly with AppleVTD under Tahoe too. Unfortunately, Apple has changed something with regard to AppleVTD so that some boards, which used to work fine with AppleVTD in the past, now refuse to work with it and vice versa. Also keep in mind that rolling back IOSkywalkFamiliy.kext may break AppleVTD support as @KGP-iMacPro recently discovered (see here).

 

Mieze 😺

Edited October 9, 2025 by Mieze

[sanigo]

19 hours ago, schrup21 said:

The behavior that Sleep results in a KP is described in "Issues" 😉

 

https://github.com/0xFireWolf/AppleBCMWLANCompanion/blob/main/Documentation/Issues.md

 

@sanigo as I said, I doubt your USB issue could be caused by the mapping - but I'm using the USB Toolbox method, maybe you would give it a try.

 

https://github.com/USBToolBox/kext

 

I think It could be possible that with the patched DMAR.aml, a configuration is missing, and therefore the controller isn't working properly. You could test whether the issue get's fixed and AppleVTD runs stably without the patched DMAR.aml (and of course without dropping DMAR)

 

Btw. AppleVTD works for me without the patched DMAR.aml

USBToolBox is not my curer,  i have tested.

[meg2014]

12 hours ago, Mieze said:

@schrup21 In principle, all my drivers (IntelMausiEthernet, IntelLucy, LucyRTL8125Ethernet, RTL8111Ethernet and AtherosE2200) work with AppleVTD under Tahoe but you need a mainboard that works properly with AppleVTD under Tahoe too. Unfortunately, Apple has changed something with regard to AppleVTD so that some boards, which used to work fine with AppleVTD in the past, now refuse to work with it and vice versa. Also keep in mind that rolling back IOSkywalkFamiliy.kext may break AppleVTD support as @KGP-iMacPro recently discovered (see here).

 

Mieze 😺

 

Okay, so I posted earlier about this utility as while back as I was working on Sequoia (15.7.2) and it was fine.  BUT, on Tahoe, it's not fine.  If I load the identical config as I am currently using (and is working just fine on Sequoia), the IntelLucy driver for my 10G card will flap, about every 5 seconds.

 

To me, this enforces your thoughts that Apple changed some things about their implementation of VTD from Sequoia to Tahoe.  If I do not load the BCMC config on Tahoe, the IntelLucy driver is just fine.

 

My motherboard is an Asus, but as it's a Z790, it's pretty modern, the BIOS firmware is also very much up to date and on Sequoia, Ventura, even Monterey, all is well, and of course, Ventura and Monterey do not a special config for my WiFi adapter, but I'm just pointing out that IntelLucy has been great.

 

I thought long and hard about posting this on the IntelLucy thread, but I don't believe this is really about one driver.  I think, and I would remind everyone to make sure they remember that the BCMC config and drivers are, at best, an early beta.

 

I think I'm just going to wait a while to see how things with BCMC work out, because, after all, as I said when I first posted about my success with BCMC on Sequoia, I just don't use WiFi that much anymore and I do all of my file transfers (and my Video work means my files are big, very big - so WiFI just doesn't have the throughput), so I'm just going to not enable BCMC on Tahoe for now.  It works on Sequoia, and that's good enough for now.  I just thought you might like to know that I think my finding seem likely to reinforce your thoughts about what Apple has done with VTD on Tahoe.

Edited October 10, 2025 by meg2014

[kgp]

No flapping of IntelLucy with BCMC here on my ASUS X299 Sage 10G (BIOS 4701 from January 2025), neither under Sequoia nor Tahoe (same EFI-folder and configuration). IntelLucy behaves just rock solid, the same states for Apple´s DEXT DriverKIT. BCMC, however, is still somewhat unstable, ends up with one or two KPs a day and does not work at all with sleep/wake. That´s all about this topic from my side for now. Thus, given the early beta status of BCMC and its actual limitations outlined by @Austere.J, everything is working as expected. 

 

Having written the above, I noticed that I was actually running Apple´s DEXT DriverKIT with BCMC under Tahoe, which just works flawless. Just for another crosscheck, I therefore changed to IntelLucy and witnessed that the IP was suddenly self assigned only. Now things get really weird. For further investigation of this issue, I totally removed BCMC (including the PCIe adapter) from my system and IntelLucy suddenly continued in not establishing any connection with VTD enabled under Tahoe, whereas the DEXT DriverKit does and both drivers also work flawless under Sequoia with VTD enabled. No idea what changed recently on my system, but I am totally convinced and even demonstrated in different posts and threads that both drivers worked also under Tahoe with and without BCMC and with VTD enabled. I am clueless for now and I am digging for the reason of such sudden change. I do not remember at which moment I updated from 26.0 to 26.0.1 and if there might be any relation..

Edited October 12, 2025 by KGP-iMacPro
Update

[schrup21]

17 hours ago, Mieze said:

@schrup21 In principle, all my drivers (IntelMausiEthernet, IntelLucy, LucyRTL8125Ethernet, RTL8111Ethernet and AtherosE2200) work with AppleVTD under Tahoe but you need a mainboard that works properly with AppleVTD under Tahoe too. Unfortunately, Apple has changed something with regard to AppleVTD so that some boards, which used to work fine with AppleVTD in the past, now refuse to work with it and vice versa. Also keep in mind that rolling back IOSkywalkFamiliy.kext may break AppleVTD support as @KGP-iMacPro recently discovered (see here).

 

Mieze 😺

I'm aware that Apple's changes in Tahoe are the cause - everything works fine until Sequoia. However, AppleVTD seems to be working for me (AppleVTD can be found in IOService, BCMC is working without issues). Since I'm using BCMC WiFi, a rollback of IOSkywalkFamily.kext is not performed (my root volume is indeed sealed/untouched). For me it looks like IntelMausiEthernet is indeed working (kextstat shows the KEXT is loaded) but the LAN interface keeps crashing if you connect the LAN cable. Apparently the negotiation is not successful.

kextstat:

Spoiler

 

IOService

Spoiler

 

I can live with the restriction, my device is a laptop - I only need the LAN IF occasionally and then I switch my config. 😊

[Mieze]

1 hour ago, schrup21 said:

For me it looks like IntelMausiEthernet is indeed working (kextstat shows the KEXT is loaded) but the LAN interface keeps crashing if you connect the LAN cable. Apparently the negotiation is not successful.

kextstat:

You are on a wrong track. With AppleVTD enabled, DMA buffers must be properly mapped by the IOMMU to allow DMA access by the NIC. If this doesn't work, the read/write access from/to the buffer will be blocked by the IOMMU at the hardware level and there will be no data transmission. That's what happens after the cable is plugged in. Now, the driver steps in, realises that there is no progress in data transmission, although there are buffers, a.k.a. packets, waiting to be transmitted and assumes a tx deadlock. In order to recover from this situation, it performs a chip reset and the cycle starts again.

 

Mieze 😺

[XanthraX]

On 9/28/2025 at 7:23 PM, HyperX7 said:

 

What is the probability of this card working? I want to try according to the return I will receive from you. Thank You!

 

 

 

How can I copy the firmware files to the /usr/local/share/firmware/wifi/ location. Terminal said permission denied.

Open Finder. Press Cmd+Shift+G. In the dialog, type /usr/local/share. It will open the folder. Check if you have the folder firmware inside. If not, make one with Cmd+Shift+N and name it firmware. Open it and create another folder and rename it wifi. Open it and copy the firmware bin there. if asks for password type it.

[pkdesign]

I think you mean /usr/share

[Henties]

@pkdesign Me thinks not. The OP recommends to use /usr/local/share/firmware/wifi/ as the repository/placehoder for the NEW firmaware which the AppleBCMWLANCompanion.kext needs/loads to make all this new WiFi magic come to life.

 

Greetings Henties  

[schrup21]

22 hours ago, Mieze said:

DMA buffers must be properly mapped by the IOMMU to allow DMA access by the NIC

Thank you very much for explaining!

So could it be, that Tahoe "expects" some reserved memory regions that aren't there? In other words, we are using our machine's DMAR.aml (maybe patched) - but a real MAC has it's own DMAR, containing reservations that are different of ours.

Or is the DMA buffers mapping not connected to DMAR at all?

[deeveedee]

@schrup21 I did look at the DMAR table from a real MacMini8,1 when I was looking at this for my hack.  Maybe something in this thread will give you ideas.

[FirstCustomac]

As far as I can remember, AppleVTD was also broken with some systems with macOS Ventura 13.3 back then, but @Casey_S.J. came up with the patch to fix it. Perhaps, we need something like this patch for macOS Tahoe?

[deeveedee]

@FirstCustomac Could be. His patch is now kernel quirk DisableIoMapperMapping.

[Mac Hosehead]

I got this working with a BCM943602CS on my Z390. I already had an adapter card but it only had two antennas so I drilled a hole and added a third. It seems to work very nice. Sadly, it now restarts before sleep. I will give up sleep for now and see how things go.

[schrup21]

To all BCMC users: My update to Tahoe 26.1 Beta 2 has now stalled for the second time in the first phase (i.e., after it was loaded and prepared, after the reboot). Shortly after the installer started, there was no SSD activity (for several minutes).

 

The first time this happened, the update continued after a reboot. However, after that, my Wi-Fi card was somehow blocked (it only worked again after a full shutdown).

 

Today the same thing happened, but this time the reboot didn't help; Installer stalled again. So I disabled my Wi-Fi module in the BIOS, and the update completed. After completing the first phase, I re-enabled the Wi-Fi module, and the Wi-Fi worked after the update was complete.

 

It may have been just a coincidence and had nothing to do with BCMC at all—I didn't have Verbose enabled, so I'm not sure.

[jlrycm]

5 minutes ago, schrup21 said:

To all BCMC users: My update to Tahoe 26.1 Beta 2 has now stalled for the second time in the first phase (i.e., after it was loaded and prepared, after the reboot). Shortly after the installer started, there was no SSD activity (for several minutes).

 

The first time this happened, the update continued after a reboot. However, after that, my Wi-Fi card was somehow blocked (it only worked again after a full shutdown).

 

Today the same thing happened, but this time the reboot didn't help; Installer stalled again. So I disabled my Wi-Fi module in the BIOS, and the update completed. After completing the first phase, I re-enabled the Wi-Fi module, and the Wi-Fi worked after the update was complete.

 

It may have been just a coincidence and had nothing to do with BCMC at all—I didn't have Verbose enabled, so I'm not sure.

@schrup21 For your motherboard, how did you disable the wifi module in BIOS?

Edited October 12, 2025 by jlrycm

[schrup21]

@jlrycm

It's a Laptop - there's a switch for that

 

 

[jlrycm]

@Austere.J how does having bcmc-srom-slide defined in Device Properties for a bcm43602CS card to specify the offset into SPROM area where the chip SROM is stored can prevent kernel panics?

Edited October 12, 2025 by jlrycm

[jlrycm]

5 hours ago, schrup21 said:

To all BCMC users: My update to Tahoe 26.1 Beta 2 has now stalled for the second time in the first phase (i.e., after it was loaded and prepared, after the reboot). Shortly after the installer started, there was no SSD activity (for several minutes).

 

The first time this happened, the update continued after a reboot. However, after that, my Wi-Fi card was somehow blocked (it only worked again after a full shutdown).

 

Today the same thing happened, but this time the reboot didn't help; Installer stalled again. So I disabled my Wi-Fi module in the BIOS, and the update completed. After completing the first phase, I re-enabled the Wi-Fi module, and the Wi-Fi worked after the update was complete.

 

It may have been just a coincidence and had nothing to do with BCMC at all—I didn't have Verbose enabled, so I'm not sure.

@schrup21 and everyone else: I installed last night the BCM43602CS card after receiving a PCI-e adapter and today I booted Tahoe and got the latest beta installed and experienced exactly the same issue you reported here. I had to boot in Sequoia, disable the AppleBCMWLANCompanion.kext in the config file and reboot to be able to finish the Tahoe 26.1 beta 2 installation. It seems like the installer does not like the AppleBCMWLANCompanion.kext 🤔

Edited October 12, 2025 by jlrycm

[Mac Hosehead]

9 hours ago, jlrycm said:

It seems like the installer does not like the AppleBCMWLANCompanion.kext

This doesn't appear to be a Beta issue and for me it's looking like the BCM kext will have to be disable/enabled for any installs or updates. At least in Tahoe, anyway. I think it needs internet access while making the installer.

Edited October 13, 2025 by Mac Hosehead