Re: [gentoo-user] Bluetooth and hciconfig
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
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
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
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
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.