Switching airplain mode off enables bluetooth when previousely disabled

[DanWaLes]

blueman: 2.3.5
BlueZ: 5.64-0ubuntu1.1
Distribution: Mint 21.3
Desktop environment: Cinnamon 6.0.4

• [✔] I have consulted the Troubleshooting page and done my best effort to follow.

I edited the /etc/bluetooth/main.conf file to disable automatically connecting, saved it then restarted, logged in (bluetooth correctly disabled at start up), pressed F12 to enable airplane mode, waited a few seconds, pressed F12 to disable airplane mode and bluetooth switched itself on automatically. It should have remembered the previous state.

[infirit]

Blueman enables bluetooth automatically through the PowerManager plugin. You can change this in the plugin dialog

[DanWaLes]

In the PowerManager plugin, I have Auto power-on disabled. I've tried enabling and disabling it but the issue remains.

[infirit]

When you say F12, is that the laptop key to switch airplane mode? Is F12 also labeled as such or is this the/a keybind in cinnamon?

KDE Plasma 6 also has an airplane mode and I don't see the behaviour you describe. Enabling or disabling makes no difference in the actual power state of the adapter in blueman 2.4. I personally have no laptop that has a switch or button for airplane mode.

We have removed the auto powering of the adapter in the new stable version 2.4.

And can you post a log of blueman-applet from before you switch airplane mode and the adapter not being powered. Through airplane on and then airplane mode off. See this how to get a debug log https://github.com/blueman-project/blueman/wiki/Troubleshooting#debugging-blueman

[DanWaLes]

When you say F12, is that the laptop key to switch airplane mode?

yes

Is F12 also labeled as such or is this the/a keybind in cinnamon?

i've checked all the Shortcuts in Keyboard, F12 or any other name for it isn't used in any key binding

logging info https://pastebin.com/NQHy0PnB. first prompt it was disabled, second i pressed F12, third i pressed f12 again, fourth i disabled bluetooth

i recently changed from Windows 10 to a more favourable OS. in Windows 10 its called Airplane Mode, not sure if i'm using correct term here but it does the same behaviour of disconnecting from wifi and bluetooth if it wasnt already enabled.

[cschramm]

I don't think Cinnamon has something like that, so I'd expect that to be a hardware killswitch.

The adapter ends up powered? You can check e.g. in bluetoothctl show.

I'd exit blueman before the procedure to check if it plays a role.

[DanWaLes]

Is it a Cinnamon bug rather than a Blueman bug then?

[cschramm]

Well, something seems to power on the adapter when unblocked. I do not expect Cinnamon to do anything like that at all.

I think what you're doing with the key is to soft block a killswitch. You can check the states with rfkill. I quickly checked and bluetoothd does not power the adapter for me on unblock if AutoEnable is disabled. Neither does a running Cinnamon, blueman-applet or anything else. My system isn't 100 % representative there, though, as the device becomes unavailable when blocked and re-appears when unblocked.

[infirit]

It does power when I unblock a soft-blocked adapter. But his happens outside of blueman's control. Here is the output bluetoothctl when the initial state of the adapter is soft-blocked and blueman-applet isn't running.

[bluetooth]# hci0 new_settings: bondable ssp br/edr le secure-conn wide-band-speech 
[bluetooth]# Agent registered
[bluetooth]# [CHG] Controller 28:DF:EB:3D:A1:E8 Pairable: yes
[bluetooth]# [CHG] Controller 28:DF:EB:3D:A1:E8 PowerState: off-blocked
[bluetooth]# [CHG] Controller 28:DF:EB:3D:A1:E8 PowerState: off-enabling
[bluetooth]# hci0 class of device changed: 0x6c0104
[bluetooth]# [CHG] Controller 28:DF:EB:3D:A1:E8 Class: 0x006c0104 (7078148)
[bluetooth]# hci0 new_settings: powered bondable ssp br/edr le secure-conn wide-band-speech 
[bluetooth]# [CHG] Controller 28:DF:EB:3D:A1:E8 PowerState: on
[bluetooth]# [CHG] Controller 28:DF:EB:3D:A1:E8 Powered: yes

@DanWaLes I haven't looked at your log yet but when you put it in airplane mode, do you see the adapter soft-blocked when you run rfkill from a terminal. Is so unblocking it will almost certainly power it like it does for me.

[cschramm]

From a quick glance at the code it looks like BlueZ restores the power state for a known adapter on unblock. I expect it to power the adapter on if it was powered on before, independent of the AutoEnable option.

I would not expect it to power it on if it was powered off when getting blocked.

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/adapter.c#n7857

[DanWaLes]

before pressing the key, with wifi enabled and bluetooth disabled
daniel@daniel-HP-Pavilion-Notebook:~$ rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
2 bluetooth hci0 blocked unblocked

after first key press
daniel@daniel-HP-Pavilion-Notebook:~$ rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 blocked unblocked
2 bluetooth hci0 blocked unblocked

after second key press
daniel@daniel-HP-Pavilion-Notebook:~$ rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
2 bluetooth hci0 unblocked unblocked

i have AutoEnable as false

[DanWaLes]

thanks for finding where the issue comes from :)