2

Try this experiment with a cheap Bluetooth speaker with no user interface:

  • pair your tablet with the Bluetooth speaker
  • turn the speaker off
  • unpair the tablet from the speaker
  • turn the speaker on
  • pair the tablet successfully with the speaker

Now try the same experiment with a headless controller running Bluez. If inside the controller (such as a Raspberry Pi) you use hciconfig hci0 sspmode 1 then the controller will automatically pair with the tablet's Bluetooth.

But if you then turn off the controller, un-pair the tablet, and turn the controller back on, it will now refuse to pair. The tablet shows the controller in its 'advertising' list, eligible for pairing. But inside the controller, the tablet appears in its 'paired' list. The working theory is the controller thinks the tablet is paired and hence refuses to pair again.

How do cheap headless Bluetooth speakers get around this problem? Opening up the controller with SSH or a keyboard are not optional.

2 Answers 2

0

Cheap headsets bypass that problem with a 3-10 second hard reset button/option which is why when they have pairing issues they can basically reset the paired/pairable devices usually by holding the power button down so unless it would wipe out the entire controller(raspberry pi, ect.) that would be the best option...

1
  • I have reported a bug in BlueZ's Simple Secure Pairing. We are looking at adding a button to our (pristine) robot to work-around the bug. And nanobots like Bluetooth earbuds don't seem to have a power button...
    – Phlip
    Dec 19, 2022 at 16:32
0

The answer is to level up to BlueZ >=5.54 and put JustWorksRepairing = always; in main.conf. Without destabilizing all your other coefficients.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .