hcitool/hciconfig are now deprecated in upstream bluez
Opened this issue · 18 comments
[parker@satellite ~]$ sudo ds4drv
[error][daemon] 'hcitool' could not be found, make sure you have bluez-utils installed.
Under the first notes section https://wiki.archlinux.org/index.php/bluetooth#Installation
There is a compat package but it's only on the AUR so not everybody will have access to it.
What replaced hciconfig hciXXX up?
I'm actually trying to figure that out now :/
Digging through some man pages I came across btmgmt
btmgmt power on
btmgmt ver 5.44
Usage:
btmgmt [options] <command> [command parameters]
Options:
--index <id> Specify adapter index
--verbose Enable extra logging
--help Display help
Commands:
version Get the MGMT Version
commands List supported commands
config Show configuration info
info Show controller info
extinfo Show extended controller info
auto-power Power all available features
power Toggle powered state
discov Toggle discoverable state
connectable Toggle connectable state
fast-conn Toggle fast connectable state
bondable Toggle bondable state
pairable Toggle bondable state
linksec Toggle link level security
ssp Toggle SSP mode
sc Toogle SC support
hs Toggle HS support
le Toggle LE support
advertising Toggle LE advertising
bredr Toggle BR/EDR support
privacy Toggle privacy support
class Set device major/minor class
disconnect Disconnect device
con List connections
find Discover nearby devices
find-service Discover nearby service
stop-find Stop discovery
name Set local name
pair Pair with a remote device
cancelpair Cancel pairing
unpair Unpair device
keys Load Link Keys
ltks Load Long Term Keys
irks Load Identity Resolving Keys
block Block Device
unblock Unblock Device
add-uuid Add UUID
rm-uuid Remove UUID
clr-uuids Clear UUIDs
local-oob Local OOB data
remote-oob Remote OOB data
did Set Device ID
static-addr Set static address
public-addr Set public address
ext-config External configuration
debug-keys Toogle debug keys
conn-info Get connection information
io-cap Set IO Capability
scan-params Set Scan Parameters
get-clock Get Clock Information
add-device Add Device
del-device Remove Device
clr-devices Clear Devices
bredr-oob Local OOB data (BR/EDR)
le-oob Local OOB data (LE)
advinfo Show advertising features
advsize Show advertising size info
add-adv Add advertising instance
rm-adv Remove advertising instance
clr-adv Clear advertising instances
appearance Set appearance
For more information on the usage of each command use:
btmgmt <command> --help
I was told this on IRC...
then yes [btmgmt will work], but keep in mind that btmgmt is not official tool
So I'm really not sure at this point.
What about bluetoothctl which also has power on command? One option is to check whether bluetooth is enabled, and fail with a help message if it needs to be enabled.
Yeah bluetoothctl is the "official" way but as you stated you would have to have a message. There's no easy way to script bluetoothctl. Another possibility is making the dbus call directly (just as bluetoothctl does on the backend)
Just putting this here as reference for the dbus locations
$ qdbus --system org.bluez /org/bluez/hci0 org.bluez.Adapter1.Powered
true
That same value has read/write enabled on it.
Is there any workaround for this yet?
@PoLoMoTo Connect in Bluez (share + PS), and use the --hidraw option of ds4drv.
Alternatively bluez-utils can be compiled with the deprecated binaries included.
Very basic illustration of easily bluetoothctl can be scripted:
(echo scan on;sleep 60;echo scan off; echo quit)|bluetoothctl
I guess that's not what parkerlreed means when he talks about "scripting".
Classical scripting in a shellscript implies calling an executable one command at a time and getting a return code on whether that command was successful or not. Just piping commands through stdin gives you no direct way of error checking.
If it ain't compiled code then it's scripting. More to the point, you can use that kind of method (of which I just gave a basic illustration) to fully control bluetoothctl and also read back what it says. It's ugly, but it works.
For example, to see if the bluetooth device is powered on, you could use:
echo show | sudo bluetoothctl | awk '/Powered/{print $2;}'
Wrapping it in a python or perl script where you can use the subprocess library to really control the interaction would allow for cleaner control than using the shell.
Given it's a first result in google, I think it's worth putting a link to clarification on deprecation, here it is.
I guess the most practical solution would be to switch everything to
use bluetoothctl as much as possible
Except where you can't, like rfcomm bind (there's a dbus call but good luck with that), resetting controller state fully (power on/off sometimes isn't enough in bluetoothctl), etc. In my opinion it wouldn't be as bad if they offered up front replacements of the commands. Piping shit into a command feels like a VERY clunky workaround.
(I know this isn't particularly related to the issue at hand but I just needed to get that out there :/ )
Somebody decided to deprecate the executables that have been used for years by tons of devs and scripts to interact with the bluetooth stack without providing any viable alternative ("experiment with the dbus interaction to emulate what bluetoothctl does", "pipe a bunch of echos to bluetoothctl", "btmgmt is the new hciconfig - oh sorry, it's not going to be official yet").
That's probably one of the dumbest things a software developer can do. Would it have been that expensive to keep the old executables until a new, stable way to handle bluetooth scripting with the new ones was out? You CAN'T deprecate something unless the alternative allows you to do exactly the same things you were able to do with the previous implementation! And the documentation is totally absent too - lots of pages still reference the hci* tools, and some (like the Arch Linux wiki) are themselves confused on what's the right way to do things now. Most of all, users haven't yet received an answer to a simple question: why were they deprecated in the first place?
I hope the guys at Bluez will soon recover from their unjustified booze and provide us with new reliable ways to do what we used to do until a year ago.
Note that after few years, there is still no replacement for all functionalities.
One example is hcitool lescan --duplicates. bluetoothctl has duplicate-data on setting, which is just ignored - check Disable “Filter duplicates” setting for LE Set Scan Enable command.
On never systems more and more hci* tools are not working anymore (throwing Input/output error), which is getting really frustrating.
FWIW: you can try to build bluez yourself with "--enable-deprecated"
Note that btmgmt is also not installed anymore since commit https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=56178b62564b26d3ff033fe7f5cae600e8826144