<< Solved >> Airdrop Ok - Handoff Not

[Edhawk]

@BillG66 with a natively supported Apple Broadcom WiFi/BT card you shouldn't need to use any additional kexts, boot arguments or to disable SIP. The whole idea of using a native Broadcom card is so it works out of the box.

You don't need to set Kernel > Quirks > ExtendBTFeatureFlags to True, either.

None of my hacks, all of which use native Apple Broadcom WiFi/BT cards on PCie adapters, require any additional boot arguments, quirks or kexts. This allows the WiFi and Bluetooth to work in macOS, from Yosemite to Ventura.

The only kext I choose to use is AirportBrcmFixup.kext. I use this kext so I can correct the Country Code for a couple of my systems, which insist on using the DE country Code, in place of the GB code my router & access point use. So this kext and the brcmfx-country=GB boot argument are all I have ever required for my Broadcom WiFi/BT cards to work.

GitHub - acidanthera/AirportBrcmFixup: An open source kernel extension providing a set of patches required for non-native Airport Broadcom Wi-Fi cards.

An open source kernel extension providing a set of patches required for non-native Airport Broadcom Wi-Fi cards. - acidanthera/AirportBrcmFixup

github.com

I would recommend removing any and all kexts and boot arguments, except AirportBrcmFixup.kext if you need it.

I would also recommend resetting any quirks and SIP to their default settings, i.e. False and Enabled respectively.

Then reset your Network devices, by deleting /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist



The plist will automatically be regenerated by the OS when it next boots.

You may need to delete the Network devices from the System Preferences > Network pane, if the Ethernet, WiFi and Bluetooth devices are not using the correct BSSID, i.e. en0 for Ethernet, en1/2 for WiFi/BT.

The System Preferences changed to System Settings in Ventura, and this newer OS requires a slightly different method for deleting the Network devices than simply clicking the '-' button below the list of Network devices.

After doing the above ensure you reboot your system and that you reset Nvram from the OC boot screen. Make sure your system reboots after using the ResetNvram.efi tool, it should do so automatically.

You may if you are dual booting need to enter the Bios to reset the disk boot order, as resetting Nvram can wipe the existing boot order, placing Windows Boot Manager as the first boot disk. But this all depends on how you have your OC config.plist configured.

Setting Misc > Boot > LauncherPath to Full (the standard entry is 'Default') stops this from happening.

As this config entry adds an option named 'OpenCore' to your Bios, which once selected tends to remain as the first boot option even after a Nvram reset.

 

[BillG66]

Thanks, @Edhawk. When I booted without ANY kexts, the system recognized the card, but Bluetooth was not enabled. In another thread, it was suggested that I try BlueToolFixup.kext, but I'm not 100% convinced that wasn't just activating the onboard Bluetooth. I'll give all your suggestions above a shot and then report back. Thanks.

 

[BillG66]

@Edhawk To be clear, you recommend deleting all of these boot-args?

-v keepsyms=1 debug=0x100 alcid=1

 

[UtterDisbelief]

... but I'm not 100% convinced that wasn't just activating the onboard Bluetooth. I'll give all your suggestions above a shot and then report back. Thanks.

I told you over on the other thread to disable IntelBluetoothFirmware.kext and IntelBluetoothInjector to disable Intel Bluetooth. Intel BT will not work without them, so it is a good way to make it invisible. I mentioned that you might still need BlueToolFixup.kext, even for Broadcom, depending on which version of macOS you were using. That turned out to be Ventura.

What @Edhawk explained is spot-on.

@Edhawk To be clear, you recommend deleting all of these boot-args?

-v keepsyms=1 debug=0x100 alcid=1

I would say keep them. I don't think Ed said to remove those. They will not affect Intel BT or Broadcom.

 

[BillG66]

@Edhawk So, I followed all of those steps, and now no Bluetooth. I had to manually add Ethernet back as a service, but it's back, and WiFi is showing weird... USB 10/100/1000 LAN, but it's active.

Any thoughts on what I might try next?

 

[BillG66]

@UtterDisbelief Sorry, I missed the second part of your post when I first read it. Okay, I've added the boot args back. So, do I use BlueToolFixup.kext AND AirportBrcmFixup.kext? I've already deleted IntelBluetoothFirmware.kext and IntelBluetoothInjector.kext.

 

[Edhawk]

You don't need BlueToolFixup.kext.

Your Bluetooth module not working is probably down to the USB port the Bluetooth connects through not being activated in your USBPorts.kext.

 

[Edhawk]

@Edhawk To be clear, you recommend deleting all of these boot-args?

-v keepsyms=1 debug=0x100 alcid=1

No, you do not need to delete any of those Boot Arguments. As @UtterDisbelief said they are not related to your Bluetooth in any way shape or form.

The first three are related to being able to see and read the verbose text on boot, if the system KP's.
The fourth injects the layout-id for your Realtek audio codec.

 

[BillG66]

You don't need BlueToolFixup.kext.

Your Bluetooth module not working is probably down to the USB port the Bluetooth connects through not being activated in your USBPorts.kext.

So, and I apologize if this is a stupid question, but if that were the case, wouldn’t the WiFi not work? It’s the same card, so wouldn’t it be using the same USB port? I can go back into Windows and repeat port discovery if that isn’t the case.

 

[Feartech]

So, and I apologize if this is a stupid question, but if that were the case, wouldn’t the WiFi not work? It’s the same card, so wouldn’t it be using the same USB port? I can go back into Windows and repeat port discovery if that isn’t the case.

bluetooth uses the usb port