bluetoothctl No default controller available [closed]

It's a bit wired here.

I have a problem is bluetoothctl always said "No default controller available". I found there are many people had same problem with me. But the situation is a bit different from them.

I can see my hciconfig -a have information like below

And hcitool dev seems no problem as well.

But I have no idea why my bluetoothctl always said "No default controller available"

Even when I turn down and turn up hci0 several times. It always in the same problem.

BTW, my BlueZ is 5.39. And I tried this experiment on buildroot. Kernel is 3.10

7 Answers

Had the same problem. Use: $ sudo bluetoothctl

Then the controller was found automatically. I also tried before. Maybe this effected the solution.

Also happens if rfkill switch is blocking Bluetooth (for some inadvertent reason, in my case):

$ rfkill list all 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: yes Hard blocked: no 

To unblock, pass the ID for your Bluetooth device from the list above to the unblock subcommand:

$ rfkill unblock 0 

Then controller should be back:

$ bluetoothctl list Controller .... [default] 

Here are the steps that worked for me by modifying the bluez config and the run without sudo:

• Create a "bluetooth" group which will be granted with <allow send_destination="org.bluez"/> on bluez's d-bus config

$ sudo groupadd bluetooth

• Open the config in /etc/dbus-1/system.d/bluetooth.conf with your favorite text editor

  e.g.

$ sudo vi /etc/dbus-1/system.d/bluetooth.conf

• Add/append the following lines below in /etc/dbus-1/system.d/bluetooth.conf

  
  <policy group="bluetooth">
<allow send_destination="org.bluez"/>
</policy>

• Save your changes.

• Add your login user to "bluetooth" group

$ sudo usermod -a -G bluetooth <loginuser>

• Reboot the system.

• Then try to use "bluetoothctl" without sudo

  $ bluetoothctl
  [bluetooth]# show

Its an old thread, but might help someone looking for answers.

I have faced this problem most of the times, and the things I verify are:

1. systemctl status bluetooth == this checks if the bluetooth service daemon is already running or not. Check for output:
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) If not, start it using the command: sudo systemctl start bluetooth

2. using sudo bluetoothctl

one of these two was the culprit usually.

I had this problem with VanillaArch on Linux Kernel 5.12. After struggling for a day I found the problem is:

1. Some of bluetooth devices firmware are not available in the new linux libraries right out of the box and you need to find. for this problem you can refer to the following repo. In readme it's well documented what you should do. basically you 'd download and copy the frimware in

/lib/firmware/brcm

for Broadcom Bluetooth devices.

2. Activation of two conflicting services on Bluetooth. Referring to "SayantanRC" on Arch froum :

When I compared between the two, I found these two services were enabled on my Manjaro installation, but disabled on my Arch linux installation:

blueman-mechanism.service bluetooth-mesh.service 

Disabled them and rebooted.

sudo systemctl disable blueman-mechanism.service sudo systemctl disable bluetooth-mesh.service 

Now the services are as below:

~ >>> systemctl list-unit-files | grep blue blueman-mechanism.service disabled disabled bluetooth-mesh.service disabled disabled bluetooth.service enabled disabled dbus-org.bluez.service alias - bluetooth.target static - ~ >>> 

And voila, bluetooth is up!

~ >>> bluetoothctl Agent registered [CHG] Controller 68:07:15:DE:1F:15 Pairable: yes [bluetooth]# show Controller 68:07:15:DE:1F:15 (public) Name: src-manjaro Alias: src-manjaro Class: 0x00000000 Powered: no Discoverable: no DiscoverableTimeout: 0x000000b4 Pairable: yes UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: Headset (00001108-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0537 Discovering: no Roles: central Roles: peripheral Advertising Features: ActiveInstances: 0x00 (0) SupportedInstances: 0x05 (5) SupportedIncludes: tx-power SupportedIncludes: appearance SupportedIncludes: local-name [bluetooth]# quit 

EDIT: For verification purpose, I re-enabled the services and bluetooth adapter was having trouble again. I disabled them and it is fine now. Checked on kernel 5.9 and 5.4.

The answer above probably works on some distributions, but may get you into trouble in others. Unfortunately, it seems that every distribution has a different default configuration for Bluetooth - it's a pretty awful mess IMHO.

Here's what worked for me on a Debian derivative Raspberry Pi OS (née Raspbian):

As a preliminary check, on many distros you can check /etc/group to see if a group name bluetooth exists:

$ cat /etc/group | grep blue 

If it exists, you obviously don't need to add the group, only add users to the group:

$ sudo usermod -G bluetooth -a <username> 

In the distro I'm using, this was all that was required to make the Controller responsive in bluetoothctl.

I had the same issue. After a long research found out that the driver was not installed. Check that answer and see if your drivers are installed correctly =)