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

[kgp]

1 hour ago, spakk said:

Hi @ll,

 

which Broadcom WiFi-chipsets, such as the mentioned and possible BCM743602CS (?), are actually supported by macOS Tahoe? I am currently not sure whether this specific chip is compatible. It would be extremely helpful to have an overview of the Broadcom models that are fully functional as well as those that could potentially be supported. Such a list could give developers a clear direction and inspire new initiatives.

 

I only follow the discussions here occasionally, so I would appreciate knowing which Wi Fi chipsets have already been successfully used with macOS Tahoe, which ones worked well in the past, and which ones are now unfortunately no longer allowed to enter the wide world of macOS Tahoe.

 

 

 

Hi @spakk, BCM743602CS was a typo by the user. Widely used for BCMC under Tahoe are the BCM943602CS and BCM943602CDP. You can use them also with OCLP under Sequoia and Sonoma without restrictions or limitations. Following this link you will find all necessary details about BCMC:

 

https://github.com/0xFireWolf/AppleBCMWLANCompanion

 

No support of Broadcom BCM94360 (e.g. Fenvi) by BCMC! No OLCP for Tahoe yet!

 

Current limitations when using BCMC under Tahoe:

 

1.) No AWDL support

2.) Sleep/Wake is broken

3.) Sporadic and random KPs at least on my system and with my system configuration

4.) Regarding ethernet connectivity:  BCMC requires DisableIOMapper=false, i.e. AppleVTD enabled! Note that there are currently issues with the Lucy Kext Family under Tahoe with AppleVTD enabled. A solution by the respective developer is on the way. Instead of InteLucy, one can successfully use Apple's native DEXT Driver under Tahoe. 

5.) Corrupt "PCI" information under "System Information" with AppleBCMWLANCompanion.kext enabled in the config.plist, again at least on my system and with my system configuration. 

 

Hope this helps somehow...

 

Cheers, KGP

Edited November 20, 2025 by KGP-iMacPro

[kgp]

1 hour ago, eSaF said:

@spakk Good day Bro, unfortunately as you know there is no Broadcom Card that will give you both Wifi and Ethernet connection in Tahoe.

 

Bro, BCM943602CS and BCM943602CDP are also BroadCoM=BCM 😉.. WIFI and ethernet are anyway decoupled from each other..

Edited November 20, 2025 by KGP-iMacPro

[cfmwan]

希望对你有用兄弟

32分鐘前，spakk說：

谢谢你提供的信息，兄弟。

 

我不是想显得比我更重要，但我正在与Realtek RTL8111项目并行研究几个Broadcom WiFi驱动程序。我不能确定这些司机最终是否会完全发挥作用。

通用Broadcom WiFi驱动程序框架的第一个原型即将完成。但我无法测试它，因为我没有Broadcom USB WiFi适配器或PCI卡。

我构建了自己的分析工具，帮助我研究驱动程序结构、固件加载过程以及重要的IORegistry和PCI配置数据。对于真正的测试，我没有官方的付费苹果开发者证书。我只能使用我的私人证书，这不能保证驱动程序会在所有系统上正常工作。

 

这就是为什么我想知道哪些Broadcom型号现在有效，哪些型号只能部分有效，哪些型号不再受支持。我还想知道哪些功能在部分工作的芯片上工作，例如，如果只运行基本的WiFi功能，或者是否缺少Handoff、AirDrop、WiFi定位服务等功能，或802点11 ac或802点11 ax等现代标准。

同样重要的是，苹果将整个WiFi软件堆栈保持封闭和私密。这包括内核扩展、固件加载器和原始源代码。如果没有访问这些内部部分，就没有办法理解更深层次的实施。逆向工程或使用受保护的苹果库也可能导致法律问题。

 

这就是为什么对开发人员来说，一个有效的和不工作的Broadcom芯片的明确列表非常重要，以了解哪些开发路径是现实的和可行的。
 

I hope it will be useful to you, bro! I wish you a smooth development!

[deeveedee]

39 minutes ago, spakk said:

The first prototype of a universal Broadcom WiFi-driver framework is almost finished. 

 

Sounds ambitious!  Are you working with Austere_J or is this an indepdendent project?  If independent, how does it differ from Austere_J's proposed solution?

[acquarius13]

@spakk I agree with @deeveedee: it sounds ambitious and I'll be glad to stay updated about your project! 

[Austere.J]

BCMC 1.1.0 Beta was released: https://github.com/0xFireWolf/AppleBCMWLANCompanion/releases/tag/v1.1.0

 

If AppleVTD is incompatible with your platform (e.g., AMD platforms and certain Intel motherboards) or with other 3rd-party drivers you are using,

you can now turn off VT-d and use the new device property "bcmc-disable-io-mapper" to disable the use of IOMapper in the Wi-Fi driver. 

 

Note that this device property comes at the cost of increased memory footprint and degraded network speed.

Please refer to the manual for details: https://github.com/0xFireWolf/AppleBCMWLANCompanion/blob/main/Documentation/DeviceProperties.md#iommu-and-applevtd

 

You can test this new device property by downloading files and verifying its checksum.

[deeveedee]

@Austere.J You indicate this in your known issues: "Upgrading to a new macOS Tahoe release with BCMC enabled causes a kernel panic during the final OTA stage, because Lilu mistakenly recognizes the final OTA stage as a normal boot"

 

Is this a bug fix that we should expect to see in Lilu.kext?

 

... and thank you for your hard work on this project!

Edited November 21, 2025 by deeveedee

[Austere.J]

10 minutes ago, deeveedee said:

@Austere.J You indicate this in your known issues: "Upgrading to a new macOS Tahoe release with BCMC enabled causes a kernel panic during the final OTA stage, because Lilu mistakenly recognizes the final OTA stage as a normal boot"

 

Is this a bug fix that we should expect to see in Lilu.kext?

 

... and thank you for your hard work on this project!

 

Ideally, we should expect to see this issue fixed in Lilu, as WhateverGreen also suffers from the same problem (https://github.com/acidanthera/WhateverGreen/pull/124 and https://github.com/acidanthera/WhateverGreen/pull/126).

However, I think the root cause is deeper and might be related to Lilu's patching the kexts bundled in BaseSystemKernelExtensions.kc which is used by the final OTA stage.

The crash or kernel panic observed and reported by other forum members early is very likely the same as the Invalid Opcode reported by royalgraphx (pull/124).

[jlrycm]

1 hour ago, Austere.J said:

BCMC 1.1.0 Beta was released: https://github.com/0xFireWolf/AppleBCMWLANCompanion/releases/tag/v1.1.0

 

If AppleVTD is incompatible with your platform (e.g., AMD platforms and certain Intel motherboards) or with other 3rd-party drivers you are using,

you can now turn off VT-d and use the new device property "bcmc-disable-io-mapper" to disable the use of IOMapper in the Wi-Fi driver. 

 

Note that this device property comes at the cost of increased memory footprint and degraded network speed.

Please refer to the manual for details: https://github.com/0xFireWolf/AppleBCMWLANCompanion/blob/main/Documentation/DeviceProperties.md#iommu-and-applevtd

 

You can test this new device property by downloading files and verifying its checksum.

@Austere.J thanks for the update and the great work! The sleep issues are not fixed, right? I imagine it takes more time to get it fixed. Or you were able to fix it? I don’t see any reference to the sleep panic in the known issues and I remember seeing that there before.

Edited November 21, 2025 by jlrycm

[Austere.J]

Just now, jlrycm said:

@Austere.J thanks for the update and the great work! The sleep issues are not fixed, right? I imagine it takes more time to get it fixed.

 

Not yet. Currently, I no longer have kernel panics when putting my desktop to sleep, but the Wi-Fi chip no longer responds when I wake it up and the driver triggers another kernel panic.

Once I conclude that the power management routines in the native Wi-Fi driver are not compatible with legacy Wi-Fi chips (which is very likely), I will try to override Apple's implementation.

[Austere.J]

9 minutes ago, jlrycm said:

@Austere.J I don’t see any reference to the sleep panic in the known issues and I remember seeing that there before.

 

It's still there: https://github.com/0xFireWolf/AppleBCMWLANCompanion/blob/main/Documentation/Issues.md#power-management

[jlrycm]

5 minutes ago, Austere.J said:

 

It's still there: https://github.com/0xFireWolf/AppleBCMWLANCompanion/blob/main/Documentation/Issues.md#power-management

Thanks for correcting me. My eyes skipped this one in hope that it was fixed. 

11 minutes ago, Austere.J said:

 

Not yet. Currently, I no longer have kernel panics when putting my desktop to sleep, but the Wi-Fi chip no longer responds when I wake it up and the driver triggers another kernel panic.

Once I conclude that the power management routines in the native Wi-Fi driver are not compatible with legacy Wi-Fi chips (which is very likely), I will try to override Apple's implementation.

Thank you for the great work. My WiFi works well except for the sleep issue. 

[Mieze]

31 minutes ago, Austere.J said:

 

Not yet. Currently, I no longer have kernel panics when putting my desktop to sleep, but the Wi-Fi chip no longer responds when I wake it up and the driver triggers another kernel panic.

That's the minor evil compared to a KP! Great work, keep going. I'm going to supply the AppleVTD compatible Ethernet drivers.

 

Mieze 😺

[jlrycm]

2 hours ago, Austere.J said:

Not yet. Currently, I no longer have kernel panics when putting my desktop to sleep, but the Wi-Fi chip no longer responds when I wake it up and the driver triggers another kernel panic.

@Austere.J Do you have the kernel panic even if you turn off the wifi in Settings prior to the desktop going to sleep?

Edited November 21, 2025 by jlrycm

[cfmwan]

14 minutes ago, spakk said:

A significant progress in DEXT building: I am now able to generate almost any DEXT driver structure. I have finally identified the correct approach. It was a several-day fight against the complex logic, but the first stage is successfully completed.

 

Writing the actual code is still a separate challenge, and I am currently working on it. For functional testing, I will also need to acquire some Broadcom PCI adapter cards to read and analyze them. I am confident that I will overcome this challenge as well.

 

The goal is to make these cards fully functional. So far, the cards have only worked partially:

 

Vendor ID | Device ID | Chipset.          | Notes
14e4.         | 43a0        | BCM4360       | Partially supported – basic Wi Fi works with patches. I will buy one of these two because if it communicates, it will be easier to get the other compatible cards working.
14e4.         | 43b1        | BCM43602      | Experimental – AWDL is unstable. This one is more challenging.
14e4.         | 43a3       | BCM4352         | Patch dependent.
14e4.         | 43ba       | BCM94360CD | Natively stable, Apple branded.

 

The next development phase will focus on establishing reliable communication for these cards and improving the stability of the drivers.

 

This is exciting news! Come on, brother! Wish you all the best!

[kgp]

3 hours ago, spakk said:

A significant progress in DEXT building: I am now able to generate almost any DEXT driver structure. I have finally identified the correct approach. It was a several-day fight against the complex logic, but the first stage is successfully completed.

 

Writing the actual code is still a separate challenge, and I am currently working on it. For functional testing, I will also need to acquire some Broadcom PCI adapter cards to read and analyze them. I am confident that I will overcome this challenge as well.

 

The goal is to make these cards fully functional. So far, the cards have only worked partially:

 

Vendor ID | Device ID | Chipset.          | Notes
14e4.         | 43a0        | BCM4360       | Partially supported – basic Wi Fi works with patches. I will buy one of these two because if it communicates, it will be easier to get the other compatible cards working.
14e4.         | 43b1        | BCM43602      | Experimental – AWDL is unstable. This one is more challenging.
14e4.         | 43a3       | BCM4352         | Patch dependent.
14e4.         | 43ba       | BCM94360CD | Natively stable, Apple branded.

 

The next development phase will focus on establishing reliable communication for these cards and improving the stability of the drivers.

 

 

That's absolutely gorgeous! I also wish you all the best.

 

I am only a bit confused about some of the Device IDs you are mentioning:

BCM43602 (CDP and CS) usually has Device ID 0x43BA

BCM94360CD usually has Device ID 0x43A0

 

None of the BCM94360-based cards use 0x43BA:

BCM94360CS usually has Device ID 0x43A0

BCM94360CS2 usually has Device ID 0x43A1

 

All the best for your journey! 

Edited November 25, 2025 by KGP-iMacPro

[Max.1974]

Hi @spakk my friend!! Great initiative — congratulations! 

 

I would like to join the project as a supporter.
My current knowledge in networking and driver development is not very advanced, but I can contribute effectively as a tester: running builds, performing real-world tests, collecting logs, reproducing issues, and sending detailed bug reports to help with debugging.

 

I have solid experience working with macOS systems, installing kexts/dexts, analyzing basic logs, and testing different hardware setups. I can run experimental builds, validate behavior on real hardware, and report any regressions or instability. If this is useful for the team, I’m available to participate in the testing cycle and provide continuous feedback throughout the development process. 

 

[Max.1974]

Thanks my friend!!  

 

Good Lucky 

[Austere.J]

13 hours ago, spakk said:

A significant progress in DEXT building: I am now able to generate almost any DEXT driver structure. I have finally identified the correct approach. It was a several-day fight against the complex logic, but the first stage is successfully completed.

 

Writing the actual code is still a separate challenge, and I am currently working on it. For functional testing, I will also need to acquire some Broadcom PCI adapter cards to read and analyze them. I am confident that I will overcome this challenge as well.

 

The goal is to make these cards fully functional. So far, the cards have only worked partially:

 

Vendor ID | Device ID | Chipset.          | Notes
14e4.         | 43a0        | BCM4360       | Partially supported – basic Wi Fi works with patches. I will buy one of these two because if it communicates, it will be easier to get the other compatible cards working.
14e4.         | 43b1        | BCM43602      | Experimental – AWDL is unstable. This one is more challenging.
14e4.         | 43a3       | BCM4352         | Patch dependent.
14e4.         | 43ba       | BCM94360CD | Natively stable, Apple branded.

 

The next development phase will focus on establishing reliable communication for these cards and improving the stability of the drivers.

 

 

8 hours ago, spakk said:

Yes, sorry, that’s a silly typing mistake on my part. 😞

 

Edit:

I would like to explain this clearly and unambiguously:

 

Case study in focus:

We have presented two options. The central point of contention is the assignment of device IDs to Broadcom WLAN cards.

 

The crucial question:

 

Does the BCM94360CD card have the device ID 0x43BA or 0x43A0?

 

The definitively correct answer is:

 

The correct answer is that the BCM94360CD has the device ID 0x43A0, and not, as I wrote above, 0x43BA for BCM94360CD. That is incorrect.

 

Technical background:

 

• Broadcom chipsets are used in various Mini-PCIe cards (such as BCM94360CD, CS, CS2).

• The device ID is a number that is read by the operating system (e.g., Windows, Linux, macOS) via PCIe.

• Each card receives its own unique ID. This ID is determined not only by the chipset but also by the physical form factor(e.g., the firmware version and any additional chips included).
• BCM43602 is a chipset also found in the BCM9443602CDP and third-party cards with the ID 0x43BA.
• The ID 0x43BA does not belong to the BCM94360CD.

 

Fact Check (Correct Information)

 

| Designation | Chipset | Device ID (PCIe) | Notes

|———————————|———————-—|—————————————

| BCM94360CD              | BCM4352/60       | 0x43A0  | Excellent performance under macOS

| BCM94360CS              | BCM4352/60      | 0x43A0  | Identical to CD

| BCM94360CS2            | BCM4352/60      | 0x43A1    | Highly compatible

| BCM943602CDP/CS.  | BCM43602          | 0x43BA   | Better AWDL support

 

What was wrong:

 

My statement "BCM94360CD has the device ID 0x43BA" is incorrect.

 

Why do AI's claim different things?

 

• AIs are often trained with too little context.
• They rely on inaccurate or inconsistent data sources.
• Technical details like these are particularly prone to confusion between cards, chipsets,

          and IDs, and I unfortunately fell for it because I didn't read the datasheets.

 

6 hours ago, spakk said:

Hi @ll

 

What We Urgently Need Is a WLAN-Driver-Development-Team for macOS

 

Why This Is a Highly Complex Topic?

 

Developing WLAN-drivers for macOS is technically challenging due to several architectural, security-related, and organizational barriers. 
Over recent years, Apple has significantly changed its driver model: traditional kernel extensions (kexts) are becoming obsolete, replaced 
by DriverKit-based system extensions (DEXTs / "dext"). This shift affects the viability and complexity of driver projects considerably.

 

Core Problems and Technical Pitfalls

 

    1. Transition from Kexts to DriverKit (DEXTs)

        What changed: Many tasks that used to be performed in the kernel (kexts) must now be handled in user-space drivers through DriverKit. 
        DEXT drivers run as system extensions and have restricted access to the kernel by design, which improves security but limits low-level 
        operations. Consequence: Tasks requiring full kernel access, such as high-performance I/O or direct manipulation of network layers, need redesigning 
        or reimplementing. Older techniques from kexts often cannot be directly ported to DriverKit.

 

    2. Limited APIs and Sandboxing

        Limitations: DriverKit intentionally avoids direct control over filesystems, certain networking APIs, and key kernel resources. Interprocess 
        communication, permissions, and signature enforcement are stricter, requiring extra components like client apps, XPC services, or Network 
        Extensions. This increases complexity and development overhead.

 

    3. AWDL, Continuity and Apple Proprietary Logic

        AWDL Challenges: Apple's proprietary features such as AirDrop, Handoff, and Continuity rely on tight integration with macOS Wi-Fi drivers via 
        AWDL protocol. Misconfigurations in AWDL can cause instability, interference, or unexpected behavior. It's also difficult to test or modify 
        these proprietary elements. User reports confirm that AWDL-related issues persist even in newer macOS releases.

 

    4. Hardware and Firmware Heterogeneity

        Chipset vs Card: The PCI device ID identifies the physical card, not just the Broadcom chip. Differences in firmware, radio frontends, antenna 
        layouts, and co-processors affect performance and compatibility, leading to unique behaviors for each card. For example, various BCM94xxx cards 
        may use similar chips but require individual code handling due to differing PCI IDs and firmware versions.

 

    5. Code Signing, Notarization and Deployment

        Apple Enforces Strict Policies: Apple now requires all system extensions and drivers on modern macOS to be signed and notarized. This process 
        complicates distribution, particularly for open-source teams and third-party developers. It extends release timelines and makes builds more prone 
        to errors.

 

Organizational Challenges Why We Need a Team

 

Diverse Skill Sets Required: A successful project requires expertise in kernel/driver development, macOS system architecture, C++/Objective-C/Swift 
programming, DriverKit experience, firmware analysis, testing infrastructure, and legal compliance with certificate management.

 

Extensive Testing Needed: Real-world testing across diverse hardware and software configurations is very resource-intensive. An individual contributor 
typically can’t maintain a broad enough test environment.

 

Security and Reliability Are Critical: Even small bugs can lead to system-wide instability. Formal review processes, code audits, and structured bug 
tracking are essential.

 

Documentation and User Support Matter: Users need installation tools, troubleshooting guides, proper logging, and clear instructions. Without them, 
projects fragment into unsupported forks and unofficial fixes.

 

Proposed Team Structure

    1. Lead Architect (Driver/Kernel) - Oversees the driver design and decides whether to use kext or dext approaches.
    2. DriverKit Developer - Implements and maintains DEXT components and communicates with userspace applications.
    3. Firmware/Hardware Engineer - Tests actual cards, verifies PCI IDs, examines firmware behavior.
    4. QA Tester - Runs automated and manual tests across a wide range of hardware and OS versions.
    5. Release Manager / DevOps & Security - Manages code signing, notarization, CI/CD pipelines, and backup procedures.
    6. Project Manager / Technical Writer - Ensures smooth coordination and documentation across the team.

 

If You’re Not a Developer: How You Can Still Help

 

You don’t need to be a programmer to contribute meaningfully. Suggested non-developer roles include:

    - Product Owner: Define user requirements and prioritize features.
    - Tester and Bug Reporter: Reproduce issues, collect logs, write clear bug reports.
    - Documentation Contributor: Write installation guides, FAQs, or create support scripts.
  
Self-awareness Helps: Honesty about your technical level and what you can offer prevents misunderstandings and sets clear expectations. 
Keep in mind that driver development is a shared effort with long-term goals that take time to achieve.

 

Reflection on Progress So Far

 

I believe I’ve made important early progress with tangible value:

 

    - Designed and implemented the basic DEXT framework. This is a major first step showing understanding of Apple’s preferred driver model.
    - Built a working prototype using simulated logic. This proves the concept before real hardware interaction begins, making it easier to onboard 
     other developers and test the integration process.

 

Key Risks and Common Problems Ahead

    - Limitations in DriverKit might block low-level functionality.
    - AWDL interactions could affect connection reliability or TCP/UDP performance.
    - Device ID or firmware version differences might cause regressions on some hardware.
    - Changes in Apple’s security model or signing practices can cause delays or break compatibility.
    - Lack of well-defined testing environments across multiple Mac models, firmware versions, access points, and networks.

 

Suggested Action Plan High Level Overview

    1. Start and Clarify Project Objectives: Identify target use cases, compatible cards, and lowest-supported macOS version.

    2. Build a Minimum Team: Assign core responsibilities to team members with relevant skills.

    3. Expand Proof of Concept: Move from simulation to real hardware interaction, step by step.

    4. Implement and Test Iteratively: Regular small updates, structured testing, and continuous feedback.

    5. Prepare for Signing and Installation: Work towards full Apple notarization while preparing installers and rollback procedures.

    6. Enter Beta Phase with Support Framework: Clear instructions, stable builds, and reliable update pathway.

 

Final Thoughts Realistic But Optimistic

 

My journey toward building a complete and functional driver is still long, but I've completed some of the most difficult foundational steps: understanding 
Apple's ecosystem, setting up the correct DEXT structure, and proving feasibility with proof-of-concept code.

 

To overcome the remaining obstacles, we’ll need a committed, multidisciplinary team and a planned approach. With a solid foundation, iterative development, 
and strict focus on testing and user support, we can deliver a signed, safe, and well-integrated WLAN driver for macOS. But let’s be clear: this is not a solo weekend job.

 
what do you all mean?

 

It's great to see someone else interested in developing Wi-Fi drivers for Tahoe. However, after carefully reading your recent posts in this thread and the DEXT prototype you published in 

I'm wondering if you generated the posts and the prototype using an LLM.

 

Your device table in the first two posts doesn't make sense. The device identifiers don't match their chipsets, and the notes contradict each other.

If I remember correctly, you mentioned you didn't have Broadcom Wi-Fi cards and asked for their details in your previous post.

As such, how did you conclude that, for example, BCM43602 has better AWDL support while AWDL is unstable?

 

Your third post (that calls for a development team) covers a lot of relevant topics.

The coverage is comprehensive but only surface-level, which is what LLMs often do when no in-depth instructions are provided.

 

You uploaded a repo in your latest post. I downloaded it but couldn't find an Xcode project file.

Xcode provides templates for developing applications/services/extensions running on Apple platforms and handles all the build system and code signing work.

Your `BCMWiFiDriver` class inherits from `IOUserNetworkController`, which does not even exist, and is defined in a C++ header file, but DriverKit-based drivers use IIG header files.

Your source files contain pseudocode and comments possibly left by the LLM asking you to replace the pseudocode with the actual DriverKit API calls.

And there is no such C++ namespace called "DriverKit".

 

I was excited to see someone else interested in Wi-Fi drivers, but what I have observed so far completely deflated that excitement.

Edited November 25, 2025 by Austere.J

[spakk]

1 hour ago, Austere.J said:

 

 

 

It's great to see someone else interested in developing Wi-Fi drivers for Tahoe. However, after carefully reading your recent posts in this thread and the DEXT prototype you published in 

I'm wondering if you generated the posts and the prototype using an LLM.

 

Your device table in the first two posts doesn't make sense. The device identifiers don't match their chipsets, and the notes contradict each other.

If I remember correctly, you mentioned you didn't have Broadcom Wi-Fi cards and asked for their details in your previous post.

As such, how did you conclude that, for example, BCM43602 has better AWDL support while AWDL is unstable?

 

Your third post (that calls for a development team) covers a lot of relevant topics.

The coverage is comprehensive but only surface-level, which is what LLMs often do when no in-depth instructions are provided.

 

You uploaded a repo in your latest post. I downloaded it but couldn't find an Xcode project file.

Xcode provides templates for developing applications/services/extensions running on Apple platforms and handles all the build system and code signing work.

Your `BCMWiFiDriver` class inherits from `IOUserNetworkController`, which does not even exist, and is defined in a C++ header file, but DriverKit-based drivers use IIG header files.

Your source files contain pseudocode and comments possibly left by the LLM asking you to replace the pseudocode with the actual DriverKit API calls.

And there is no such C++ namespace called "DriverKit".

 

I was excited to see someone else interested in Wi-Fi drivers, but what I have observed so far completely deflated that excitement.

Hi @Austere.J    

 

I've never made a secret of the fact that I'm not a programmer! I've never claimed otherwise anywhere in the forum! The reason I didn't include any technical details in my post is simply that it's not my area of expertise. I just wanted to outline the problems I'd encountered and offer suggestions for collaboration. If I had the necessary knowledge, I wouldn't be sitting here writing posts like this with you, only to be attacked.

 

Broadcom Wi-Fi cards have specific requirements and firmware that are often proprietary. Therefore, it's difficult to develop open-source drivers for them without access to this information. This is one reason why creating a working driver is challenging.

 

Regarding AWDL support: This is based on information from other users that AWDL is a protocol developed by Apple and that there's very little publicly available information about it.

 

Regarding my repository and the missing Xcode project file... All I can say is, those who can read are clearly at an advantage, because then you would have gathered from the text that I don't work with Xcode and that I deliberately avoided the annoying problems Xcode constantly causes, instead building the project with a Makefile. The basic framework can easily be built with it! And the content was clearly described in my text, which stated that there are many placeholders in the code. I didn't mean to confuse anyone. If someone wants to create an Xcode project, that's no problem; it can be done in a few moments, but I personally don't enjoy working with it.

I'm sorry if I dampened your enthusiasm.

My goal was to show a way, not to deliver a finished product. Whether I use AI isn't an issue; I could have retouched it so it wouldn't look like AI, but that's not important to me!

[Austere.J]

7 minutes ago, spakk said:

Hi @Austere.J    

 

I've never made a secret of the fact that I'm not a programmer! I've never claimed otherwise anywhere in the forum! The reason I didn't include any technical details in my post is simply that it's not my area of expertise. I just wanted to outline the problems I'd encountered and offer suggestions for collaboration. If I had the necessary knowledge, I wouldn't be sitting here writing posts like this with you, only to be attacked.

 

Broadcom Wi-Fi cards have specific requirements and firmware that are often proprietary. Therefore, it's difficult to develop open-source drivers for them without access to this information. This is one reason why creating a working driver is challenging.

 

Regarding AWDL support: This is based on information from other users that AWDL is a protocol developed by Apple and that there's very little publicly available information about it.

 

Regarding my repository and the missing Xcode project file... All I can say is, those who can read are clearly at an advantage, because then you would have gathered from the text that I don't work with Xcode and that I deliberately avoided the annoying problems Xcode constantly causes, instead building the project with a Makefile. The basic framework can easily be built with it! And the content was clearly described in my text, which stated that there are many placeholders in the code. I didn't mean to confuse anyone. If someone wants to create an Xcode project, that's no problem; it can be done in a few moments, but I personally don't enjoy working with it.

I'm sorry if I dampened your enthusiasm.

My goal was to show a way, not to deliver a finished product. Whether I use AI isn't an issue; I could have retouched it so it wouldn't look like AI, but that's not important to me!

 

Thanks for your detailed response.

First of all, I didn't mean to attack you in any way. I sincerely apologize if my previous post hurt your feelings.

I completely understand that developers might not always want to use Xcode and from your repository that you prefer using Makefiles, and I personally use CLion when working on my projects.

The missing Xcode project file is merely one of the reasons that makes me feel that the posts and prototype were generated by an LLM.

Please note that I'm not complaining about your use of LLM at all.

Instead, as I clearly indicated in my previous post, I am asking whether you were generating these things using an LLM because I found your previous posts confusing and misleading.

[arsradu]

On 11/2/2025 at 4:29 PM, KGP-iMacPro said:

 

What I’m still curious about is whether @Mieze’s RealtekRTL8111.kext works under macOS Tahoe with AppleVTD enabled (DisableIOMapper = False). If it doesn’t, I’d like to know whether there’s a native macOS driver that could take over when RealtekRTL8111.kext is disabled in the config.plist. Up to my knowledge there does not exist any..😉

 

Now I can finally give you an answer on this, since I managed to test it. And nope, it doesn't work. With AppleVTD enabled, I can have WiFi, but Ethernet doesn't work anymore. With it disabled, Ethernet works, but WiFi doesn't work anymore. I saw Mieze already confirmed above. So I guess it's a known issue.

 

Also, I'm guessing that's what the newly added bcmc-disable-io-mapper property is for, right? To disable the use of AppleVTD on driver level, so it doesn't interfere with other drivers (in this case Ethernet driver). But it comes with a cost... At least until Mieze implements a fix on the Realtek8111 driver's side.

[arsradu]

19 hours ago, eSaF said:

Hi, if I may, with my BCM943602CS Card I initially experience exactly the same situation as you described, I could get WIFI with one setting but no Ethernet.

On the other hand, I could get Ethernet but no WIFI. With the new Device Properties entry devised by @Austere.J I can now enjoy both WIFI and Ethernet connections at the same time.

 

Attached are a series of pics of my settings coupled with the created WIFI folder containing the necessary files as advised in the 'How To' manual.

In the BIOS VT-D is Disabled, also note the settings in the config.plist. Sorry if my explanation is a bit vague but hopefully it will contain enough information as is.

  Reveal hidden contents

 

Cheers.

 

Thank you!  

 

I think you only need DisableIOMapper set to True, or, if you don't need VT-D for other OSes, disable it in BIOS. The device properties option does indeed allow us to use both Ethernet and WiFI (with VT-D disabled) but, if I got this right (and I can confirm this part), it comes with a performance cost. Not an issue if you're using Ethernet for most tasks anyway. But if you want higher speeds on WiFi, this might not be the best option.

 

But yeah, now I can have both.  I kept VT-D enabled in BIOS since it might be useful for Windows, which I'm dual booting. But yeah, with DisableIOMapper quirk enabled and bcmc-disable-io-mapper set to true in Device Properties, everything works fine.

 

I'm only curious, has anyone tried to unplug/disconnect their internet connection while WiFi was enabled? I usually get a freeze and need to restart.

[arsradu]

42 minutes ago, eSaF said:

I just removed the Ethernet cable without any problem. 

Internet connection was attained with WIFI only, also in Windows WIFI was maintained.

 

The settings Ethernet and WIFI I mentioned in my previous post works in all 3 macOS versions as well as Windows.

My Internet connection is via fibre optics with a connection speed of 1.5 gb/s.

 

On the worst days (peak time) the speed will drop between 850 mb/s and 900 mb/s.

My only gripe as documented, I have no 'Hand Off to iPhone Camera' wirelessly and no 'Air Drop'.

 

Cheers.

Weird... Sometimes it just freezes... And the download speed difference is significant in my case. From a 300-400Mb/s download speed with VT-D enabled to 80-95Mb/s with it disabled... Interesting that you don't get the same effect... I also got fiber optics internet, but only 1Gb/s advertised in my case. Via Ethernet I can get around 950-970Mb/s download.

 

I'll keep testing this. 

 

Thank you so much for your answer!

[Austere.J]

6 hours ago, arsradu said:

if I got this right (and I can confirm this part), it comes with a performance cost. Not an issue if you're using Ethernet for most tasks anyway. But if you want higher speeds on WiFi, this might not be the best option.

 

Yes, your understanding is correct.

 

Quote

I'm only curious, has anyone tried to unplug/disconnect their internet connection while WiFi was enabled? I usually get a freeze and need to restart.

 

I recall that you have an RTL8168 Ethernet card and you are using RealtekRTL8111? The Ethernet driver handles the interrupts when you unplug the cable. The freeze might be a sign of a kernel panic.