btstack: a2dp connection fails with 0x66 since 1.5.1

[baltitenger]

Trying to run a2dp_source_demo from pico-examples, I get this:

BTstack up and running on 28:CD:C1:0C:11:91.
Start scanning...
Device found: 30:53:C1:4E:A2:2C with COD: 240404, rssi -72 dBm, name 'WI-XB400'
Bluetooth speaker detected, trying to connect to 30:53:C1:4E:A2:2C...
A2DP Source: Connection failed, status 0x66, cid 0x01, a2dp_cid 0x01 
A2DP Source: Stream failed, status 0x66.

The example used to work on 1.5.0, reverting d9c88c6 seems to fix it.

[mringwal]

The error is
#define L2CAP_CONNECTION_RESPONSE_RESULT_REFUSED_SECURITY 0x66
from btstack/src/bluetooth.h

I'm not aware of any changes that would be relevant for this demo in BTstack since the initial release.

Could you try to put your speaker into 'pairing' mode before starting the a2dp_source_demo?

[baltitenger]

I have tried it in pairing mode as well but it gives the same result, though I only tried with the same speaker.

Commenting out this line is enough to fix it. I'm not sure why changing the address could matter for the speaker.

[mringwal]

Interesting find. What addr is used with that line, what is used without? Can you try to set a different random addresses?  The only incorrect bd addr per se would be all zeroes.

[baltitenger]

The address before the change is 43:43:A2:12:1F:AC, after is 28:CD:C1:0C:11:91.
I tried connecting to a different speaker with the new address and it worked. However, if I try reverting the change now then connecting to the new speaker fails with the same error (while the old speaker works).

I'm assuming there's something besides the address by which the speaker can identify the device, and now since the address changed but the other kind of ID did not, the speaker suspects foul play? (I don't know anything about bluetooth, just guessing)

[mringwal]

The speaker probably only recognizes the Pico W only by the BD ADDR, but I got another idea. This line changes the address of the Pico W, but it's stored link keys don't change. if you connect to the speaker again, it will use the stored link key but the speaker doesn't have one for the new address.

Please try this:

• delete all stored link keys - see below
• use the new code with the unique address (28:..:91) in your case
• put speaker in pairing mode

@peterharperuk what's the easiest way for people to erase BTstack's TLV?

[baltitenger]

I just zeroed the whole flash and it fixed my problem. Thanks!
(feel free to close this, but imo it might be worth putting a note in the changelog or something)

[mringwal]

@peterharperuk short summary: for those with an earlier version of the Pico SDK where the default (43:43:A2:12:1F:AC) was used and that did update, the TLV / Flash contains link keys for bonded devices, but these devices don't recognize us and cannot lookup their link key.

Any idea how to document this? Zeroeing the whole flash obviously works.

[baltitenger]

Can't btstack detect this scenario somehow and automatically forget the key? Or would that have other undesirable side effects?

[mringwal]

For the desktop ports, where you could use multiple USB Bluetooth dongles, all bonding information is stored per BD_ADDR, so this cannot happen.

For an embedded device, the Bluetooth address can/should/will never change on it's own. It won't happen again on the Pico W after the commit you've pointed out, as it will now always have a valid BD_ADDR.

Interesting idea to reset it. But to get it right, we would need to store the BD ADDR in the TLV and can then reset TLV if it changes. However, we should not reset TLV if there's no stored BD_ADDR to compare against it - to not break working systems.

[peterharperuk]

We should probably have put something in the release notes. But it's a bit late for that now.

[peterharperuk]

I'll add a note to the readme about clearing your flash if you have issues.