RPi-Distro / pi-bluetooth

Loads BCM43430A1 firmware on boot

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Where is bdaddr?

mibofra opened this issue · comments

Sorry but, another bug for you :D

/usr/bin/bthelper: 19: /usr/bin/bdaddr: not found

There isn't any bdaddr :D
Should it be provided by the package, or use another tool?

https://packages.debian.org/search?searchon=contents&keywords=bdaddr&mode=path&suite=stable&arch=any it's empty :D

It comes with bluez, but isn't included by default in Debian's version.

spf@spf-msi-WS65:~$ ls /media/spf/rootfs/usr/bin/bdaddr
ls: impossibile accedere a '/media/spf/rootfs/usr/bin/bdaddr': File o directory non esistente

No such file or directory, the image is 2020-05-27-raspios-buster-arm64.img

It was added recently. After that image was released.

$ dpkg -L bluez | grep bdaddr
/usr/bin/bdaddr

Shouldn't be more standard using hcitool, that it's already in the repo?

I'm not sure, but maybe @pelwell will have the answer.

Example: hcitool cmd 0x3f 0x001 ADDR in hex, reversed, hciconfig hci0 reset do the work
With a random 58:ca:6c:53:83:b9 addr:

hcitool -i hci0 cmd 0x3f 0x001 0xb9 0x83 0x53 0x6c 0xca 0x58

Saying you can do it with hcitool is like saying you can build a computer out of NOR gates, but if using hcitool is genuinely preferable to a tool designed for the job then I have no problem with using it. I've got an outstanding patch to bthelper. so I'll add this to the list (assuming it works).

Saying you can do it with hcitool is like saying you can build a computer out of NOR gates, but if using hcitool is genuinely preferable to a tool designed for the job then I have no problem with using it. I've got an outstanding patch to bthelper. so I'll add this to the list (assuming it works).

I'm working on it, just changing the order of colums. @pelwell I understand what you mean, but the spirit is to try to do everything without adding dependecies (as I'm reversing order without awk to don't add it as dep).

Or (another solution) can be to add bdaddr to this package instead of modding the standard bluez one.

The hcitool solution works, I've tested it already (you can do it too). I'm just working to rearrange of the columns so hcitool set the right bdaddr and not a reversed one.

P.S. It could be said also the opposite anyway, why just don't add all to btaddr instead of using a script calling hcitool, hciconfig, bluetoothctl and so on...
P.S.S. It isn't to be annoying, it is just that if you want to use the rpi hw pack on another system is not rpios, this make the package not portable. raspberrypi-sys-mods works without issues in all debian based systemd distros, and the rest of the hw doesn't mind neither the init system.

I didn't take your suggestion as annoying, I just find it strange that BlueZ would go to the trouble of adding an optional command dedicated to one purpose rather than adding a user-friendly option to hcitool to do the same thing, resulting in the situation that a byte sequence including a reversed BDADDR is the preferred method.

Here's the new version of bthelper, in case you are able to test it before I push to the repo:

#!/bin/sh
# For on-board BT, configure the BDADDR if necessary and route SCO packets
# to the HCI interface (enables HFP/HSP)

set -e

if [ "$#" -ne 1 ]; then
    echo "Usage: $0 <bluetooth hci device>"
    exit 0
fi

dev=$1

# Need to bring hci up before looking at MAC as it can be all zeros during init
/bin/hciconfig $dev up
if ! /bin/hciconfig $dev | grep -q "Bus: UART"; then
    echo Not a UART-attached BT Modem
    exit 0
fi

if ( /usr/bin/hciconfig $dev | grep -q -E '\s(B8:27:EB:|DC:A6:32:)' ); then
    echo Raspberry Pi BDADDR already set
else
    SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
    B1=`echo $SERIAL | cut -c3-4`
    B2=`echo $SERIAL | cut -c5-6`
    B3=`echo $SERIAL | cut -c7-8`
    BDADDR=`printf '0x%02x 0x%02x 0x%02x 0xeb 0x27 0xb8' $((0x$B3 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B1 ^ 0xaa))`

    /usr/bin/hcitool -i $dev cmd 0x3f 0x001 $BDADDR
    /bin/hciconfig $dev reset
fi

# Force reinitialisation to allow extra features such as Secure Simple Pairing
# to be enabled
/usr/bin/bluetoothctl power off
/usr/bin/bluetoothctl power on

# Route SCO packets to the HCI interface (enables HFP/HSP)
/usr/bin/hcitool -i $dev cmd 0x3f 0x1c 0x01 0x02 0x00 0x01 0x01 > /dev/null

Thanks @pelwell, I was focused in parsing the output of the printf instead of changing it (well, it is the simplest solution...)
Just, /usr/bin/hciconfig is under /bin (as before and after in the script). So, I've made this changes:

#!/bin/sh
# For on-board BT, configure the BDADDR if necessary and route SCO packets
# to the HCI interface (enables HFP/HSP)

set -e

if [ "$#" -ne 1 ]; then
    echo "Usage: $0 <bluetooth hci device>"
    exit 0
fi

dev=$1

# Need to bring hci up before looking at MAC as it can be all zeros during init
/bin/hciconfig $dev up
if ! /bin/hciconfig $dev | grep -q "Bus: UART"; then
    echo Not a UART-attached BT Modem
    exit 0
fi

if ( /usr/bin/hcitool -i $dev dev | cut -sf3 | grep -q -E '\s(B8:27:EB:|DC:A6:32:)' ); then
    echo Raspberry Pi BDADDR already set
else
    SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
    B1=`echo $SERIAL | cut -c3-4`
    B2=`echo $SERIAL | cut -c5-6`
    B3=`echo $SERIAL | cut -c7-8`
    BDADDR=`printf '0x%02x 0x%02x 0x%02x 0xeb 0x27 0xb8' $((0x$B3 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B1 ^ 0xaa))`

    /usr/bin/hcitool -i $dev cmd 0x3f 0x001 $BDADDR
    /bin/hciconfig $dev reset
fi

# Force reinitialisation to allow extra features such as Secure Simple Pairing
# to be enabled
/usr/bin/bluetoothctl power off
/usr/bin/bluetoothctl power on

# Route SCO packets to the HCI interface (enables HFP/HSP)
/usr/bin/hcitool -i $dev cmd 0x3f 0x1c 0x01 0x02 0x00 0x01 0x01 > /dev/null

/usr/bin/hcitool -i $dev dev | cut -sf3 gives the current BDADDR in uppercase.
My bluetooth addr is set correctly!

root@myrpi:~# bthelper hci0
< HCI Command: ogf 0x3f, ocf 0x0001, plen 6
  19 9A 4B EB 27 B8 
> HCI Event: 0x0e plen 4
  01 01 FC 00 
Changing power off succeeded
[CHG] Controller AA:AA:AA:AA:AA:AA Powered: no
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: no
Changing power on succeeded
[CHG] Controller AA:AA:AA:AA:AA:AA Powered: yes

Obviously my controller has not addr AA:AA:AA:AA:AA:AA anymore.

The extra cut doesn't do anything useful here - the grep is sufficient - but I'll take the hcitool dev change.

The extra cut doesn't do anything useful here - the grep is sufficient - but I'll take the hcitool dev change.

You are right, but it was just to be sure. Please test it again anyway, just to be sure! I'm testing it on my rpi4, it SHOULD work also on the rpi3.

It's working on an old 3B with an unprogrammed BDADDR. @XECDesign it's good to go.

Sorry I closed the issue as accident, nice that's working on rpi3 too! @pelwell

Closing, as it seems to be in master now. Reopen it if you need. Thanks!