Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1348346 - No control over device state with blueman-2.0.4-2.fc23
Summary: No control over device state with blueman-2.0.4-2.fc23
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: 23
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Don Zickus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1348669 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-20 22:40 UTC by Mike Simms
Modified: 2016-10-27 22:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-27 22:16:32 UTC
Type: Bug


Attachments (Terms of Use)
terminal output for version 2.0.4-2.fc23 (7.25 KB, text/plain)
2016-06-20 22:40 UTC, Mike Simms
no flags Details
terminal output for build 2.1-0.3.git7a2e20e.fc23 (23.50 KB, text/plain)
2016-06-20 22:42 UTC, Mike Simms
no flags Details
lsusb -v output for the adaptor (8.80 KB, text/plain)
2016-06-20 22:44 UTC, Mike Simms
no flags Details

Description Mike Simms 2016-06-20 22:40:04 UTC
Created attachment 1170011 [details]
terminal output for version 2.0.4-2.fc23

Description of problem: The bluetooth disabled icon appears after startup even though the adaptor is enabled. No control of bluetooth adaptor from blueman-applet. 


Version-Release number of selected component (if applicable): blueman-2.0.4-2.fc23


How reproducible: Consistently


Steps to Reproduce:
1. Install blueman update
2. exit running version of blueman or restart PC (either work)
3. try changing the state of the bluetooth adaptor

Actual results: See attached output file, there is a problem with state changes.


Expected results: bluetooth adaptor should be enabled after logging into MATE and fully controllable from the applet.


Additional info: F23 MATE 1.14.1 GTK+2 with Compiz as Window Manager. It is a clean install today which enabled me to pinpoint where this issue actually came from. It affects the notebook with F24 as well. The issue is fixed by downgrading to blueman build 2.1-0.3.git7a2e20e.fc23.

Comment 1 Mike Simms 2016-06-20 22:42:19 UTC
Created attachment 1170012 [details]
terminal output for build 2.1-0.3.git7a2e20e.fc23

2.1-0.3.git7a2e20e.fc23

terminal output showing downgrade and subsequent output of working build for comparison with a power state change from the blueman-applet

Comment 2 Mike Simms 2016-06-20 22:44:42 UTC
Created attachment 1170013 [details]
lsusb -v output for the adaptor

It's an intel bluetooth device integrated internally into my notebook.

Comment 3 Mike Simms 2016-06-20 22:46:48 UTC
Missed a step to Reproduce:
1. Install blueman update
2. exit running version of blueman or restart PC (either work)
3. start blueman-applet
4. try changing the state of the bluetooth adaptor

Comment 4 Raphael Groner 2016-06-21 09:55:20 UTC
Known bug and it happens mostly after system resumes from suspend.
Try to fix with 'hciconfig hci0 up' in a root terminal and restart blueman.

Comment 5 Mike Simms 2016-06-21 10:46:52 UTC
Filed upstream https://github.com/blueman-project/blueman/issues/537

Comment 6 Mike Simms 2016-06-21 10:50:06 UTC
(In reply to Raphael Groner from comment #4)
> Known bug and it happens mostly after system resumes from suspend.
> Try to fix with 'hciconfig hci0 up' in a root terminal and restart blueman.

Thanks for the answer. I don't suspend my notebook, it happens from cold boot as well or just running the applet from terminal.

That command worked but do I have to enter that every time I turn the notebook on? If so, it still needs addressing properly as that is not an acceptable long term solution to be fair.

Comment 7 Mike Simms 2016-06-21 11:17:18 UTC
as suspected it's a session only fix. even then I'm reliant on this terminal command to turn the device on or off as needed.

sudo hciconfig hci0 up|down

Comment 8 Mike Simms 2016-06-21 11:20:20 UTC
the applet works properly with sudo rights when run from terminal:

sudo blueman-applet

Comment 9 Mike Simms 2016-06-21 12:02:44 UTC
(In reply to Mike Simms from comment #8)
> the applet works properly with sudo rights when run from terminal:
> 
> sudo blueman-applet

blueman has full control like this but you still need to issue the hciconfig hci0 up command beforehand.

Comment 10 Mike Simms 2016-06-21 15:16:37 UTC
@arehtykitna, this is intended behaviour. BlueZ does not power the adapter automatically any-more since version 5.0. There are two options, enable auto-power on in the PowerManager plugin or create a udev rule as described here. The former will power the adapter when you login and the latter will do it as soon as the adapter is detected.

from infirit - https://github.com/blueman-project/blueman/issues/537

solution:

Create a file in /etc/udev/rules.d/ (eg 50-bluetooth-hci-auto-poweron.rules) with the following content

ACTION=="add", SUBSYSTEM=="bluetooth", KERNEL=="hci[0-9]*", RUN+="/bin/hciconfig %k up"

________________________________________________________________________________
I was not aware of this policy change, sorry for any inconvenience caused.

Comment 11 Raphael Groner 2016-06-21 15:40:00 UTC
(In reply to Mike Simms from comment #10)
> @arehtykitna, this is intended behaviour. BlueZ does not power the adapter
> automatically any-more since version 5.0. There are two options, enable
> auto-power on in the PowerManager plugin

What do you mean with PowerManager plugin? How to do in Cinnamon (or other desktop environment)?

> or create a udev rule as described
> here. The former will power the adapter when you login and the latter will
> do it as soon as the adapter is detected.
> 
> from infirit - https://github.com/blueman-project/blueman/issues/537
> 
> solution:
> 
> Create a file in /etc/udev/rules.d/ (eg 50-bluetooth-hci-auto-poweron.rules)
> with the following content
> 
> ACTION=="add", SUBSYSTEM=="bluetooth", KERNEL=="hci[0-9]*",
> RUN+="/bin/hciconfig %k up"

Thanks for forwarding from upstream documentation.
https://github.com/blueman-project/blueman/wiki/Troubleshooting#turn-on-bluetooth-device-on-boot

This should get fixed in udev (or bluez) to provide it as a standard rule, independent from any used DE.

Comment 12 Mike Simms 2016-06-21 18:48:33 UTC
> This should get fixed in udev (or bluez) to provide it as a standard rule,
> independent from any used DE.

Indeed, the udev rule would be best if possible. That's why I chose it as the solution for my own purposes. Suppose I want to install and use a different DE, the same fix covers all of them.

Comment 13 Stuart D Gathman 2016-08-29 23:36:08 UTC
*** Bug 1348669 has been marked as a duplicate of this bug. ***

Comment 14 Don Zickus 2016-08-30 13:21:43 UTC
Hi,

I added to bluez a month or two ago a conf file from upstream, /etc/bluetooth/main.conf.  At the bottom of that file is a Policy action

AutoEnable=true

I set it to true for default installs currently.  This is supposed to solve the problem reported here.  Of course, for those worried about security/power, setting it to 'false' is easy to do.

Just note, there is no 'agent' running (though blueman provides one I believe), so be careful walking around with an active bluetooth radio enabled.  All this means is there is no 'agent' running to authenticate a transaction, so everything should get rejected when trying to connect, in theory..

Cheers,
Don

Comment 15 Raphael Groner 2016-08-30 16:28:07 UTC
(In reply to Don Zickus from comment #14)

What happens if there's no such entry for AutoEnable at all in the mentioned conf file? As it seems adding that entry (either with false or true as the value) allows the manual activation / deactivation of the device via the context menu entry what was the original issue as far as I understand: "fully controllable from the applet". I wonder if there's another default value than either true or false assumed if the AutoEnable entry is missed.

Comment 16 Don Zickus 2016-08-30 16:53:53 UTC
(In reply to Raphael Groner from comment #15)
> (In reply to Don Zickus from comment #14)
> 
> What happens if there's no such entry for AutoEnable at all in the mentioned
> conf file? As it seems adding that entry (either with false or true as the
> value) allows the manual activation / deactivation of the device via the
> context menu entry what was the original issue as far as I understand:
> "fully controllable from the applet". I wonder if there's another default
> value than either true or false assumed if the AutoEnable entry is missed.

Hi Raphael,

AutoEnable is only useful when set to true.  Otherwise it is assumed false and the device is not enabled (as is currently). :-)

So setting it to false or removing the file or entry is equivalent to the same thing.  Only forcing it to be true is key difference.

Cheers,
Don

Comment 17 Raphael Groner 2016-08-30 16:58:16 UTC
Don,

then I don't understand the duplication in bug #1348669 that talks about DBus.

Comment 18 Don Zickus 2016-08-30 18:01:26 UTC
Hi Raphael,

Hmm, I see your point.  Enabling bluetooth from a conf file or udev doesn't quite fix https://bugzilla.redhat.com/show_bug.cgi?id=1348669, so the duplicate doesn't make sense.

I believe that is what you are implying, no?

Cheers,
Don

Comment 19 Raphael Groner 2016-08-30 19:05:46 UTC
I agree with https://bugzilla.redhat.com/show_bug.cgi?id=1348669#c2 :
Bluetooth should be switched off by default and manually enabled if needed, is it possible to get it switched off automatically after some time like mobile devices can do? That's the best solution IMHO for both border cases, power saving and security issues.

Comment 20 Stuart D Gathman 2016-08-30 22:48:54 UTC
I submitted bz#1348669 originally, and closed it as a DUP because I read above that blueman did not allow enabling from blueman by design.  If I misread that, I can reopen my bug.  Since my bluetooth adapter is a USB dongle, I just pull it out to save power - so my problem is solved!  :-)  I agree it would be annoying to have to continue to use bluetoothctl to power an internal adapter on/off.

Comment 21 Raphael Groner 2016-08-30 23:48:27 UTC
(In reply to Stuart D Gathman from comment #20)
…
> Since my bluetooth adapter is a USB
> dongle, I just pull it out to save power - so my problem is solved!  :-)  I
> agree it would be annoying to have to continue to use bluetoothctl to power
> an internal adapter on/off.

But think about all the laptops or other mobile devices around in the world, I know of some models that do not have any hardware switch to disable bluetooth.

Comment 22 Raphael Groner 2016-09-10 14:46:08 UTC
(In reply to Don Zickus from comment #16)
… 
> AutoEnable is only useful when set to true.  Otherwise it is assumed false
> and the device is not enabled (as is currently). :-)
> 
> So setting it to false or removing the file or entry is equivalent to the
> same thing.  Only forcing it to be true is key difference.

Indeed. AutoEnable=false or commented breaks blueman-applet and it's not possible for the user to enable bluetooth with the context menu.

Comment 23 Mike Simms 2016-10-27 22:16:32 UTC
(In reply to Don Zickus from comment #14)
> Hi,
> 
> I added to bluez a month or two ago a conf file from upstream,
> /etc/bluetooth/main.conf.  At the bottom of that file is a Policy action
> 
> AutoEnable=true
> 
> I set it to true for default installs currently.  This is supposed to solve
> the problem reported here.  Of course, for those worried about
> security/power, setting it to 'false' is easy to do.
> 
> Just note, there is no 'agent' running (though blueman provides one I
> believe), so be careful walking around with an active bluetooth radio
> enabled.  All this means is there is no 'agent' running to authenticate a
> transaction, so everything should get rejected when trying to connect, in
> theory..
> 
> Cheers,
> Don

Hi Don, many thanks for this main.conf addition. It does indeed resolve the power toggling issue. Apologies for the late reply, it's the first time I've been able to sit in front of the machine and attempt a clean install to check it out properly again.


Note You need to log in before you can comment on or make changes to this bug.