hcitool/hciconfig are now deprecated in upstream bluez

[parkerlreed]

[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.

[Ape]

What replaced hciconfig hciXXX up?

[parkerlreed]

I'm actually trying to figure that out now :/

[parkerlreed]

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

[parkerlreed]

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.

[Ape]

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.

[parkerlreed]

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)

[parkerlreed]

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.

[PoLoMoTo]

Is there any workaround for this yet?

[parkerlreed]

@PoLoMoTo Connect in Bluez (share + PS), and use the --hidraw option of ds4drv.

Alternatively bluez-utils can be compiled with the deprecated binaries included.

[gdudek]

Very basic illustration of easily bluetoothctl can be scripted: (echo scan on;sleep 60;echo scan off; echo quit)|bluetoothctl

[0x664b44c3]

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.

[gdudek]

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.

[Hi-Angel]

Given it's a first result in google, I think it's worth putting a link to clarification on deprecation, here it is.

[parkerlreed]

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 :/ )

[blacklight]

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.

[bojanpotocnik]

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.

[mprt]

FWIW: you can try to build bluez yourself with "--enable-deprecated"

[bojanpotocnik]

Note that btmgmt is also not installed anymore since commit https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=56178b62564b26d3ff033fe7f5cae600e8826144

https://www.spinics.net/lists/linux-bluetooth/msg65031.html