RuckerGauge/blePeripheral

Problem resolving a previously bound device's random address to its public address after a reboot.

JohnRucker opened this issue · 3 comments

JohnRucker commented

If you reboot the Raspberry Pi, and the random address of a bound device (iPad in this example) changes, that device can no longer read or write a secure characteristic.
Symptom 1) The buetoothd daemon has an error during boot, the easiest way to see it is to issue a sudo systemctl status bluetooth. 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 your iPhone connects the sudo btmon log doesn't show any errors. It just doesn't resolve the iPhone's random address back to public as it did before the reboot. Here is a screen shot of what that looks like:
image

Symptom 3) When you iPhone 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

Workaround

If you restart bluetootd after a reboot sudo systemctl restart bluetooth this all goes away. The address will be resolved correctly. In the following screen shot of the log from sudo btmon you can see my iPad's random address B4:F6:1C:53:EF:B3 gets correctly resolved to its public address of B4:F6:1C:53:EF:B3.
image

I don't think this problem has anything to do with my node app. It has something to do with BlueZ and the Raspberry Pi. Looking for pointer on where to focus my troubleshooting efforts!

siditm commented

I don't own an iOS device so can't test this, but you might look into:

sudo gatttool -t random -b 00:11:22:33:44:55 -I

E.g. https://stackoverflow.com/a/22313844

or for the lecc options https://devzone.nordicsemi.com/f/...

JohnRucker commented

This continues to be an issue in version 2 of blePeripheral as I think it is an unresolved issue with the Raspberry Pi firmware. The workaround continues to be to restart bluetooth on the Pi after a reboot.

sharmilhassan commented

I am also getting the "Failed to set mode" errors. I have tried restarting bluetooth on the Pi after a reboot but the errors still persist.

sudo systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-06-24 20:47:58 PDT; 9s ago
Docs: man:bluetoothd(8)
Main PID: 483 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 877)
CGroup: /system.slice/bluetooth.service
└─483 /usr/libexec/bluetooth/bluetoothd --noplugin=wiimote,battery,deviceinfo,hostname,scanparam,autopair

Jun 24 20:47:58 securetrans bluetoothd[483]: Excluding (cli) hostname
Jun 24 20:47:58 securetrans bluetoothd[483]: Excluding (cli) wiimote
Jun 24 20:47:58 securetrans bluetoothd[483]: Excluding (cli) autopair
Jun 24 20:47:58 securetrans bluetoothd[483]: Excluding (cli) scanparam
Jun 24 20:47:58 securetrans bluetoothd[483]: Excluding (cli) deviceinfo
Jun 24 20:47:58 securetrans bluetoothd[483]: Excluding (cli) battery
Jun 24 20:47:58 securetrans bluetoothd[483]: Bluetooth management interface 1.18 initialized
Jun 24 20:47:58 securetrans bluetoothd[483]: Failed to set mode: Rejected (0x0b)
Jun 24 20:47:58 securetrans bluetoothd[483]: Failed to set mode: Rejected (0x0b)
Jun 24 20:47:58 securetrans bluetoothd[483]: Failed to set privacy: Rejected (0x0b)

  • 👍2