Undefined behaviour of bluez adapter power function Ubuntu 22.04

[Taha-Firoz]

Hello, I'm testing bluer on an Ubuntu 22.04 VM (host is windows 11) which has a separate linux compatible Bluetooth dongle passed through to it. Since I wasn't using a library that allowed me to change the power state of a bluetooth adapter I hadn't tried it before. However with bluer I added a feature where the bluetooth adapter is powered off then powered on after a few seconds to ensure everything is in a correct state.

This apparently breaks Bluetooth for some reason, and this isn't because of bluer but just an issue I noticed with bluez. If I do the same thing with bluetoothctl where I power on and then power off the adapter it doesn't function properly. The weird part I don't understand is if I use the gnome control center Bluetooth panel and reset the adapter from there it begins to function properly. When debugging I noticed to check into rfkill and even when I use rfkill to remove any soft blocks on the hardware but I still try to power on the dongle via bluetoothctl I get the same behavior.

The only difference I've noticed between how gnome-control-center's method of disabling bluetooth is that it goes into airplane mode through it's own rfkill dbus api. If you disable Bluetooth via gnome-control-center it sends a call directly to rfkill instead of bluetoothd but I don't see any other reference of bluez so I may not be looking at the full source. Anyway I've gotten everything to work by just spamming the Bluetooth toggle in gnome-control-center but is there a better way, a more programmatic way where I can reset Bluetooth or is this issue specific to my setup where I have my dongle passing through to a VM. The only reason I'm even considering resetting Bluetooth because some times I don't get any scan results until I reset it a couple of times.

[surban]

Please test this on a real machine, not in a VM.

I don't think you can reliably pass-through a Bluetooth adapter because Windows has probably loaded its firmware on the controller before passing it through the VM.

Also note that powering the adapter on and off is not resetting it. You could try unloading and loading the appropriate kernel module instead.

[Taha-Firoz]

I'm not sure if what I'm about to say is entirely accurate, as I have limited experience with Linux-related matters. However, I've observed that the Bluez power toggle feature seems to be inconsistent, at least on my setup (Windows 11 Host, Bluetooth adapter passed through, Ubuntu 22.04 on VMWare, Bluez v5.64).

My observations were made using btmon, rfkill, and bluetoothctl.

Expected Behavior:

When using bluetoothctl, I can usually power the adapter on and off as needed. Each command to toggle power through bluetoothctl generates events on both rfkill and btmon. These events indicate the state the adapter has been toggled to.

Unexpected Behavior:

However, I've noticed that if I use bluetoothctl to toggle power multiple times or sometimes during a scan, the power toggle stops working. This issue also occurs occasionally after a fresh boot of the VM. When this happens, bluetoothctl returns various errors, such as "Failed" or "Busy". At this point, no calls to anything in bluetoothctl work, and I can neither enable nor disable the power, nor can I change the scan.

It seems like Bluez fails to call rfkill correctly when this issue occurs. I've noticed this when replicating the issue: after the first power-off call, rfkill doesn't receive an event, and bluetoothctl reports a dbus error. This failed power-off call leaves Bluez in an inconsistent state, where bluetoothctl can no longer interact with it. All calls to discover or power result in some dbus error.

Interestingly, btmon still shows that the adapter is functioning. I'm not sure about this behavior, but from what I've gathered, the safest way to restart the adapter is by using rfkill directly, instead of going through Bluez.

Bluez power toggle feature appears to be inconsistent, at least on my setup, and it seems that using rfkill directly is a more reliable way to keep a consistent the adapter's power state & bluez.