JohnHRucker
Posts: 7
Joined: Wed Aug 29, 2018 9:00 pm
Location: USA, Illinois

Bluetooth LE peripheral can not resolve a bound device's random address after reboot

Wed Dec 19, 2018 4:32 pm

I have a Raspberry Pi Zero W setup as a Bluetooth LE peripheral based on BlueZ 5.50 and Node.JS. I'm running this on Raspbian Stretch Lite with a build date of November 13, 2018. I upgraded BlueZ from 5.43 to 5.50 following these steps. My blePeripheral class works well for me, I'm able to securely bind to my iPhone and exchange encrypted data with the Raspberry Pi Zero W. as expected.

However, If I reboot the Raspberry Pi, and the random address of the bound device (iPad in this example) changes, that device can no longer read or write a secure characteristic. This seems to randomly happen, sometimes I can reboot the Pi and everything is fine. Here are my symptoms:

Symptom 1) The buetoothd daemon has an error during boot, the easiest way to see it is to issue a sudo systemctl status bluetooth just after reboot. There will be three errors just after the initialized line:
Failed to set mode: Rejected (0x0b)
Failed to set mode: Rejected (0x0b)
Failed to set privacy: Rejected (0x0b)

Symptom 2) When my iPad connects, the sudo btmon log doesn't show any errors. It just doesn't resolve the iPad's random address back to its public address as it did before the reboot. Here is a screen shot of what that looks like:
Image

Symptom 3) When my iPad tries to access a secure characteristic it gets an Insufficient Encryption error and then makes a LE Long Term Key Request. BlueZ responds with LE Long Term Key Request Neg Reply as shown below:
Image


my Workaround
If I restart bluetootd after a reboot with the sudo systemctl restart bluetooth command, this all goes away. The address will be resolved correctly next time my iPad connects. In the following screenshot of the log from sudo btmon you can see my iPad's random address 4B:0E:5C:79:3A:BE gets correctly resolved to its public address of B4:F6:1C:53:EF:B3 in the "MGMT Event: Device Connected" event. Not sure why there are always two exact MGMT Event: Device Connected log entires??
Image

I don't think this problem has anything to do with my node app. I'm thinking it has something to do with BlueZ and the Raspberry Pi. Looking for pointers on where to focus my troubleshooting efforts! Actually all input is welcome take a look at my BlueZ upgrade process maybe I missed something there. Why do I see two exact MGMT Events is this normal? This one has me stuck!!

Thanks in advance for your time!!

JR

epoch1970
Posts: 2230
Joined: Thu May 05, 2016 9:33 am
Location: Paris, France

Re: Bluetooth LE peripheral can not resolve a bound device's random address after reboot

Thu Dec 20, 2018 6:19 pm

Nice work. I know zilch about BT and especially BT LE, but this makes me think of systemd.
I would look at the various units and see if there is a possibility they start in the wrong order (or without configuration).
With systemd repeatability is not a given...
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

JohnHRucker
Posts: 7
Joined: Wed Aug 29, 2018 9:00 pm
Location: USA, Illinois

Re: Bluetooth LE peripheral can not resolve a bound device's random address after reboot

Fri Dec 28, 2018 12:07 pm

epoch1970 wrote:
Thu Dec 20, 2018 6:19 pm
Nice work. I know zilch about BT and especially BT LE, but this makes me think of systemd.
I would look at the various units and see if there is a possibility they start in the wrong order (or without configuration).
With systemd repeatability is not a given...

I haven't changed the order of the boot process that I know of. If there is something I can check you have in mind let me know. I have tried several settings in /etc/bluetooth/main.conf (BlueZ config file) and I'm pretty sure it is being read and the settings are okay.

As for the auto startup process here is my /lib/systemd/system/bluetooth.service file. Note: I have made changes to the ExecStart line by adding the --noplugin option. Just as an FYI this issue still takes place if I remove my changes.

Code: Select all

[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)
ConditionPathIsDirectory=/sys/class/bluetooth

[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=wiimote,battery,deviceinfo,hostname,scanparam,autopair
NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1
ProtectHome=true
ProtectSystem=full

[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
Thanks for the input!!

JohnHRucker
Posts: 7
Joined: Wed Aug 29, 2018 9:00 pm
Location: USA, Illinois

Re: Bluetooth LE peripheral can not resolve a bound device's random address after reboot

Mon Jan 14, 2019 4:21 pm

I have had a little more time to work on this. I think the boot order of the Bluetooth.service does have something to do with the problem. I set my node apps .service [unit] to want and be after the bluetooth.service. This didn’t make a difference in the load order of the boot process. I don’t know why?? But when I set my .service file to want and be after network.target a lot of things seemed to change in regards to the boot order. My apps now wait for bluetooth to load. But I have seen this error when I didn’t have any of my node.js apps set to auto start on reboot.
Here is the top of my rgMan.service file:

Code: Select all

[Unit]
Description=rgMan
Wants=network.target
After=network.target
Below is a screen shot of the bluetooth.service loading according to the systemd-analyze plot command. What is frustrating is the boot order of the services change even If I don’t make a single change to the system. I just feel like there is a dependency that the bluetooth.service needs and is not waiting for it. But I can’t find it??
goodBootOrder.JPG
goodBootOrder.JPG (119.65 KiB) Viewed 390 times

JohnHRucker
Posts: 7
Joined: Wed Aug 29, 2018 9:00 pm
Location: USA, Illinois

Re: Bluetooth LE peripheral can not resolve a bound device's random address after reboot

Thu Jan 17, 2019 2:29 pm

Just came across this issue on the github site for the RPI-Distro. It sounds very similar to my problem.
https://github.com/RPi-Distro/pi-bluetooth/issues/8

Return to “Raspbian”