Ask Different Asked by Ivan Gozali on December 6, 2021
I seem to be having persistent issues with Bluetooth connectivity, especially after waking up my Macbook Pro from a long sleep.
I have a speaker that automatically turns off after a certain period of inactivity, and my use case typically is open the laptop, turn the speaker on, and when the Bluetooth driver is acting normal, they will automatically reconnect.
However, the problem seem to be that the my Bluetooth peripherals do not reconnect if my Macbook has just been woken up from a long sleep.
After searching around, I found this script to relaunch the bluetooth kernel extensions, but it didn’t seem to work on Yosemite.
Here’s what sudo tail -f /var/log/system.log
gave me after doing a kextload
and kextunload
(hostname and username redacted):
Nov 17 07:50:11 {redacted} sudo[8118]: username: TTY=ttys000 ; PWD=/Users/username; USER=root ; COMMAND=/sbin/kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
Nov 17 07:50:11 {redacted} kernel[0]: IOBluetoothUSBDFU::probe
Nov 17 07:50:11 {redacted} kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821D FirmwareVersion - 0x0147
Nov 17 07:50:11 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x0800 ****
Nov 17 07:50:11 {redacted} kernel[0]: **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed -- 0x0800 ****
Nov 17 07:50:11 {redacted} kernel[0]: [IOBluetoothHCIController][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][initHardwareWL] -- failed -- calling DoDeviceReset (kBluetoothControllerResetHub) -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][DoDeviceReset] -- thread_call_enter1 (mReEnumerateOrResetThread) -- reEnumerateOrReset (0xffffff8213ac3ae0) = 2 -- returned FALSE -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Error!! -- Something went wrong in the setup process. Could not communicate with Bluetooth Transport successfully -- 0x0800 -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- entering -- param0 = 0xffffff806a870800, param1 = 0x2 -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- entering -- reEnumerateOrResetIn = 2 -- this = 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- in our workloop -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- parameter is valid -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- reEnumerateOrReset = 2 -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- calling myHub->ReEnumerateDevice() -- gEnumerateCounter = 1
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- exit; error = 0x0000 (kIOReturnSuccess)
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- exiting -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: IOBluetoothUSBDFU::probe
Nov 17 07:50:12 {redacted} kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821D FirmwareVersion - 0x0147
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHCIController][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHCIController::setConfigState] calling registerService
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Connected to the transport successfully -- 0xe300 -- 0x0800 -- 0x0800 ****
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.595 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.617 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.637 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.657 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.659 : BTLE scanner Powered Off
Nov 17 07:50:12 --- last message repeated 2 times ---
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.663673 AM [AirPlay] BTLE client stopping to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} blued[62]: hciControllerOnline; HID devices? 0
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.663868 AM [AirPlay] BTLE client starting to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.664 : Starting Handoff scanning
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.664336 AM [AirPlay] BTLE client stopped to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.664753 AM [AirPlay] BTLE client started to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.664 : Stopping Handoff advertising
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.665 : BTLE scanner Powered On
Nov 17 07:50:12 {redacted} blued[62]: hostControllerOnline - Number of Paired devices = 2, List of Paired devices = (
"00-0c-8a-dd-fd-88",
"84-38-35-ec-1c-ea"
)
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::message - kIOUSBMessagePortHasBeenReset.
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::checkStatus - received Status Packet, Payload 2: device was reinitialized
Nov 17 07:50:13 {redacted} hidd[74]: MultitouchHID: device bootloaded
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::_deviceGetReport - DeviceRequest for reportID 0xc8 returned with result 0xe000404f - retrying
uname -a
output (hostname redacted):
$ uname -a
Darwin {redacted} 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
Has any of you seen this problem before? Any help would be appreciated.
UPDATE2: The last solution only worked for about a week. I have updated to macOS Mojave (10.14.6) and this issue appears to be fixed. Will monitor and report back if anything changes.
UPDATE: I have been able to solve this 100% after observing for months by going to System Preferences
-> General
-> unchecking Allow Handoff between this Mac and your iCloud devices
So I've been dealing with this on my Macbook Pro (Early 2015) for about as long as I've had it. Tried pretty much everything, kextunload
/kextload
, SMC reset, etc... to no avail. To be specific, my symptom is that after waking up sometime the bluetooth icon would have a squiggle through it like this:
And would refuse to connect to any devices. This behavior was present on Yosemite as well as High Sierra (version I'm currently on).
The ONLY workaround that has worked with > 80% consistency for me (other than rebooting) is this:
System Preferences
-> Bluetooth
-> Uncheck Show Bluetooth in menu bar
-> Check Show Bluetooth in menu bar
then wait 10 seconds (at this point your bluetooth should be available and not have the squiggle through the icon)-> retry connecting device.
This has worked 80% of the time for me although sometimes I still need a reboot. Hope this helps.
UPDATE: This has prevented bluetooth unavailable but it appears bluetooth would just sometimes not connect / work even though the icon shows it's fine... Not really sure what to do any more. This seems like a problem Apple should investigate.
Answered by Alex H on December 6, 2021
Based on other people suggestions I created simple shell script to reset bluetooth. See gist for details.
Simplified version (depends on blueutil
brew):
blueutil -p 0
networksetup -setairportpower en0 off
sleep 3
networksetup -setairportpower en0 on
sleep 3
blueutil -p 1
It turns off bluetooth, turns off wi-fi, turns wi-fi back on, and finally turns bluetooth back on.
Answered by CrnaStena on December 6, 2021
This article by Michael Kummer reports a fairly exhaustive list of failed attempts to fix bluetooth problems on mac, and finally suggests a compromised solution by disabling handsoff that seems working: https://michaelkummer.com/technology/mac-bluetooth-issues-affect-keyboard-trackpad/
Answered by user716468 on December 6, 2021
Reinstall MacOS.
This is not really a solution solution but I just want to share my experience to give some hope to those who are facing the same problem as mine -- that this might still not be a hardware problem or wifi interference problem, which may be more costly or troublesome to solve that reinstalling MacOS.
What I experienced: After my 2015 Macbook Pro woke up from sleep, it could not connect to bluetooth devices. The problem had worsen overtime, from initially just little inconvenience (e.g., disabling and re-enabling bluetooth module or wifi could fix it) to later a huge pain (e.g., requires a restart with SMC/PRAM reset).
A symptom or side effect which might be related was that the computer sometimes took too long (10s of seconds) to wake up.
Reinstalling (clean) MacOS was my last resort but it seems to simply work. After reinstalling I did not observe any problem or hiccup with bluetooth, wifi, or sleeping.
Disclaimer: There is probably some proper fix that can achieve the same effect, which may or may not have been discovered yet. Also, reinstalling OS always comes with risks of losing data and productivity that one should evaluate.
New update: It was problem-free for a week. But then the bluetooth problem seems to come back sometimes. I did not do much tinkering with the system in the week other than installing some very common software and packages mainly through Homebrew.
Answered by user716468 on December 6, 2021
Looks like the kextunload
commands don't actually work anymore on High Sierra. However, there's a 3rd party command line tool for doing the same thing and it works: https://github.com/toy/blueutil – you can tweak the scripts mentioned here to use blueutil
instead, or there's even a full-blown solution (very similar to what we have seen on this page already): https://gist.github.com/ralph-hm/a65840c4f5e439b90170d735a89a863f
Answered by miemo on December 6, 2021
I still have this issue in macOS Sierra. @Tyilo's link above to his gist gave me a starting point. But I also wanted to use homebrew to install sleepwatcher, and the plist files weren't set up properly out of the box. So I played around for a long time and came up with this script that got things working reliably for me.
brew install sleepwatcher
sudo touch /etc/rc.sleep
sudo tee -a /etc/rc.wakeup <<EOF
#!/bin/sh
# Sleepwatcher script to get bluetooth working after the mac wakes up
# Got this approach from https://gist.github.com/Tyilo/c92684d277acb62272b5
kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
EOF
sudo chmod +x /etc/rc.wakeup
brew services start sleepwatcher
sudo tee -a /Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-custom.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>de.bernhard-baehr.sleepwatcher</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/sbin/sleepwatcher</string>
<string>-V</string>
<string>-s /etc/rc.sleep</string>
<string>-w /etc/rc.wakeup</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
</dict>
</plist>
EOF
sudo launchctl load /Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-custom.plist
Answered by Kyle Tolle on December 6, 2021
Most of the suggestion I've read seemed a bit complex for something as simple as this. Decided to take a noob approach:
Answered by GDB on December 6, 2021
Aware that this is quite an old post now but was being driven nuts by the delay I was getting after sleep wake-up before the Magic Trackpad was usable.... could easily be a good 30 secs. Tried most / all of the hints and tips I could find to very little effect.
However, I just tried moving the Bluetooth icon on the Menu bar (CMD ALT Drag) from its normal position (about 7th in ) to 2nd in (as counted from the Right), i.e. next to the Spotlight menu.
So far?... problem gone !
Not 100% sure why this would be, but suspect it might be something to do with the order in which tasks from those items on the RHS Menu Bar are addressed after wake-up, i.e. those nearer RHS have higher priority?
Only takes a couple of secs to do, so if you also have this problem - might be worth a try?
(iMac 27" i7 / OS X 10.10.5)
JH
Answered by John H on December 6, 2021
Try clicking the mouse after your Mac wakes from sleep.
This seemed to connect my Magic Mouse 2 faster with a Mac Mini running macOS Sierra (10.12.2).
Answered by Aanand on December 6, 2021
To summarize, here's a list of things mentioned here, in links from here, in similar threads at other sites, or even made up by me reasoning from those others. I've tried all of these, singly and in many combinations. All of them have seemed to work at least once; all have failed at least once.
I choose to keep this list handy, and use "all of the above."
I think the only thing that's certain, here, is that there's a large dose of "random" involved somewhere, perhaps a race among all these drivers for networks, pseudo networks, layered networks, virtual networks, and proxy networks. In which case, it's probably not merely Apple's fault, because those drivers come from a variety of sources.
Of course, Apple's once-famous "just works" reputation was largely built on forbidding exactly this kind of colliding diversity.
Answered by jackr on December 6, 2021
-- UPDATE: This problem is NOT fixed in OSX 10.11 El Capitan --
The following is an alternative to the Automator solution posted by webaholic, for those who, like me, find inconvenient having to entering your password again (most likely you'll have just entered it to logon after waking your Mac up).
First, in Terminal, create a script that reloads the bluetooth subsystem:
cat > bt_restart <<END
#!/bin/sh
kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport &&
kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
END
chmod +x bt_restart
Second, make root its owner and move it to /sbin:
sudo chown root:wheel bt_restart
sudo mv bt_restart /usr/local/sbin
Third, add the command to the list of NOPASSWD commands in sudoers:
echo -e "nn# Restart bluetooth without passwordn$USER ALL=(ALL) NOPASSWD: /usr/local/sbin/bt_restart" | EDITOR='tee -a' sudo visudo
Finally, create a script on your desktop that calls bt_restart:
echo '#!/usr/bin/sudo /usr/local/sbin/bt_restart' > ~/Desktop/"Restart Bluetooth"
chmod +x ~/Desktop/"Restart Bluetooth"
Done! Just double-click with your notebook's trackpad (or USB mouse) on the Restart Bluetooth on your Desktop.
Answered by Ezequiel Tolnay on December 6, 2021
After trying to run the scripts suggested by other answers, unloading and reloading both the kext and the bluetooth daemon, my bluetooth still wasn't responding.
However, I have discovered that if Yosemite sleeps with VMWare running and bluetooth doesn't work when the OS is woken up, closing VMWare rectifies the issue.
It seems that the drivers in VMWare don't always handle the sleep / wake process correctly.
Answered by TheDarkKnight on December 6, 2021
Thanks to Tyilo from the comments on the accepted answer, I have modified his script to install sleepwatcher and append to the script some code that will not only unload the Bluetooth driver (com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
), but also restart blued
, Apple's Bluetooth daemon.
The script can be found here: https://gist.github.com/timgws/fc63aeca6a248bbb25ff
Running this has resolved all the issues for me.
Answered by Tim Groeneveld on December 6, 2021
Mikaey's solution on the apple support forum:
This has solved the issue for me.
Answered by kingliam on December 6, 2021
I had the same problem and I think I spotted a possible cause of the problem. My mouse was called "My Name's mouse" with the apostrophe, maybe that was causing the errors.
I have changed the name to avoid using spaces and special characters, now is called just "mymouse" and I don't seem to have the problem anymore.
Answered by Leenyx on December 6, 2021
I've had issues reconnecting my bluetooth keyboard & trackpad since upgrading to Yosimite.
First try this: Open Terminal & run 2 commands:
sudo kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
sudo kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
I only had to run above once. If later bluetooth breaks again 2 options, simply run above again or you can create a 1-click solution with a simple app using Automator:
Replace (* Your script goes here *) with:
do shell script "kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport;
kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport" with administrator privileges
Run the automator app whenever bluetooth devices won't connect
Answered by webaholik on December 6, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP