Re: [gentoo-user] Bluetooth and hciconfig

2017-03-30 Thread Mick
On Wednesday 29 Mar 2017 14:10:36 Foster McLane wrote:
> On Tue, Mar 28, 2017 at 04:53:44PM +0100, Mick wrote:
> > # AutoEnable defines option to enable all controllers when they are found.
> > # This includes adapters present on start as well as adapters that are
> > plugged # in later on. Defaults to 'false'.
> > AutoEnable = true
> > ===
> 
> Can you remove the spaces around the '=' and try again?
> 
> Foster

Thanks Foster, I have tried with and without spaces, with and without single 
quotation marks.  It still errors out.  I'll wait until the next version 
stabilises, check if hciconfig has disappeared from my system (I'll try to 
remember to keep a backup of the binary) and and see what the logs show after 
that.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Bluetooth and hciconfig

2017-03-29 Thread Foster McLane
On Tue, Mar 28, 2017 at 04:53:44PM +0100, Mick wrote:
> # AutoEnable defines option to enable all controllers when they are found.
> # This includes adapters present on start as well as adapters that are plugged
> # in later on. Defaults to 'false'.
> AutoEnable = true
> ===

Can you remove the spaces around the '=' and try again?

Foster



Re: [gentoo-user] Bluetooth and hciconfig

2017-03-28 Thread Mick
On Tuesday 28 Mar 2017 11:19:33 Foster McLane wrote:
> On Tue, Mar 28, 2017 at 07:59:02AM -0700, Mick wrote:
> > Mar 28 15:50:20 dell_xps bluetoothd[10619]: Unknown key AutoEnable in
> > main.conf
> 
> Did you use the 'AutoEnable' option in the '[Policy]' section of
> main.conf?

Yes.  :-(

===
#[Policy]
#
# The ReconnectUUIDs defines the set of remote services that should try
# to be reconnected to in case of a link loss (link supervision
# timeout). The policy plugin should contain a sane set of values by
# default, but this list can be overridden here. By setting the list to
# empty the reconnection feature gets disabled.
#ReconnectUUIDs=1112--1000-8000-00805f9b34fb,111f--1000-8000-00805f9b34fb,110a--1000-8000-00805f9b34fb

# ReconnectAttempts define the number of attempts to reconnect after a link
# lost. Setting the value to 0 disables reconnecting feature.
#ReconnectAttempts=7

# ReconnectIntervals define the set of intervals in seconds to use in between
# attempts.
# If the number of attempts defined in ReconnectAttempts is bigger than the
# set of intervals the last interval is repeated until the last attempt.
#ReconnectIntervals=1,2,4,8,16,32,64

# AutoEnable defines option to enable all controllers when they are found.
# This includes adapters present on start as well as adapters that are plugged
# in later on. Defaults to 'false'.
AutoEnable = true
===

> > So, what's the solution if hciconfig et al are not installed with future
> > versions of bluez and the AutoEnable option does not seem to take?
> 
> I'm pretty sure the future solution is to use bluetoothctl as a console
> user interface or find a more scriptable alternative (I don't know of
> any) that also use the DBus interface.
> 
> I just hit this problem with the upgrade as I was using scripts to manage
> turning bluetooth on and off and I was able to get by with just the
> AutoEnable option. I did not find much else in my cursory research as to
> a replacement for hciconfig. The following is from the release notes for
> 
> BlueZ 5.35:
> > A noteworthy new feature is the ability to configure bluetoothd to
> > automatically enable (power on) all new adapters. One use of this is to
> > replace unreliable "hciconfig hci0 up" commands that some distributions
> > use in their init/udev scripts. The feature can be enabled by having
> > AutoEnable=true under the [Policy] section of /etc/bluetooth/main.conf.
> 
> Foster

Yes, but the same AutoEnable option is present in main.conf of 5.43-r1 which I 
am running at present.  Perhaps it only becomes effective in a later version, 
but then why would it be added as an option in the current stable version?

Meanwhile, I did some additional experimentation.  If I run bluetoothctl after 
'/etc/init.d/bluetooth start' and then set:

power on
agent on
scan on, and
quit

the adapter is now up and I can connect with bluetooth as if I had run 
hciconfig up.  If I run neither bluetoothctl, nor hciconfig the adapter stays 
disabled.  Of course, hciconfig is just an one liner (run as root) so it is 
more convenient than running bluetooth control each time.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Bluetooth and hciconfig

2017-03-28 Thread Foster McLane
On Tue, Mar 28, 2017 at 07:59:02AM -0700, Mick wrote:
> Mar 28 15:50:20 dell_xps bluetoothd[10619]: Unknown key AutoEnable in
> main.conf

Did you use the 'AutoEnable' option in the '[Policy]' section of
main.conf?

> So, what's the solution if hciconfig et al are not installed with future
> versions of bluez and the AutoEnable option does not seem to take?

I'm pretty sure the future solution is to use bluetoothctl as a console
user interface or find a more scriptable alternative (I don't know of
any) that also use the DBus interface.

I just hit this problem with the upgrade as I was using scripts to manage
turning bluetooth on and off and I was able to get by with just the
AutoEnable option. I did not find much else in my cursory research as to
a replacement for hciconfig. The following is from the release notes for
BlueZ 5.35:

> A noteworthy new feature is the ability to configure bluetoothd to
> automatically enable (power on) all new adapters. One use of this is to
> replace unreliable "hciconfig hci0 up" commands that some distributions
> use in their init/udev scripts. The feature can be enabled by having
> AutoEnable=true under the [Policy] section of /etc/bluetooth/main.conf.

Foster



[gentoo-user] Bluetooth and hciconfig

2017-03-28 Thread Mick
A recent post had me investigating this.  I'm on net-wireless/bluez-5.43-r1 
which thankfully provides the hciconfig utility.  I have used hciconfig for 
years now to enable the bluetooth adapter on my laptop.

Starting /etc/init.d/bluetooth does not enable the adapter itself.  Setting

AutoEnable = true

causes an error in the logs:

in Mar 28 15:50:20 dell_xps bluetoothd[10619]: Bluetooth daemon 5.43
Mar 28 15:50:20 dell_xps bluetoothd[10619]: Unknown key AutoEnable in 
main.conf
Mar 28 15:50:20 dell_xps bluetoothd[10619]: Starting SDP server
Mar 28 15:50:20 dell_xps bluetoothd[10619]: Bluetooth management interface 
1.14 initialized
Mar 28 15:50:20 dell_xps bluetoothd[10619]: Failed to obtain handles for 
"Service Changed" characteristic
Mar 28 15:50:20 dell_xps bluetoothd[10619]: Endpoint registered: sender=:1.34 
path=/MediaEndpoint/A2DPSource
Mar 28 15:50:20 dell_xps bluetoothd[10619]: Endpoint registered: sender=:1.34 
path=/MediaEndpoint/A2DPSink


The adapter remains disabled:

# hciconfig 
hci0:   Type: Primary  Bus: USB
BD Address: 90:4C:E5:FA:F2:A8  ACL MTU: 1021:8  SCO MTU: 64:8
DOWN 
RX bytes:1058 acl:0 sco:0 events:52 errors:0
TX bytes:951 acl:0 sco:0 commands:52 errors:0


Enabling it manually with hciconfig works as always had:

# hciconfig hci0 up piscan
# hciconfig 
hci0:   Type: Primary  Bus: USB
BD Address: 90:4C:E5:FA:F2:A8  ACL MTU: 1021:8  SCO MTU: 64:8
UP RUNNING PSCAN ISCAN 
RX bytes:1599 acl:0 sco:0 events:80 errors:0
TX bytes:1559 acl:0 sco:0 commands:80 errors:0

So, what's the solution if hciconfig et al are not installed with future 
versions of bluez and the AutoEnable option does not seem to take?
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.