- Joined
- Jul 22, 2018
- Messages
- 8,477
- Motherboard
- Supermicro X11SPA-T
- CPU
- Intel Xeon W-3275 28 Core
- Graphics
- 2xAMD RX 580 8GB
- OS X/macOS
- 13.x
- Bootloader
- OpenCore (UEFI)
- Mac
- Mac mini
- MacBook Pro
- Mobile Phone
- Android
- iOS
How to Fix Bluetooth on macOS Monterey and Later
This guide covers fixing Bluetooth on macOS Monterey and Later using Clover and OpenCore. By following this guide, you'll be able to enable Bluetooth on macOS Monterey and Later using Clover or OpenCore Bootloader.
Background
Recently, we upgraded a build to macOS Monterey 12.6, which was previously deployed with macOS Big Sur 11.6.5. Interestingly, after upgrading to macOS Monterey, we found that BT was available in System Preferences but it was not working. This means no On/Off function, the BT address was NULL and the State was Off. This simply meant that the Bluetooth is either not connected properly or the system is unable to communicate. We were using Broadcom BCM94360NG from Fenvi on this build. As a part of the diagnosis, we changed the card with a new one we had lying and it made no difference. Luckily, we had the exact same build, but a different one with macOS Big Sur, so we swapped the cards, and still a no-go. From this, we concluded that there is no issue with the card but could be the M.2 WiFi Slot or the BIOS. We went further and found that M.2 WiFi Slot and the BIOS were perfect. However, one unusual thing we noticed was under Windows, the WiFi was available, but no Bluetooth. Considering the card firmware was corrupt, we tried to update the firmware but found that the firmware is loading and working up to the mark. Now, it was time to investigate the OS part, under macOS.
Upon doing some quick research over the internet, we came to know that many users are having such issues and mostly with Broadcom where the BT isn't working, but the WiFi is. When doing a firm investigation, we came to know that Big Sur's Bluetooth implementation is different than Monterey and above, and therefore on a newer macOS version, it fails to find firmware for the chipset and due to this BT firmware isn't loaded at startup and therefore does not work. Since macOS Monterey, Apple has changed a lot in terms of the implementation of various peripherals, including Bluetooth. Apple has changed parts of the Bluetooth stack from kernel space to user space and due to this, the issue exists. The issue exists on natively supported cards (Broadcom, including AirPort Cards) and also community supported cards such as Intel. However, a few Broadcom Cards such as Fenvi T919 are an exception and regardless of the macOS version, the BT works with zero issues. We used a few different builds with different specifications. Upon our investigation, we noticed three scenarios which are described below.
Case #1
In this case, the Bluetooth does not have its address (NULL) and the State was Off.
Case #2
In this case, the Bluetooth does have the address and the State On but fails to initialize firmware. The WiFi operation was normal and the USB mapping was implemented. In this case, the firmware was also failing to load. However, when checking for logs, we found that
Case #3
On some systems, even when using all the fixes, the Bluetooth address may appear as NULL. Unless there is a valid Bluetooth address, the Bluetooth will remain in off state as reported by @GrantMBP
Upon checking the bootlog
Solutions
To prevent the Bluetooth issue on macOS Monterey and above, a couple of solutions are available which are described below. Depending on the case, you may need to use either one of the solutions listed below or a combination of them.
I. Implement USB Mapping
Since macOS Big Sur (11.3.x), Apple made some changes to its USB implementation. With the new rewritten drivers, the XhciPortLimit is broken. Although it is always recommended to map the USB ports, it has become mandatory now.
In addition, you need to change the connector type for your Bluetooth USB Port. As macOS always expects Bluetooth as
II. Remove Duplicate Bluetooth
There are a few setups where the Motherboard is usually shipped with an Onboard Intel WiFi/BT Card and to avoid the hassle, several users tend to install a PCIe WiFi/BT Card which is a wrong approach. This is only suitable where the BIOS has the option to disable the Onboard WiFi/BT. For the rest of the cases, where one has no such option, you must disable the unsupported one to avoid conflicts. If it's not possible to remove the hardware (to avoid the risk of damage), you can simply exclude the Bluetooth port on the EHC/XHC Bus. See USB Port Mapping for more information.
However, there are several cases where the Bluetooth is connected to an Internal Hub, and disabling such a port will make the whole hub stop working and as a result, the other devices connected to such port will not work. Therefore, the best approach is to simply remove the unsupported Bluetooth module and replace it with a compatible one. See Bluetooth Compatibility for more information.
III. Bypass Firmware Update Check
In Monterey,
To skip the firmware update check,
However, for this to work properly, the transport must also be properly set (otherwise, the file will be ignored). To determine the transport,
BlueToolFixup forces
¹ BlueToolFixup solely patches BlueTool's firmware update check currently. More work appears to be needed for Intel Bluetooth.
² Not many have been tested currently, and not all features (Continuity) have been tested. This is obviously not required on cards pulled from a Mac, and on cards that are completely native and do not need BrcmPatchRAM (ie. BCM94360NG).
IV. Bypass Address Check
Since macOS 12.4 and newer versions, a new address check has been introduced in
V. Update Bluetooth Firmware
On some systems, the Bluetooth address may still appear as NULL despite using all the above solutions. Unless there is valid Bluetooth firmware, the Bluetooth will remain in the off state as reported by @HG87. You must flash the correct firmware for your Bluetooth device. See Flashing Broadcom Bluetooth Firmware for more information.
Test Results
Following are the test results for various Bluetooth
BCM94360NG
Conclusion
Hence, we can conclude that most of the Broadcom and Intel WiFi/BT Cards under Monterey may not work, even with proper USB Ports Mapping. This solution is also required by natively supported AirPort Cards such as Broadcom BCM94360NG and BCM943602CS. This might be useful for other Broadcom models as well. We can confirm that the above solution completely fixes the Bluetooth issue on macOS Monterey and above.
Reporting
This guide covers fixing Bluetooth on macOS Monterey and Later using Clover and OpenCore. By following this guide, you'll be able to enable Bluetooth on macOS Monterey and Later using Clover or OpenCore Bootloader.
Background
Recently, we upgraded a build to macOS Monterey 12.6, which was previously deployed with macOS Big Sur 11.6.5. Interestingly, after upgrading to macOS Monterey, we found that BT was available in System Preferences but it was not working. This means no On/Off function, the BT address was NULL and the State was Off. This simply meant that the Bluetooth is either not connected properly or the system is unable to communicate. We were using Broadcom BCM94360NG from Fenvi on this build. As a part of the diagnosis, we changed the card with a new one we had lying and it made no difference. Luckily, we had the exact same build, but a different one with macOS Big Sur, so we swapped the cards, and still a no-go. From this, we concluded that there is no issue with the card but could be the M.2 WiFi Slot or the BIOS. We went further and found that M.2 WiFi Slot and the BIOS were perfect. However, one unusual thing we noticed was under Windows, the WiFi was available, but no Bluetooth. Considering the card firmware was corrupt, we tried to update the firmware but found that the firmware is loading and working up to the mark. Now, it was time to investigate the OS part, under macOS.
Upon doing some quick research over the internet, we came to know that many users are having such issues and mostly with Broadcom where the BT isn't working, but the WiFi is. When doing a firm investigation, we came to know that Big Sur's Bluetooth implementation is different than Monterey and above, and therefore on a newer macOS version, it fails to find firmware for the chipset and due to this BT firmware isn't loaded at startup and therefore does not work. Since macOS Monterey, Apple has changed a lot in terms of the implementation of various peripherals, including Bluetooth. Apple has changed parts of the Bluetooth stack from kernel space to user space and due to this, the issue exists. The issue exists on natively supported cards (Broadcom, including AirPort Cards) and also community supported cards such as Intel. However, a few Broadcom Cards such as Fenvi T919 are an exception and regardless of the macOS version, the BT works with zero issues. We used a few different builds with different specifications. Upon our investigation, we noticed three scenarios which are described below.
Case #1
In this case, the Bluetooth does not have its address (NULL) and the State was Off.
Case #2
In this case, the Bluetooth does have the address and the State On but fails to initialize firmware. The WiFi operation was normal and the USB mapping was implemented. In this case, the firmware was also failing to load. However, when checking for logs, we found that
bluetoothd was constantly crashing. You can find the details below.
Code:
Process: bluetoothd [534]
Path: /usr/sbin/bluetoothd
Identifier: bluetoothd
Version: ???
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 0
Date/Time: 2022-09-14 00:59:43.2840 -0400
OS Version: macOS 12.6 (21G115)
Report Version: 12
Anonymous UUID: 8BD1AA41-B687-73EB-AD85-5F89ED23CE95
Sleep/Wake UUID: D418A682-0BCF-46B9-9D99-C0196368945A
Time Awake Since Boot: 4400 seconds
Time Since Wake: 16 seconds
System Integrity Protection: disabled
Crashed Thread: 1 Dispatch queue: com.apple.bluetooth.root
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace LIBSYSTEM, Code 2 Application Triggered Fault
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x7ff81eabc97a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x7ff81eabcce8 mach_msg + 56
2 CoreFoundation 0x7ff81ebc036d __CFRunLoopServiceMachPort + 319
3 CoreFoundation 0x7ff81ebbe9f8 __CFRunLoopRun + 1276
4 CoreFoundation 0x7ff81ebbde3c CFRunLoopRunSpecific + 562
5 CoreFoundation 0x7ff81ec45dcb CFRunLoopRun + 40
6 bluetoothd 0x107abc0c8 0x107aa3000 + 102600
7 dyld 0x1093e452e start + 462
Thread 1 Crashed:: Dispatch queue: com.apple.bluetooth.root
0 libsystem_kernel.dylib 0x7ff81eadfdba __abort_with_payload + 10
1 libsystem_kernel.dylib 0x7ff81eae1877 abort_with_payload_wrapper_internal + 80
2 libsystem_kernel.dylib 0x7ff81eae18a9 abort_with_payload + 9
3 bluetoothd 0x107b180db 0x107aa3000 + 479451
4 bluetoothd 0x107b61c68 0x107aa3000 + 781416
5 bluetoothd 0x107b10bd8 0x107aa3000 + 449496
6 bluetoothd 0x107df963a 0x107aa3000 + 3499578
7 bluetoothd 0x107dfa7d1 0x107aa3000 + 3504081
8 bluetoothd 0x107dda085 0x107aa3000 + 3371141
9 bluetoothd 0x107dd9ca9 0x107aa3000 + 3370153
10 libdispatch.dylib 0x7ff81e9410cc _dispatch_call_block_and_release + 12
11 libdispatch.dylib 0x7ff81e942317 _dispatch_client_callout + 8
12 libdispatch.dylib 0x7ff81e948317 _dispatch_lane_serial_drain + 672
13 libdispatch.dylib 0x7ff81e948e30 _dispatch_lane_invoke + 417
14 libdispatch.dylib 0x7ff81e952eee _dispatch_workloop_worker_thread + 753
15 libsystem_pthread.dylib 0x7ff81eaf5fd0 _pthread_wqthread + 326
16 libsystem_pthread.dylib 0x7ff81eaf4f57 start_wqthread + 15
Thread 2:: StackLoop
0 libsystem_kernel.dylib 0x7ff81eabebd2 __psynch_mutexwait + 10
1 libsystem_pthread.dylib 0x7ff81eaf6e7e _pthread_mutex_firstfit_lock_wait + 76
2 libsystem_pthread.dylib 0x7ff81eaf4cbb _pthread_mutex_firstfit_lock_slow + 205
3 bluetoothd 0x107b10a3c 0x107aa3000 + 449084
4 bluetoothd 0x107b10ea4 0x107aa3000 + 450212
5 libsystem_pthread.dylib 0x7ff81eaf94e1 _pthread_start + 125
6 libsystem_pthread.dylib 0x7ff81eaf4f6b thread_start + 15
Thread 3:
0 libsystem_pthread.dylib 0x7ff81eaf4f48 start_wqthread + 0
Thread 4:
0 libsystem_pthread.dylib 0x7ff81eaf4f48 start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x7ff81eaf4f48 start_wqthread + 0
Thread 1 crashed with X86 Thread State (64-bit):
rax: 0x0000000002000209 rbx: 0x0000000000000000 rcx: 0x0000700001616468 rdx: 0x00007000016164d0
rdi: 0x0000000000000012 rsi: 0x0000000000000002 rbp: 0x00007000016164b0 rsp: 0x0000700001616468
r8: 0x00007fc95b9158d0 r9: 0x0000000000000000 r10: 0x0000000000000050 r11: 0x0000000000000246
r12: 0x0000000000000050 r13: 0x00007000016164d0 r14: 0x0000000000000002 r15: 0x0000000000000012
rip: 0x00007ff81eadfdba rfl: 0x0000000000000246 cr2: 0x00000001080d3690
Logical CPU: 0
Error Code: 0x02000209
Trap Number: 133
Binary Images:
0x7ff81eabb000 - 0x7ff81eaf2fff libsystem_kernel.dylib (*) <8cc28466-fd2f-3c80-9834-9525b7beac19> /usr/lib/system/libsystem_kernel.dylib
0x7ff81eb40000 - 0x7ff81f042fff CoreFoundation (*) <93c48919-68af-367e-9a67-db4159bc962c> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x107aa3000 - 0x108176fff bluetoothd (*) <a71d6d7c-a7c1-3503-87e5-7c88f0c27d0b> /usr/sbin/bluetoothd
0x1093df000 - 0x10944afff dyld (*) <71febccd-d9dc-3599-9971-2b3407c588a8> /usr/lib/dyld
0x7ff81e93f000 - 0x7ff81e985fff libdispatch.dylib (*) <1a04b380-76e4-3e4b-b0fc-9837533d021d> /usr/lib/system/libdispatch.dylib
0x7ff81eaf3000 - 0x7ff81eafefff libsystem_pthread.dylib (*) <b5454e27-e8c7-3fdb-b77f-714f1e82e70b> /usr/lib/system/libsystem_pthread.dylib
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=925.4M resident=0K(0%) swapped_out_or_unallocated=925.4M(100%)
Writable regions: Total=493.4M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=493.4M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 256K 1
Dispatch continuations 128.0M 1
Dispatch continuations (reserved) 64.0M 1 reserved VM address space (unallocated)
Kernel Alloc Once 8K 1
MALLOC 170.3M 48
MALLOC guard page 48K 10
MALLOC_MEDIUM (reserved) 120.0M 1 reserved VM address space (unallocated)
ObjC additional data 15K 1
SQLite page cache 128K 2
STACK GUARD 56.0M 6
Stack 10.5M 6
VM_ALLOCATE 36K 5
__CTF 756 1
__DATA 19.7M 390
__DATA_CONST 20.2M 246
__DATA_DIRTY 1180K 163
__FONT_DATA 4K 1
__LINKEDIT 646.1M 9
__TEXT 279.3M 406
__UNICODE 592K 1
dyld private memory 1024K 1
mapped file 29.3M 6
shared memory 580K 6
=========== ======= =======
TOTAL 1.5G 1313
TOTAL, minus reserved VM space 1.3G 1313Case #3
On some systems, even when using all the fixes, the Bluetooth address may appear as NULL. Unless there is a valid Bluetooth address, the Bluetooth will remain in off state as reported by @GrantMBP
Upon checking the bootlog
bluetoothd: [com.apple.bluetooth:Server.Core] com.apple.server.bluetooth: Bluetooth Super Server Robot Destroyer
securityd: (Security) [com.apple.securityd:atomicfile] 0x7f7df7806160 commited /private/var/db/mds/system/mdsObject.db.sb-a16a57d5-8J5qoF to /private/var/db/mds/system/mdsObject.db
bluetoothd: [com.apple.bluetooth:Server.Core] could not find BT_DEVICE_ADDRESS env variable
bluetoothd: [com.apple.bluetooth:Server.Core] It is a MacBookPro12,1
bluetoothd: [com.apple.bluetooth:Server.Core] FindLocalMacAddress did not find bootargs for random address generation
securityd: (Security) [com.apple.securityd:atomicfile] 0x7f7df7806160 commited /private/var/db/mds/system/mdsObject.db.sb-a16a57d5-8J5qoF to /private/var/db/mds/system/mdsObject.db
bluetoothd: [com.apple.bluetooth:Server.Core] could not find BT_DEVICE_ADDRESS env variable
bluetoothd: [com.apple.bluetooth:Server.Core] It is a MacBookPro12,1
bluetoothd: [com.apple.bluetooth:Server.Core] FindLocalMacAddress did not find bootargs for random address generation
Solutions
To prevent the Bluetooth issue on macOS Monterey and above, a couple of solutions are available which are described below. Depending on the case, you may need to use either one of the solutions listed below or a combination of them.
I. Implement USB Mapping
Since macOS Big Sur (11.3.x), Apple made some changes to its USB implementation. With the new rewritten drivers, the XhciPortLimit is broken. Although it is always recommended to map the USB ports, it has become mandatory now.
In addition, you need to change the connector type for your Bluetooth USB Port. As macOS always expects Bluetooth as
Internal, it's best to change the connector type to 255 (Internal). See USB Port Mapping for more information.II. Remove Duplicate Bluetooth
There are a few setups where the Motherboard is usually shipped with an Onboard Intel WiFi/BT Card and to avoid the hassle, several users tend to install a PCIe WiFi/BT Card which is a wrong approach. This is only suitable where the BIOS has the option to disable the Onboard WiFi/BT. For the rest of the cases, where one has no such option, you must disable the unsupported one to avoid conflicts. If it's not possible to remove the hardware (to avoid the risk of damage), you can simply exclude the Bluetooth port on the EHC/XHC Bus. See USB Port Mapping for more information.
However, there are several cases where the Bluetooth is connected to an Internal Hub, and disabling such a port will make the whole hub stop working and as a result, the other devices connected to such port will not work. Therefore, the best approach is to simply remove the unsupported Bluetooth module and replace it with a compatible one. See Bluetooth Compatibility for more information.
III. Bypass Firmware Update Check
In Monterey,
bluetoothd identifies and opens the Bluetooth IOUSBDevice. It will then send an XPC message to BlueTool, another daemon used for updating firmware, to run its internal script. In its internal script, BlueTool will attempt to update the firmware, if necessary. However, on non-native chipsets, BlueTool fails to find firmware for the chipset:
Code:
2021-06-10 19:33:57.527421+0100 0x35b Default 0x0 149 0 bluetoothd: [com.apple.bluetooth:Server.Core] Booting chipset
2021-06-10 19:33:57.527426+0100 0x35b Default 0x0 149 0 bluetoothd: [com.apple.bluetooth:Server.XPC] Creating XPCServiceConnection to com.apple.BlueTool
...
2021-06-10 19:33:57.527946+0100 0x35b Default 0x0 149 0 bluetoothd: [com.apple.bluetooth:Server.XPC] Opening connection to com.apple.BlueTool for UID 0
...
2021-06-10 19:33:57.544046+0100 0x6f1 Default 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] Running xpcRunBuiltinScript
...
2021-06-10 19:33:57.546883+0100 0x6f1 Error 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] getManufacturer could not find bootdata property
...
2021-06-10 19:33:57.553779+0100 0x6f1 Error 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] No WiFi - Iteration 0
...
2021-06-10 19:33:58.058809+0100 0x6f1 Error 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] Error - no firmware for this platform. Looking for <private> (null) DEV
2021-06-10 19:33:58.058817+0100 0x6f1 Default 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] <private> script attempt 1 of 1: result 10 execution time:513(MS)
2021-06-10 19:33:58.558993+0100 0x6f1 Default 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] builtin script completed with result 10
2021-06-10 19:33:58.559031+0100 0x6f1 Default 0x0 350 0 BlueTool: [com.apple.bluetooth:BlueTool] Completed handling of dictionary-xpc event
2021-06-10 19:33:58.559136+0100 0x35b Error 0x0 149 0 bluetoothd: [com.apple.bluetooth:Server.Core] Couldn't find a platform / chipset / firmware combination for the HW. Please file a bug with syslog, full ioreg output and result of `uname -a`.
2021-06-10 19:33:58.559137+0100 0x35b Error 0x0 149 0 bluetoothd: [com.apple.bluetooth:Server.Core] BlueTool failed to run boot script with result 10
...
2021-06-10 19:33:58.560254+0100 0x35b Default 0x0 149 0 bluetoothd: [com.apple.bluetooth:Server.Core] Notifying BT Firmware CrashedBlueTool then returns 10 as the result in the XPC reply back. Here, the bluetoothd terminates, as this is a non-zero value. The launchd will then restart bluetoothd, and the cycle continues.To skip the firmware update check,
BlueTool checks for the existence of /etc/bluetool/SkipBluetoothAutomaticFirmwareUpdate. This could be manually created, but we replace it with /System/Library/CoreServices/boot.efi, so manually creating it is not needed, and so Bluetooth can work in recovery. Since boot.efi should always exist, the firmware update check will always be skipped, and since the existence of the file is checked, not the contents, there are no issues with replacing the original string with this.However, for this to work properly, the transport must also be properly set (otherwise, the file will be ignored). To determine the transport,
BlueTool (and also bluetoothd) looks for a transport-encoding property on a registry entry named either bluetooth or marconi-bt. The value of this property determines the transport: 0 for USB, 3 for UART, and 7 for PCIe. Therefore, we set transport-encoding to 00000000 (type data) and rename ourselves to bluetooth. BlueTool will then find our registry entry, get the transport, check for the existence of the skip firmware file, skip the firmware update, and then finish and reply with a result of 0 to bluetoothd. bluetoothd will then continue and Bluetooth should work.BlueToolFixup forces
BlueTool to skip attempting a firmware update, allowing for some Broadcom¹ chipsets² to work on Monterey. It also properly sets the transport.¹ BlueToolFixup solely patches BlueTool's firmware update check currently. More work appears to be needed for Intel Bluetooth.
² Not many have been tested currently, and not all features (Continuity) have been tested. This is obviously not required on cards pulled from a Mac, and on cards that are completely native and do not need BrcmPatchRAM (ie. BCM94360NG).
IV. Bypass Address Check
Since macOS 12.4 and newer versions, a new address check has been introduced in
bluetoothd, which triggers an error if two Bluetooth devices have the same address. However, this check can be circumvented by adding the boot argument -btlfxallowanyaddr. This is still useful in case you don't have multiple Bluetooth devices but have a NULL address issue. See adding boot-args for more information.V. Update Bluetooth Firmware
On some systems, the Bluetooth address may still appear as NULL despite using all the above solutions. Unless there is valid Bluetooth firmware, the Bluetooth will remain in the off state as reported by @HG87. You must flash the correct firmware for your Bluetooth device. See Flashing Broadcom Bluetooth Firmware for more information.
Test Results
Following are the test results for various Bluetooth
BCM94360NG
Conclusion
Hence, we can conclude that most of the Broadcom and Intel WiFi/BT Cards under Monterey may not work, even with proper USB Ports Mapping. This solution is also required by natively supported AirPort Cards such as Broadcom BCM94360NG and BCM943602CS. This might be useful for other Broadcom models as well. We can confirm that the above solution completely fixes the Bluetooth issue on macOS Monterey and above.
Reporting
Last edited:
