Closed mibofra closed 4 years ago
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 - thegrep
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!
Sorry but, another bug for you :D
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