search

toy / blueutil

CLI for bluetooth on OSX: power, discoverable state, list, inquire devices, connect, info, …
https://github.com/toy/blueutil
Other
1.01k stars 53 forks source link

Setting Discoverable as Root Disables Discoverability for the System #41

Closed Brikwerk closed 3 years ago

Brikwerk commented 3 years ago

The Problem

Using blueutil as a root user and setting discoverability causes the system to lose the ability to be discovered over Bluetooth.

Replicating the Issue

To replicate this bug (which I advise against replicating since I haven't been able to reverse it), run the following:

sudo blueutil -d 1

Attempted Debugging

I've tested a couple different configurations to double check that one device wasn't simply refusing to acknowledge my Mac. I'll list out a few things I tried:

  1. Opening the Bluetooth Preferences menu and checking if the Mac was discoverable on an iPhone, iPad, Linux laptop, and a Raspberry Pi.
  2. Setting the discoverability to 1 in blueutil as a regular user and checking on the same devices.
  3. Setting the discoverability to 1 in blueutil as a root user and checking on the same devices.

In an attempt to remedy this issue I have:

I suppose a last ditch effort could be to reinstall MacOS, however, I'm a little loathe to do this since it's a bit of a minor issue.

I've also tested running the above command on another MacBook Pro with similar results occurring. I'll list the specs of the two laptops below, for some extra info (this could be a Catalina specific issue, maybe?)

On a side note, both systems above were able to use blueutil as a regular user (before encountering the bug) and set discoverability such that they were able to show up on other devices.

Extra Information

Things also get a little weirder if you check the discoverable values as a regular user and a root user. The two values don't seem to coincide? Eg: If discoverable is 0 for both root/a regular user and I set discoverable as root, the regular user will still see discoverable as zero. For a further example:

blueutil -d
> 0
sudo blueutil -d
> 0
sudo blueutil -d 1
sudo blueutil -d
> 1
blueutil -d
> 0

My guess is that something has been written to that shouldn't have been written to as root? Honestly, this is a little outside my expertise. I'm a bit of a layman when it comes to the inner-workings of MacOS. Any input on a solution to this would be much appreciated!

toy commented 3 years ago

Interesting issue. I am a bit wary trying to reproduce it :) Could you try creating another user and login in (probably better to not fast-user-switch) and checking if discoverability works? Discoverability is at least written to ~/Library/Preferences/ByHost/com.apple.Bluetooth.*.plist (note * which is the uuid of the system), not sure if it will help, but check the owner of that file.

Brikwerk commented 3 years ago

Thanks for looking into this! Totally reasonable that you'd be wary about reproducing, haha. Not a super enjoyable bug to experience, especially when I'm trying to do Bluetooth dev on Mac. Anyways, I've had some time to experiment with this issue more.

Unfortunately, things have gotten a little weirder. I restarted my main machine once more for other reasons and now I actually can't get the system to stop being discoverable. This means I have the exact opposite issue from what I wrote above. I ran through the above steps I detailed to try and correct, yet still I can't toggle discoverability.

Anyways, since I'm functionally in the same position (unable to control discoverability), I went ahead with creating a new user, testing discoverability, and looking at the Bluetooth plist. I'll detail some of the things I tried below in chronological order.

I did notice, however, that non-root blueutil writes to ~/Library/Preferences/ByHost/com.apple.Bluetooth.*.plist just fine. I was able to observe this value toggling on and off with the appropriate commands. I also noticed that root blueutil doesn't write to this value, however, changes with root blueutil are still tracked. It seems to be writing elsewhere, possibly.

toy commented 3 years ago

I'm already thinking that to prevent the problem code can be added that will check process uid not to be 0 and adding an environment variable to override the restriction, but better to find how to fix it first to ensure that it is really caused by setting discoverability as root.

Few things you can try:

dave4jr commented 3 years ago

@toy @Brikwerk Hey guys, I've also ran into this issue doing the same thing as above. My bluetooth can no longer connect to any device. I've noticed that when opening Bluetooth Explorer > Tools > HCI Controller Selector, there's no longer any controller in the list here. I actually did try reinstalling the entire operating system and it did not help. I just updated to BigSur and still an issue. I've purchased another USB Bluetooth and that is working. Also, in my console, I'm seeing an error happen over and over:

Screen Shot 2020-11-13 at 4 01 31 PM
Brikwerk commented 3 years ago

@dave4jr I think our machines are exhibiting slightly different issues. I'm able to pair/connect/reconnect with other Bluetooth devices on the affected machines. The only symptom I'm seeing is the inability to toggle discoverability. Also, I believe the HCI Controller Selector won't actually list the default Apple Bluetooth adapter. I quickly checked this on an unaffected Mac and "None" was listed.

@toy I've found time to do some more debugging with the steps you listed in your reply.

I do, however, have some other interesting results:

Edit: Quick update, I'm seeing the Bluetoothd(208) error occurring consistently about every 10-11 seconds now for over an hour. I think I'm getting these errors regardless of whether the preferences pane is open or not.

dave4jr commented 3 years ago

@Brikwerk Oh okay, thanks for the clarification. I'm a software developer but all the iOS dev I've done is through React Native so I'm really lacking in knowledge when it comes to diagnosing this issue, and the fact that my bluetooth seems completely bricked is really unfortunate. I know it was after I ran this program. I tried all of the solutions you mentioned in your original post as well. Have you seen the console error message I posted in my last message? "CoreBluetooth isn't advertising on client type 9". I have no idea what that is and have tried searching high and low on the web. Any help would be truly appreciated!

toy commented 3 years ago

@dave4jr Sounds weird. If you have reinstalled the system, then the problem is not in system files/configs as it most probably is for @Brikwerk. Can you describe exact steps that led to the problem that you have? It is probably better to extract it as a separate issue.

@Brikwerk I've successfully reproduced the issue. After running sudo blueutil -d 1 discoverability state got stuck in discoverable state. I used fs_usage -w in parallel and saw operations by cfprefsd with com.apple.Bluetooth.*.plist under /private/var/root/Library/Preferences/ByHost (directory are not readable, so sudo find /private/var/root/Library/Preferences/ByHost -name 'com.apple.Bluetooth*' can be used) and /Library/Preferences/com.apple.Bluetooth.plist. What I found after lots of restarts, retries, deleting files and trying to use defaults:

toy commented 3 years ago

@Brikwerk It would be great if you could try https://github.com/toy/blueutil/compare/refuse-to-run-as-root

Brikwerk commented 3 years ago

@toy Thanks for looking into this more and biting the bullet by reproducing! I can also confirm that deleting the two files you mentioned and restarting the affected systems was able to fix both.

I also built/ran the new branch and I can also confirm that the preventative measures are effective. I'm able to toggle discoverability normally as a non-root user. Running as root and attempting to toggle prints the new message and prevents triggering the bug.

toy commented 3 years ago

Awesome!

I've merged the change and released https://github.com/toy/blueutil/releases/tag/v2.7.0. I assume this issue can be closed and @dave4jr can open a new issue if needed.

Brikwerk commented 3 years ago

Great to hear! Thanks for your help/work on this issue @toy! Very much appreciated. I also think with the solution implemented, we can close this issue.

@dave4jr If your Bluetooth problems persist, I would open up another issue since your problem does sound like it might be more hardware-centric vs. configuration-based.