Bug 475209 - Enabling/disabling bluetooth not working
Summary: Enabling/disabling bluetooth not working
Status: RESOLVED WORKSFORME
Alias: None
Product: Bluedevil
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: 5.27.8
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Rosca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-04 11:21 UTC by Henning
Modified: 2024-01-31 19:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henning 2023-10-04 11:21:27 UTC
The checkbox does not work, which is crazy. Bluetooth is always disabled, which is a battery drain and privacy and security risk.

Reproduce:
1. Pair bluetooth headphones / Speakers and set them as sound output in the "Volume" applet
2. Turn the speakers off so they disconnect
3.  Disable Bluetooth via the checkbox
4. Turn the headphones / speakers on again.

What happens: they connect! This is crazy and indicates that at least saved devices are automatically pairing. Does the checkbox only disable the scanning? It can't fully, as the device has to be searched, even if its ID is recognized.

This means the device is permanently visible, with its name not changeable through a GUI, leaking maybe sensible information to for example bluetooth tracking beacons.

What should happen:
- put a polkit exception or otherwise allow the checkbox to run this command, without password prompt, when the user is wheel:

pkexec systemctl disable bluetooth.service

Maybe this could work?


sudo cat > /etc/polkit-1/rules.d/99-bluetooth.service <<EOF
> polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "bluetooth.service" &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});
EOF

sudo systemctl restart polkit



The service that needs the polkit password is "org.freedesktop.policykit.exec".
Comment 1 Henning 2023-10-04 11:22:45 UTC
What should happen:
- put a new checkbox or simply replace the command to actually disable the bluetooth service. By default its on anyways, so no UX features will be harmed. But KDE with its complex GUI needs to be just as transparent, and this is a dangerous false promise

Imagine running KDE on Tails and having Bluetooth always running.
Comment 2 Henning 2023-10-04 11:23:52 UTC
The restriction to wheel should be discussed. Maybe add another group too, as it may be good to use a system as non-sudoer
Comment 3 Nicolas Fella 2023-10-04 14:13:46 UTC
The checkbox disables bluetooth via rfkill. You seem to suggest that's not working as expected, but it is for me
Comment 4 Henning 2023-10-04 18:39:34 UTC
Specified App:
bluez-libs-5.70-1.fc38.x86_64
bluez-5.70-1.fc38.x86_64
kf5-bluez-qt-5.109.0-1.fc38.x86_64
bluez-cups-5.70-1.fc38.x86_64
bluedevil-5.27.8-1.fc38.x86_64
NetworkManager-bluetooth-1.42.8-1.fc38.x86_64

--- Software ---
OS: Fedora Linux 38.20231004.0 (Kinoite)
KDE Plasma: 5.27.8
KDE Frameworks: 5.109.0
Qt: 5.15.10
Kernel: 6.5.5-200.fc38.x86_64
Compositor: wayland

--- Hardware ---
CPU: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx
RAM: 21.4 GB
GPU: AMD Radeon Vega 8 Graphics
Video memory: 2048MB
Audio: Pipewire
Comment 5 Nate Graham 2023-10-11 20:30:32 UTC
Yeah, it's working for me too.

What exactly happens visually when you click the checkbox? Nothing?
Comment 6 Henning 2023-10-11 21:06:51 UTC
When clicking the checkbox and a device is still connected as audio sink, sometimes the applet just crashes. Another reported bug I think.

When nothing is connected, first nothin happens but the check is gone, then after 5s or so the whole applet changes to the "enable bluetooth" display.

Reproducing the exact thing I did is still possible.

For interest, they are sennheiser PXC550-II headphones with multipairing, so multiple devices can connect at once, and the headphones pause the currently playing device if the other one starts playing something. Works well on Fedora
Comment 7 Nate Graham 2023-10-12 22:50:01 UTC
Can you use the `rfkill` command-line program to disable your bluetooth adapter adequately? Can you try?
Comment 8 Bug Janitor Service 2023-10-27 03:45:41 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Henning 2023-10-29 23:11:44 UTC
didnt find the right command yet
Comment 10 Nate Graham 2023-10-30 18:52:04 UTC
Please do so :)
Comment 11 Henning 2023-11-11 15:40:26 UTC
So when running 

sudo rfkill block bluetooth

The bluetooth disables itself perfectly in the applet. And it can be enabled from there too.
Comment 12 Nicolas Fella 2023-11-17 22:24:45 UTC
Nate, this title change does not make sense. We disable Bluetooth via rfkill already
Comment 13 Nate Graham 2023-11-17 22:27:57 UTC
Hmm, in that case it's not clear why it's not working for the reporter.
Comment 14 Henning 2023-11-19 01:29:26 UTC
Yes in fact it makes no sense. rfkill seems to correlate normally with this applet, but I will try to reproduce this exact bahavior.

Also still, when having a device connected and disabling bluetooth, the applet may freeze until the device is disconnected first and then the bluetooth is disabled, which takes weirdly long (5s or more) but this will only be vaguely related
Comment 15 Henning 2024-01-31 19:52:05 UTC
I cannot reproduce this on Plasma 6 prerelease, closing for now