Anyone can make bluetooth work on Sonoma?

rank_jokobe · Aug 23, 2024

I have build a macOS VM Sonoma, but I can not make bluetooth work on it. My wireless card is FV-T919 with bcm94360CD, actually It have a bluetooth that can run natively on Sonoma and Ventura.
On Ventura it worked natively both wifi and bluetooth, but on Sonoma bluetooth failed to work, I tried passthrough USB device and passthrough USB controller(Ventura run this way), but they all failed on Sonoma, So maybe something different on Ventura and Sonoma?
by the way, I got logs on Sonoma
appleusbxhci::createports ports limit reached
following the instruction on https://www.nicksherlock.com/2022/10/installing-macos-13-ventura-on-proxmox/

the1010boy · Aug 25, 2024

I am also trying to figure out how to get WiFi and Bluetooth working in my macOS VM, running Sonoma 14.6.1.

I too have a bcm94360CD Broadcom card. Additionally I have a Broadcom bcm43602, which I am trying now, and that doesn't seem to work either.

At first, I thought it was just my inexperience in passing through PCI devices and passing through USB devices. However, after I've successfully passed through several PCIe devices (NVMe drive, AMD Radeon GPU, HighPoint Tech RocketRAID HBA) and several USB devices (keyboard, mouse, webcam) I now believe that my issue is something else.

After searching the interweb some more, I have found the following sources which lead me to believe the issue is a macOS issue that needs to be dealt with via some hackintoshing.

I found this page about a preview release of OCLP (OpenCore Legacy Patcher) for "Preliminary support for macOS Sonoma #1077", which has a section far down the page called "Hackintosh Notes" where it says...

"While the project is designed for legacy Mac hardware, we know the community is quite interested in our development of Broadcom patches. For those who wish to use the Broadcom patches on non-standard machines such as Hackintoshes, see below:

Enabling Patching support for modern Broadcom Cards

To use our current patches, you'll need to ensure the following:

System Integrity Protection is set to 0x803
- csr-active-config | data | 03080000
  - Reset NVRAM or add csr-active-config to Delete to ensure the new variable is set
AMFI is disabled
- boot-args | string | amfi=0x80
Secure Boot Model is set to Disabled
Following kexts are blocked:
- com.apple.iokit.IOSkywalkFamily (Reference)
- Set MinKernel to 23.0.0 to ensure patches only apply on Sonoma
Following kexts are injected:
- IOSkywalk.kext
- IO80211FamilyLegacy.kext
  - Kext has a child, AirPortBrcmNIC.kext, ensure this is injected as well
- Set MinKernel to 23.0.0 to ensure patches only apply on Sonoma

Once these are injected, you can run OpenCore-Patcher's Post-Install option and root patch. On reboot, Wireless support should be restored assuming your machine was configured correctly to the above."

However, I'm not very experienced in hackintoshing, as yet, so some of this I don't yet quite understand.

I do have some experience in downloading and using OCLP to run Monterey on my Mac Pro 5,1 with an upgraded WiFi and Bluetooth card (bcm943602CDP) which has been working great for quite some time now. But even this isolated experience using OCLP doesn't give me the confidence to say I am an experienced user of OCLP, as yet.

I also found this post on OSX Latitude "Wifi in Sonoma: Patching for legacy Broadcom wireless cards" which states Sonoma dropped support for these Broadcom cards which they now refer to as "legacy" wifi/bluetooth cards. Their steps to solve the issue are similarly beyond my expertise.

However, I'm going to try and see if I can figure it all out. If however, you already know and understand what they are talking bout in these sites then I would welcome a collaboration so that we can get our WiFi and bluetooth up and running in our macOS VMs.

the1010boy · Aug 25, 2024

I also just came across this page: "Get back Fenvi T919 and other Broadcom Wi-Fi on macOS 14 Sonoma thanks to OLCP"

...helpful, yet the most intriguing part of it, for me, is the semi-automated option mentioned at the very end of the article which references this post "Patch Sonoma WiFi On The Fly" by HorizonUnix.

fty1777 · Aug 26, 2024

Same here. Mine is a bcm and a dedicated whole USB controller is passed-through as a PCI-e device. Solutions on google can fix the Wifi by OLCP, but the bluetooth is still non-fixable after a lot of methods tried: OLCP, kexts, even a fresh install of Sonoma, no luck. Monterey and Ventura all works smoothly with fully functional hands-off and airdrop. Having been searching for solutions for nearly one year and still stuck on Ventura now.

the1010boy · Aug 27, 2024

I found yet another article on "How To fix Broadcom Wi-FI on macOS Sonoma and Later".

After reading through this article and watching the associated video on it (video link is referenced in the article), I decided to try out the fix to see if I could do it and hope it solved the issues I'm seeing with my macOS VM.

Sadly the fix did not resolve my Bluetooth issues , but it did resolve WiFi issues. (to be fair the article's title only mentions fixing WiFI, but I was hoping it would resolve the bluetooth issue also.)

Anyway, so now I too am looking for just the Bluetooth fix at this point.

One thing I did notice is that my bluetooth hardware isn't recognized correctly by macOS. And the guide I followed for getting wifi working (link above) does say that before any of their steps for fixing the issue could lead to a successful resolution of the WiFi issues, the WiFI hardware would FIRST have to be recognized by macOS.

So I imagine I first have to figure out how to get my bluetooth hardware recognized by macOS in my VM before anything else.

Here's how Proxmox sees my USB passed through Bluetooth device...

Here's how my VM's macOS system profiler sees my Bluetooth card (notice 'NULL' , that can't be good)...

Here's how hackintool running on macOS in my VM sees the VM's USB devices (notice none of them are bluetooth specific devices)...

fty1777 · Aug 27, 2024

the1010boy said:
I found yet another article on "How To fix Broadcom Wi-FI on macOS Sonoma and Later".

After reading through this article and watching the associated video on it (video link is referenced in the article), I decided to try out the fix to see if I could do it and hope it solved the issues I'm seeing with my macOS VM.

Sadly the fix did not resolve my Bluetooth issues , but it did resolve WiFi issues. (to be fair the article's title only mentions fixing WiFI, but I was hoping it would resolve the bluetooth issue also.)

Anyway, so now I too am looking for just the Bluetooth fix at this point.

One thing I did notice is that my bluetooth hardware isn't recognized correctly by macOS. And the guide I followed for getting wifi working (link above) does say that before any of their steps for fixing the issue could lead to a successful resolution of the WiFi issues, the WiFI hardware would FIRST have to be recognized by macOS.

So I imagine I first have to figure out how to get my bluetooth hardware recognized by macOS in my VM before anything else.

Here's how Proxmox sees my USB passed through Bluetooth device...
View attachment 73763

Here's how my VM's macOS system profiler sees my Bluetooth card (notice 'NULL' , that can't be good)...
View attachment 73760

Here's how hackintool running on macOS in my VM sees the VM's USB devices (notice none of them are bluetooth specific devices)...
View attachment 73761

Thank you so much for your info. My situation is quite similar to yours. I can have my wifi work after using OLCP patching and stuff as guided in the tutorial (there are a LOT of tutorials fixing the broadcom wifi in Sonoma), but the bluetooth still does not work. I see the following in common:

1. bluetooth controller address indicated NULL in sys report
2. USB Ports is empty in Hackintool, with the same usb mapping configuration used in Ventura, where instead all ports are correctly shown and can respond to USB device plug-unplug. (However, this seems like a Hackintool problem instead of the USB itself.)

I have my whole USB controller passed-through to the VM because I bought a dedicated PCI-e USB controller, and I do not need to set up any usb device in the proxmox web ui.

Searching on google gives a lot of people complaining about the Wi-Fi issue, which can be perfectly solved by OLCP, but few reports about a broken bluetooth. Instantly working bluetooth + non-functional Wi-Fi looks like a very typical combination met by most people after the system upgrade. But we now have working Wi-Fi and broken bluetooth, which is the exact opposite. I suspect this is specific to proxmox ve (or any macOS installed in QEMU, or to be broader, KVM.) because I see so few people with the issues like us. Unfortunately, I have not found a solution yet.

fty1777 · Aug 27, 2024

Really bad news: according to https://github.com/dortania/OpenCore-Legacy-Patcher/issues/1076, bluetoothd now checkes for virtual machine manager and refuses to work once it found the OS is inside a VM. I am not 100% sure about this yet. Maybe you guys can further investigate.

fty1777 · Aug 27, 2024

fty1777 said:
Really bad news: according to https://github.com/dortania/OpenCore-Legacy-Patcher/issues/1076, bluetoothd now checkes for virtual machine manager and refuses to work once it found the OS is inside a VM. I am not 100% sure about this yet. Maybe you guys can further investigate.

So what bluetoothd actually checks is kern.hv_vmm_present, which would be 1 if the OS is running in a VM. After digging down into what OCLP has done to patch the kernel to fake an always kern.hv_vmm_present=1 for other purposes by switching kern.hv_vmm_present with kern.direct_handoff (which is always 1, I believe that's why it is chosen), I decided to do the opposite. I searched through the kernel binary to found a seemingly always 0 kernel flag with the same length as hv_vmm_present, and found that kern.hibernatecount would typically keep 0 (since in my case the hibernation is disabled, which I think is unnecessary for a VM). I made kernel patches to switch the two flags, and boom! It is now working perfectly!

Share this solution with you guys. You can try the following if you are not using hibernation:

With OCAT GUI:

Go to Kernel -> Patch and add two new items as follows:

Identifier	Base	Count	Find	Limit	Mask	Replace	Skip	Arch
kernel		1	68696265726E61746568696472656164790068696265726E617465636F756E7400	0		68696265726E61746568696472656164790068765F766D6D5F70726573656E7400	0	x86_64
kernel		1	626F6F742073657373696F6E20555549440068765F766D6D5F70726573656E7400	0		626F6F742073657373696F6E20555549440068696265726E617465636F756E7400	0	x86_64

Or directly edit config.plist:

Insert the two patch dicts into the Patch array:

Code:

    <dict>
        ...
        <key>Kernel</key>
        <dict>
            ...
            <key>Patch</key>
            <array>
                ...
                <dict>
                    <key>Arch</key>
                    <string>x86_64</string>
                    <key>Base</key>
                    <string></string>
                    <key>Comment</key>
                    <string>Sonoma VM BT Enabler - PART 1 of 2 - Patch kern.hv_vmm_present=0</string>
                    <key>Count</key>
                    <integer>1</integer>
                    <key>Enabled</key>
                    <true/>
                    <key>Find</key>
                    <data>aGliZXJuYXRlaGlkcmVhZHkAaGliZXJuYXRlY291bnQA</data>
                    <key>Identifier</key>
                    <string>kernel</string>
                    <key>Limit</key>
                    <integer>0</integer>
                    <key>Mask</key>
                    <data></data>
                    <key>MaxKernel</key>
                    <string></string>
                    <key>MinKernel</key>
                    <string>20.4.0</string>
                    <key>Replace</key>
                    <data>aGliZXJuYXRlaGlkcmVhZHkAaHZfdm1tX3ByZXNlbnQA</data>
                    <key>ReplaceMask</key>
                    <data></data>
                    <key>Skip</key>
                    <integer>0</integer>
                </dict>
                <dict>
                    <key>Arch</key>
                    <string>x86_64</string>
                    <key>Base</key>
                    <string></string>
                    <key>Comment</key>
                    <string>Sonoma VM BT Enabler - PART 2 of 2 - Patch kern.hv_vmm_present=0</string>
                    <key>Count</key>
                    <integer>1</integer>
                    <key>Enabled</key>
                    <true/>
                    <key>Find</key>
                    <data>Ym9vdCBzZXNzaW9uIFVVSUQAaHZfdm1tX3ByZXNlbnQA</data>
                    <key>Identifier</key>
                    <string>kernel</string>
                    <key>Limit</key>
                    <integer>0</integer>
                    <key>Mask</key>
                    <data></data>
                    <key>MaxKernel</key>
                    <string></string>
                    <key>MinKernel</key>
                    <string>22.0.0</string>
                    <key>Replace</key>
                    <data>Ym9vdCBzZXNzaW9uIFVVSUQAaGliZXJuYXRlY291bnQA</data>
                    <key>ReplaceMask</key>
                    <data></data>
                    <key>Skip</key>
                    <integer>0</integer>
                </dict>
                ...

Save the modification and then just reboot to see if it works. Technically no NVRAM reset should be needed.

If your hibernatecount is not always 0, you may want to find another flag. I used this command to find all kern flags with 14 characters:

Bash:

sysctl kern | grep -E '^kern\.[^.]{14}:'

My output is (before patching) :

Code:

kern.sugid_coredump: 0
kern.hibernatecount: 0
kern.hv_vmm_present: 1
kern.wq_max_threads: 512
kern.drivercorefile: /private/var/dextcores/%N.core
kern.direct_handoff: 1
kern.consoleoptions: 0
kern.pmcallouttimer: 2000
kern.sleep_abs_time: 0

After patching:

Code:

kern.sugid_coredump: 0
kern.hibernatecount: 1
kern.hv_vmm_present: 0
kern.wq_max_threads: 512
kern.drivercorefile: /private/var/dextcores/%N.core
kern.direct_handoff: 1
kern.consoleoptions: 0
kern.pmcallouttimer: 2000
kern.sleep_abs_time: 0

Unfortunately, this would very possibly break qemu-guest-agent, which is necessary for the host getting VM status or taking hot snapshot while the VM is running. This is because qemu-guest-agent also checks the hv_vmm_present flag, but only works if it is true (=1).

Use at your own risk. Hope it would help.

the1010boy · Aug 30, 2024

fty1777 said:

Or directly edit config.plist:

Insert the two patch dicts into the Patch array:

Code:

<dict>
...
<key>Kernel</key>
<dict>
...
<key>Patch</key>
<array>
...
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string></string>
<key>Comment</key>
<string>Sonoma VM BT Enabler - PART 1 of 2 - Patch kern.hv_vmm_present=0</string>
<key>Count</key>
<integer>1</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>aGliZXJuYXRlaGlkcmVhZHkAaGliZXJuYXRlY291bnQA</data>
<key>Identifier</key>
<string>kernel</string>
<key>Limit</key>
<integer>0</integer>
<key>Mask</key>
<data></data>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>20.4.0</string>
<key>Replace</key>
<data>aGliZXJuYXRlaGlkcmVhZHkAaHZfdm1tX3ByZXNlbnQA</data>
<key>ReplaceMask</key>
<data></data>
<key>Skip</key>
<integer>0</integer>
</dict>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>Base</key>
<string></string>
<key>Comment</key>
<string>Sonoma VM BT Enabler - PART 2 of 2 - Patch kern.hv_vmm_present=0</string>
<key>Count</key>
<integer>1</integer>
<key>Enabled</key>
<true/>
<key>Find</key>
<data>Ym9vdCBzZXNzaW9uIFVVSUQAaHZfdm1tX3ByZXNlbnQA</data>
<key>Identifier</key>
<string>kernel</string>
<key>Limit</key>
<integer>0</integer>
<key>Mask</key>
<data></data>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>22.0.0</string>
<key>Replace</key>
<data>Ym9vdCBzZXNzaW9uIFVVSUQAaGliZXJuYXRlY291bnQA</data>
<key>ReplaceMask</key>
<data></data>
<key>Skip</key>
<integer>0</integer>
</dict>
...

Save the modification and then just reboot to see if it works.

Thanks for posting your solution @fty1777 ...the "just edit config.plist" section of your solution is what worked for me. I now have bluetooth working on my macOS VM running Sonoma 14.6.1

gadreel · Sep 22, 2024

I have an ASUS BT-400 bluetooth and his solution worked for me also. I express my thanks to him over PMs. I do not know if there is somewhere we can link his patch for other users with VMs. You have no idea how frustrating was for me until I found his answer after a year of searching the whole internet for answers.

ulys · Nov 4, 2024

I'm using the Intel AX210 from Ziyituod and I created a Sonoma (14.7) VM with OSX-PROXMOX. Wi-Fi and GPU Passthrough work.
I tried the patch and got the same output "After patching". Before the patch, bluetooth was always "on" but not working. After the patch, it switches back to off right after enabling it.

It worked for me using the config.plist and kexts here: https://github.com/OpenIntelWireless/IntelBluetoothFirmware/issues/476#issuecomment-1993701502
I'm not sure about stability yet.
kern.hv_vmm_present is still 1 but it's fine for me

For anyone having the same issue, don't forget to passthrough the USB like me...

Search

Search

Anyone can make bluetooth work on Sonoma?

rank_jokobe

New Member

the1010boy

New Member

the1010boy

New Member

fty1777

New Member

the1010boy

New Member

fty1777

New Member

fty1777

New Member

fty1777

New Member

the1010boy

New Member

gadreel

New Member

ulys

New Member