Bluetooth's on/off status doesn't update from the SetProperty D-Bus method that bluetoothd sends

Bug #446657 reported by pablomme
540
This bug affects 123 people
Affects Status Importance Assigned to Milestone
GNOME Bluetooth
Unknown
Medium
The Ubuntu Power Consumption Project
New
Undecided
Unassigned
bluez (Fedora)
Won't Fix
Medium
bluez (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Karmic by Timo Aaltonen
Nominated for Lucid by papukaija
Declined for Maverick by Timo Aaltonen
linux (Ubuntu)
Invalid
Wishlist
Unassigned
Declined for Karmic by Timo Aaltonen
Nominated for Lucid by papukaija
Declined for Maverick by Timo Aaltonen

Bug Description

Binary package hint: gnome-bluetooth

Gnome's bluetooth applet should get a bluetooth device's on/off status through dbus from SetProperty setting sent by bluetoothd. This information was given in http://permalink.gmane.org/gmane.linux.bluez.kernel/4302 There is a setting controlling this feature: RememberPowered=true in /etc/bluetooth/main.conf

Questions:
Is the dbus message is even sent? If it is sent, why gnome-bluetooth doesn't do anything for it? Does bluez's SetProperty actually find the last (if even saved) bluetooth status?

ProblemType: Bug
Architecture: i386
Date: Thu Oct 8 20:54:15 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: wl
Package: gnome-bluetooth 2.28.1-0ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=es_ES.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
SourcePackage: gnome-bluetooth
Uname: Linux 2.6.31-12-generic i686

Revision history for this message
pablomme (pablomme) wrote :
Revision history for this message
papukaija (papukaija) wrote :

True, the on/off setting should not be lost on restart.

Changed in gnome-bluetooth (Ubuntu):
status: New → Confirmed
papukaija (papukaija)
tags: added: ubuntu-unr
Revision history for this message
Omer Akram (om26er) wrote :

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue , in the default Ubuntu 9.10 install , that affects many people and is quick and easy to fix. So this bug can't be addressed as part of the project.

its rather more like a feature request

For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

Don't worry though, This bug has been marked as "invalid" ONLY in the papercuts project.

Changed in hundredpapercuts:
status: New → Invalid
Revision history for this message
Omer Akram (om26er) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in gnome-bluetooth (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
papukaija (papukaija) wrote :

This bug is now sent to upstream (at https://bugzilla.gnome.org/show_bug.cgi?id=607334 ).

Changed in gnome-bluetooth (Ubuntu):
status: Incomplete → New
status: New → Confirmed
Revision history for this message
Charlie Kravetz (charlie-tca) wrote :

Set to triaged; status low as this is a nice to implement feature.

Changed in gnome-bluetooth (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Revision history for this message
papukaija (papukaija) wrote :

According to https://bugzilla.gnome.org/show_bug.cgi?id=598140#c2 this feature isn't gnome-bluetooth's job, but bluetoothd's (part of bluez). So do I change it here too?

Revision history for this message
Lightbreeze (nedhoy-gmail) wrote :

@papukaiji: For the Ubuntu task press "Also affects distribution" then change the package name in the box that appears.

Vish (vish)
affects: gnome-bluetooth (Ubuntu) → bluez (Ubuntu)
Changed in bluez (Ubuntu):
status: Triaged → New
papukaija (papukaija)
Changed in bluez (Ubuntu):
status: New → Confirmed
papukaija (papukaija)
summary: - gnome-bluetooth should store user-selected bluetooth on/off status and
- apply it when loading the applet
+ Should store user-selected bluetooth on/off status and apply it when
+ loading the applet
Revision history for this message
papukaija (papukaija) wrote : Re: Should store user-selected bluetooth on/off status and apply it when loading the applet

Where is the upstream bug reporting system for bluez?

Revision history for this message
Vish (vish) wrote :

@papukaija: http://wiki.bluez.org/report/1 seems to be the place to report the issue

affects: hundredpapercuts → utils
Changed in utils:
status: Invalid → New
Revision history for this message
papukaija (papukaija) wrote :

Vish: I found that, but there is no login/signup page to submit bugs.

Revision history for this message
Vish (vish) wrote :

@papukaija: Yes , the filing of bugs seems a bit weird. :(
However i had a quick look , Try getting some info from these links>
http://wiki.bluez.org/wiki/TracReports
http://wiki.bluez.org/wiki/TracGuide
http://trac.edgewall.org/wiki/TracFaq

If all else fails , try contacting the devs directly > http://www.bluez.org/contact/
I didnt have time to dig deeper. thanks for looking into this.

Revision history for this message
papukaija (papukaija) wrote :
Revision history for this message
papukaija (papukaija) wrote :

Sorry, the correct link is:
http://comments.gmane.org/gmane.linux.bluez.kernel/4287

And it seems that this feature is already implemented, but for some reason not working in Ubuntu.

Revision history for this message
papukaija (papukaija) wrote :

I'm going to edit this bug's title and description since this feature request is implemented,but for some reason not working in Ubuntu.

papukaija (papukaija)
affects: bluez (Ubuntu) → gnome-bluetooth (Ubuntu)
papukaija (papukaija)
description: updated
Revision history for this message
papukaija (papukaija) wrote :

For some reason I can't change this bug's title to "Doesn't get the bluetooth's on/off status from the SetProperty D-Bus method that bluetoothd sends"

Vish (vish)
summary: - Should store user-selected bluetooth on/off status and apply it when
- loading the applet
+ Bluetooth's on/off status doesn't update from the SetProperty D-Bus
+ method that bluetoothd sends
Revision history for this message
Սահակ (petrosyan) wrote :

this bug has been fixed in Ubuntu 10.04

Revision history for this message
Vish (vish) wrote :

Սահակ , I'm using Ubuntu 10.04 and its _not_ fixed for here.

Revision history for this message
Baptiste Mille-Mathias (bmillemathias) wrote :

Not a gnome-bluetooth problem

affects: gnome-bluetooth (Ubuntu) → ubuntu
Changed in ubuntu:
status: Confirmed → Invalid
status: Invalid → Confirmed
Revision history for this message
Baptiste Mille-Mathias (bmillemathias) wrote :

Rather on bluez

affects: ubuntu → bluez (Ubuntu)
Revision history for this message
Baptiste Mille-Mathias (bmillemathias) wrote :

Honnestly this bug is a mess, the title is "Bluetooth's on/off status doesn't update from the SetProperty D-Bus method that bluetoothd sends" but th epeople complains about non-remembering the power status after computer reboot, which is *totally* different.

Revision history for this message
pablomme (pablomme) wrote :

@Baptiste: please read the full bug history. This bug was initially reported against gnome-bluetooth, forwarded upstream, rejected, then moved against bluez, forwarded upstream, and confirmed non-existent there. This turns out to be an Ubuntu-specific problem that prevents bluez from using its existing feature of loading the previously recorded on/off state, which is caused by a dbus communication issue or, most likely, inaction on the dbus communication between gnome-bluetooth and bluetoothd.

The bug title is correct and the comments are on-topic. The only messiness stems from the fact that this bug has required reporting to two different upstreams to discover the nature of the problem, but that's just the way things have panned out.

Please reconsider whether you really wish to move the bug against bluez again.

Revision history for this message
papukaija (papukaija) wrote :

@Baptiste: Please read http://permalink.gmane.org/gmane.linux.bluez.kernel/4302

@All: I'm going to re-assign this bug for gnome-bluetooth and to remove the bug watcher since it was created for the feature request. Should this bug be opened for dbus too?

affects: bluez (Ubuntu) → gnome-bluetooth (Ubuntu)
Changed in gnome-bluetooth:
importance: Unknown → Undecided
status: Unknown → New
Revision history for this message
papukaija (papukaija) wrote :

It's of course possible that the dbus message in question is not sent by bluetoothd's (part of bluez).

I'm setting the external tracker to invalid since this bug seems to be an Ubuntu specific problem (see comment 22 and http://permalink.gmane.org/gmane.linux.bluez.kernel/4291 ).

Changed in gnome-bluetooth:
status: New → Invalid
Revision history for this message
papukaija (papukaija) wrote :

Is there a way to debug this bug?

Revision history for this message
Vish (vish) wrote :

@Baptiste Mille-Mathias : How do we proceed with this bug? bluez says its not their bug . And everyone else says its a bluez bug.

I had filed a similar bug [ Bug #503286 ] regarding the hardware switch not remembering the bluetooth state.
And kernel upstream also mentioned that the bug needs fixing in bluez

Attaching my /etc/bluetooth/main.conf
upstream bluez mentions it works with the git version. is this an ubuntu bug?

papukaija (papukaija)
Changed in bluez-utils:
status: New → Invalid
Revision history for this message
papukaija (papukaija) wrote :

In main.conf, there is:

# What value should be assumed for the adapter Powered property when
# SetProperty(Powered, ...) hasn't been called yet. Defaults to true
InitiallyPowered = true

If you set this to false, the bluetooth-applet will show bt as disabled regardless of your bt status at logout. This means that gnome-bluetooth doesn't get the SetProperty dbus message sent by bluetoothd.

So should this bug be opened for dbus and/or for bluez?

papukaija (papukaija)
tags: added: karmic lucid
Revision history for this message
Vish (vish) wrote :

Even if set :
InitiallyPowered = false

I find the hardware bluetooth light always on for every boot.

Revision history for this message
Alexander Sack (asac) wrote :

this would require us to change main.conf to:

# What value should be assumed for the adapter Powered property when
# SetProperty(Powered, ...) hasn't been called yet. Defaults to true
InitiallyPowered = true

# Remember the previously stored Powered state when initializing adapters
RememberPowered = true

however, this causes problems for some users so we shouldn't change this that late this cycle. lets try it next cycle.

affects: gnome-bluetooth (Ubuntu) → bluez (Ubuntu)
Changed in bluez (Ubuntu):
importance: Low → Wishlist
status: Confirmed → Triaged
Revision history for this message
papukaija (papukaija) wrote :

Wait wait. Those are the default values. So, we're back in finding out why gnome-bluetooth doesn't get the SetProperty dbus message sent by bluetoothd. How to debug dbus?

Changed in bluez (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
Gleb Kozyrev (gkozyrev) wrote :

In my case (on lucid) dbus seems to be working just fine: the applet is able to switch bluetooth on/off and is correctly notified when switched via rfkill.
Still bluetooth is always on at startup regardless of the applet and InitiallyPowered/RememberPowered settings. Should this be filed as a separate bug? It might get bounced between upstreams the same way :(
BTW, where is Powered state supposed to be stored when RememberPowered = true? Looking for modified files with find / ~/ -newermt '2 min ago' gives me nothing but log files.

Revision history for this message
pablomme (pablomme) wrote :

I was about to add that this bug seems fixed in lucid, but clearly Gleb's comment indicates otherwise. Mine is a clean 32-bit install from beta 2 - Gleb, how does your installation differ from mine?

Revision history for this message
Vish (vish) wrote :

Doesnt work for me either in Lucid.
Every boot i have to turn the bluetooth LED off using the kill switch.

Revision history for this message
Gleb Kozyrev (gkozyrev) wrote :

Mine is 64-bit. I've installed a fresh ubuntu-10.04-beta2-desktop-amd64 today and bluetooth is always on after boot.

Revision history for this message
papukaija (papukaija) wrote :

Gleb (about your comment 31): The only bug reported in this bug report is that bluetooth on/off status isn't remembered on boot.

All: How to debug bluez to see if the dbus message is even sent? If it is sent, why gnome-bluetooth doesn't do anything for it? Or to see if bluez's SetProperty actually finds the last (if even saved) bluetooth status?

Revision history for this message
papukaija (papukaija) wrote :

Please remove the wishlist importance since this is a real bug.

description: updated
Revision history for this message
papukaija (papukaija) wrote :

Has anyone tried to reproduce this bug in Maverick?

tags: added: not-a-wishlist
Revision history for this message
Vish (vish) wrote :

@papukaija : In Lucid , I'v tested with mainline Kernel .34 and .35 , both of which remember the killswitch state of the previous session. Bug might have been in the kernel?
Could you try the mainline kernels too? https://wiki.ubuntu.com/KernelMainlineBuilds

Revision history for this message
papukaija (papukaija) wrote :

@Vish: That would explain why bluez.org can't confirm this bug. I'll test with 2.6.34-lucid and 2.6.35-rc1-lucid soon. Is your attached main.conf a file with default settings because I'm not sure if my file has the defaults, especially about the "RememberPowered" setting?

Revision history for this message
Vish (vish) wrote :

@papukaija : InitiallyPowered and RememberPowered are both true by default.

papukaija (papukaija)
tags: added: hw-specific ubuntu-une
removed: ubuntu-unr
papukaija (papukaija)
tags: added: maverick
papukaija (papukaija)
tags: added: natty
papukaija (papukaija)
tags: added: oneiric
papukaija (papukaija)
affects: bluez (Ubuntu) → linux (Ubuntu)
Changed in bluez (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Invalid
no longer affects: gnome-bluetooth
no longer affects: bluez
tags: removed: not-a-wishlist
tags: added: precise
Changed in bluez (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti)
Changed in bluez (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → Mathieu Trudel-Lapierre (mathieu-tl)
Changed in gnome-bluetooth:
importance: Unknown → Medium
status: Unknown → New
Changed in bluez (Ubuntu):
assignee: Mathieu Trudel-Lapierre (mathieu-tl) → nobody
papukaija (papukaija)
tags: added: battery-power-consumption
tags: removed: ubuntu-une
Sam_ (and-sam)
tags: added: amd64
papukaija (papukaija)
tags: added: quantal
removed: karmic maverick
59 comments hidden view all 139 comments
Revision history for this message
In , tommy (tommy-redhat-bugs) wrote :

I have same problem, after disable bluetooth using command

systemctl disable bluetooth.service

bluetooth still shown after restart. I've to kill blueman-applet every time I boot my system.

I'm using Fedora 18 XFCE.

Revision history for this message
In , grawert (grawert-redhat-bugs) wrote :

I had the same issue on a Lenovo X1. The problem seems not to be gnome-bluetooth or any bluetooth daemon. For Lenovo laptops there is the thinkpad-acpi kernel module. That module is activating bluetooth. I did the following:

# modprobe -r thinkpad_acpi
# modprobe -v thinkpad_acpi
insmod /lib/modules/3.7.6-201.fc18.x86_64/kernel/drivers/platform/x86/thinkpad_acpi.ko fan_control=1

Bluetooth is actived now! There is a module parameter bluetooth=0, but it is not recognized as of thinkpad_acpi module version 0.24. The documentation is also mentioning that many paramters are deprecated, and rfkill shall be used. When examining with rfkill, the following blocked states are set after module loading:

# rfkill list bluetooth
3: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
4: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no

As soon as I turn on "soft blocking" for bluetooth, it gets disabled:

# rfkill block bluetooth
# rfkill list bluetooth
3: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no

Bluetooth is deactivated now.

I added "rfkill block bluetooth" to /etc/rc.d/rc.local. During boot the bluetooth LED is active when the thinkpad_acpi module is loaded, but turns off, as soon as rc-local.service unit has been reached.

Revision history for this message
In , beland (beland-redhat-bugs) wrote :

*** Bug 911093 has been marked as a duplicate of this bug. ***

papukaija (papukaija)
Changed in bluez (Ubuntu):
status: Confirmed → Incomplete
papukaija (papukaija)
Changed in bluez (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
In , mwp.junk (mwp.junk-redhat-bugs) wrote :

I have two laptops running F18 and F19, complete installs, and both exhibit the same issue. The F18 laptop is a Dell XPS 17 (LX720x) with a 3.9.6 kernel and the F19 is a Dell Latitude D830 with 3.9.8 kernel.

Interacting with the top-bar bluetooth applet doesn't have any affect on the bluetooth led.

'sudo systemctl stop bluetooth.service' && 'sudo systemctl disable bluetooth.service' won't turn it off either despite 'sudo systemctl status bluetooth.service' saying it's dead (inactive) and the systemd journal showing bluetoothhd was stopped.

'sudo chkconfig --list | grep bluetooth' doesn't show it running and 'chkconfig bluetooth off' just forwards to systemctl disable bluetooth.service.

Revision history for this message
In , hub+rhbz (hub+rhbz-redhat-bugs) wrote :

You might want to refer to this upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=638117

papukaija (papukaija)
tags: added: raring
removed: lucid natty oneiric
Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
In , jpazdziora (jpazdziora-redhat-bugs) wrote :

I currently have

#!/bin/bash
echo disable > /proc/acpi/ibm/bluetooth

in my /etc/rc.d/rc.local so I will no longer attempt to keep this bugzilla open for proper resolution. Someone else who still cares might want to pick up the flag.

Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Revision history for this message
In , jshubin (jshubin-redhat-bugs) wrote :

Still present on F20, and annoying hackers everywhere :)

Revision history for this message
In , mskinner (mskinner-redhat-bugs) wrote :

I have a T530 - even though I have bluetooth disabled in the KDE settings, the /proc/acpi/ibm/bluetooth had it enabled.

I am running the latest BIOS as well.

Revision history for this message
In , mskinner (mskinner-redhat-bugs) wrote :

I have a T530 - even though I have bluetooth disabled in the KDE settings, the /proc/acpi/ibm/bluetooth had it enabled.

I'm running F20.

I am running the latest BIOS as well.

Revision history for this message
In , sbonazzo (sbonazzo-redhat-bugs) wrote :

Same here on F19 on T530.

Revision history for this message
In , eminguez (eminguez-redhat-bugs) wrote :

Systemctl workaround:

echo "w /proc/acpi/ibm/bluetooth - - - - disable" >> /etc/tmpfiles.d/disable-bluetooth.conf

Revision history for this message
In , bnocera (bnocera-redhat-bugs) wrote :

systemd is supposed to remember and restore rfkill status. If that doesn't work, it could be a problem with systemd's implementation, or with the kernel implementation of the device specific rfkill (the thinkpad_acpi module is known to be problematic).

Punting to systemd.

Changed in gnome-bluetooth:
status: New → Unknown
Revision history for this message
In , htl10 (htl10-redhat-bugs) wrote :

(In reply to Bastien Nocera from comment #32)
> systemd is supposed to remember and restore rfkill status. If that doesn't
> work, it could be a problem with systemd's implementation, or with the
> kernel implementation of the device specific rfkill (the thinkpad_acpi
> module is known to be problematic).
>
> Punting to systemd.

It is certainly not being remembered. FWIW, I have toshiba_bluetooth module; and I keep having to turn it off at the user-settings; it seems to be forgotten whenever reboot/logout.

Revision history for this message
In , pspacek (pspacek-redhat-bugs) wrote :

I confirm the same issue on T540 running latest Fedora 21.

Revision history for this message
In , wgqiwt (wgqiwt-redhat-bugs) wrote :

Same on lenovo w530 centos 6

Revision history for this message
In , jshubin (jshubin-redhat-bugs) wrote :

On Fedora 21.
Bluetooth is off.
Turn wifi switch off, then on.
Bluetooth turns itself on again!

Argghhh...

Revision history for this message
In , beland (beland-redhat-bugs) wrote :

According to https://bugzilla.gnome.org/show_bug.cgi?id=638117 systemd 209 fixes this for at least some hardware.

I can confirm this fix on Fedora 21 with my Macbook Air running systemd-216-24.fc21.x86_64; Bluetooth stays off after reboot if set that way. Also according to that external bug, there may be additional bugs in the hardware-specific kernel bluetooth drivers.

It sounds like if we want this fixed, then, we should report new hardware-specific bugs against the kernel. On my MacBook, "lsmod | grep rfkill" reports:

rfkill 21980 5 cfg80211,bluetooth

I also have a Lenovo ThinkPad running Fedora 19, and it lists users of rfkill as cfg80211,thinkpad_acpi,bluetooth. For those that are running Fedora 21 and seeing this problem still, what modules do you see there?

The upstream bug also mentions this as a manual workaround:

/etc/modprobe.d/rfkill.conf:

options rfkill master_switch_mode=0

Revision history for this message
In , ledufff (ledufff-redhat-bugs) wrote :

(In reply to James (purpleidea) from comment #36)
> On Fedora 21.
> Bluetooth is off.
> Turn wifi switch off, then on.
> Bluetooth turns itself on again!
>
> Argghhh...

I can reply this too in Fedora 22 (Cinnamon)

Revision history for this message
In , jpazdziora (jpazdziora-redhat-bugs) wrote :

Updating version based on comment 38.

Revision history for this message
In , leigh123linux (leigh123linux-redhat-bugs) wrote :

*** Bug 1240476 has been marked as a duplicate of this bug. ***

Revision history for this message
In , jsynacek (jsynacek-redhat-bugs) wrote :

*** Bug 1231423 has been marked as a duplicate of this bug. ***

Revision history for this message
In , josephpfidler (josephpfidler-redhat-bugs) wrote :

Just noticed this bug with Fedora 23 - Gnome 3.18.2.

Set Bluetooth to off in the Gnome Settings Bluetooth dialogue - reboot and that setting is forgotten and Bluetooth is turned on again. Same is true for the Bluetooth setting in the power settings dialog.

For me this creates an necessary power drain by having Bluetooth enabled when its not needed, and more importantly a potential security problem. Hardware is an Asus UX305LA laptop.

Cheers, Joe.

Revision history for this message
In , mbrancaleoni (mbrancaleoni-redhat-bugs) wrote :

same on fedora 24, branched release (updated as now).

calling it an Enhancement is a bit.... meh, but well.

Revision history for this message
In , josephpfidler (josephpfidler-redhat-bugs) wrote :

Yep - Not honoring a very noticeable user setting seems like a straight forward bug to me. And its now six year old.

I am happy to test fixes for this if it helps...

Revision history for this message
In , mbrancaleoni (mbrancaleoni-redhat-bugs) wrote :

right now issue bypassed with tlp and by setting

DEVICES_TO_DISABLE_ON_STARTUP="bluetooth"

in /etc/default/tlp

not elegant, but 99.999% of time bluetooth is not really needed here.

Revision history for this message
In , josephpfidler (josephpfidler-redhat-bugs) wrote :

Its more elegant the the "rfkill block bluetooth" command I currently have in a startup script.
Thanks Matteo for your help.

Revision history for this message
In , jsynacek (jsynacek-redhat-bugs) wrote :

On Fedora 24, I can't reproduce this anymore.

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: no
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
3: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no

After turning off bluetooth from the gnome menu:

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no

After rebooting the machine, bluetooth is still soft blocked and appears as Off in the menu and bluetooth settings.

$ rpm -q gnome-shell bluez kernel
gnome-shell-3.20.0-1.fc24.x86_64
bluez-5.37-3.fc24.x86_64
kernel-4.5.0-301.fc24.x86_64

Revision history for this message
In , josephpfidler (josephpfidler-redhat-bugs) wrote :

Just re-tested this bug against my current setup - Fedora 23 with current updates. I do not see the issue as originally described - my Blutooth is staying off after a power-off. I am still working to see if I applied any of the work arounds, so that I can confirm if this is a valid result. I do see the issue after a suspend-resume event, but do know if that is relevant to this bug.

To re-create using suspend-resume I ...

1] Turn-off Blu-tooth using the Gnome menu (if its not already off). rfkill list shows:

1: asus-wlan: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: asus-bluetooth: Bluetooth
 Soft blocked: yes
 Hard blocked: no
3: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no

2] suspend the machine - sudo systemctl suspend

3] Resume. Gnome indicator shows Blutooth enabled and I can see the laptop's blutooth from other devices. Rfkill list still shows:

1: asus-wlan: Wireless LAN
 Soft blocked: no
 Hard blocked: no
2: asus-bluetooth: Bluetooth
 Soft blocked: yes
 Hard blocked: no
3: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no
4: hci0: Bluetooth
 Soft blocked: no
 Hard blocked: no

rpm -q gnome-shell bluez kernel
gnome-shell-3.18.4-1.fc23.x86_64
bluez-5.36-1.fc23.x86_64
kernel-4.4.4-301.fc23.x86_64
kernel-4.4.5-300.fc23.x86_64
kernel-4.4.6-300.fc23.x86_64

So after the resume Blutooth has activated itself despite being configured not too. I noticed the second Blutooth device (hci0) that has appeared in the list and wonder if this is part the cause of the problem. I am out of the office next week - will try to load the F24 Alpha then and re-test against that.

Changed in bluez (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Revision history for this message
In , bugzilla (bugzilla-redhat-bugs) wrote :

Same for F23

tags: added: iso-testing
Revision history for this message
In , bcotton (bcotton-redhat-bugs) wrote :

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
In , hub+rhbz (hub+rhbz-redhat-bugs) wrote :

Good news.
I haven't seen the problem is F24 and F25. Possibly fixed upstream.

Revision history for this message
In , woiling (woiling-redhat-bugs) wrote :

I still experience this behaviour on Fedora 24.

Revision history for this message
In , htl10 (htl10-redhat-bugs) wrote :

Argh, in my rc.local, I had it blocked by default:

/etc/rc.d/rc.local

rfkill block bluetooth

Revision history for this message
In , woiling (woiling-redhat-bugs) wrote :

It also still happens on Fedora 25 for me.

Revision history for this message
In , josephpfidler (josephpfidler-redhat-bugs) wrote :

Yep its still there. Just retested under F25 with current updates.

Turn off Bluetooth in the Gnome settings panel. Either a suspend-resume or power-off power-on will result in Bluetooth active.

I did see an error related to communication with my Bluetooth device (hci0) but have no idea if this is related to this error:

sudo dmesg | grep hci0
[ 3.692511] Bluetooth: hci0: read Intel version: 370810011003110e00
[ 3.694466] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[ 3.830043] Bluetooth: hci0 sending frame failed (-19)
[ 5.865638] Bluetooth: hci0 command 0xfc8e tx timeout
[ 14.313764] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 14.313889] Bluetooth: hci0 sending frame failed (-19)
[ 16.361767] Bluetooth: hci0 command 0xfc11 tx timeout
[ 16.361772] Bluetooth: hci0: Exiting manufacturer mode failed (-110)
[ 23.495554] Bluetooth: hci0: read Intel version: 370810011003110e00
[ 23.495766] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[ 23.804611] Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated

Changed in bluez (Fedora):
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , devidd05 (devidd05-redhat-bugs) wrote :

I am experiencing the same thing again in Fedora 31 in Dell XPS 13 9350.

Revision history for this message
In , updates (updates-redhat-bugs) wrote :

FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

Changed in bluez (Fedora):
status: Confirmed → Won't Fix
Displaying first 40 and last 40 comments. View all 139 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.