Android phone initiates pairing again with already bonded devices.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I have two PSOC 4 ble dev kit configured to work as peripheral(s) with simple static pass pairing program and Android phone as client.

1) peripheral_1 address = 0xCECECECECE with static passkey 123456, Device name = Garden, appearance = generic tag.

2) peripheral_2 address = 0xC1C1C1C1C1 with static passkey 123455, Device name = Garden, appearance = generic tag.

Both peripherals IO configured as display only.

I try to connect to peripheral_1 through cysmart app, I get pop-up to feed passkey, after giving correct passkey the devices are bonded and all good.

repeated the same proceedure with peripheral_2 and all good as well.

Now the real problem comes in. After disconnecting with peripheral_2, I tried to connect to peripheral_1, I get pop again to feed in passkey for already bonded device, why?

Also, after feeding in the passkey I can't read any of the characteristics values unless I disconnect and re-connect to peripheral_1. Why?

Now I repeat with peripheral_2 and I see the same behavior(client asks to feed in passkey again).

I believe the STK/LTK should be uniquely generated based on the BT address and store in client's database.

Suppose if I change the appearance of one of the peripheral to "unknown" then I see the client does not ask for passkey to re-enter again after bonding. Only with this combination

appearance it works("unknown" vs "<any other tag>").

I doubt if there is any issue with PSoc 4 Ble deleting bonding info as I don't see this issue if I re-connect again with only one peripheral.

Any inputs, suggestions are greatly appreciated.

0 Likes
1 Solution
Anonymous
Not applicable

I suspect it is an app-side thing for the Android software, and I don't know anything about that

But, having the devices' appearances differing allowing them to both work correctly seems to point to the Android trying to distinguish the device based on the name alone, and when they both have the same name, it rewrites the bonding information associated with that device when connecting to the second peripheral?

That would explain why it tries just directly connecting versus trying to read the characteristic (it tries to encrypt/bond and doesn't succeed, so it skips to reading the characteristic and then returns to re-authenticate when that fails with security error)

PS: Referring to the peripheral needing time to bond, it was more a thought than a serious consideration, but worth asking about

If the Android Client is the one initiating pairing/bonding/encryption each time, then it would be code on the Android that effects the different behavior on connecting; Otherwise, it could be that the peripheral is initiating the security from it's side when it was recently connected or something similar?

View solution in original post

0 Likes
7 Replies
Anonymous
Not applicable

Try a combination of different: Device name, Passkey to see if the bonding information is being stored associated with the device name or passkey incorrectly. That would explain why it thinks you are using the wrong bond information and requesting a new bond procedure?

Otherwise, double check that you are giving the peripheral time to save the bond data.

0 Likes
Anonymous
Not applicable

Tried different combination of Device name , passkey but nothing works.

I did sniff the air traces and below are my observations

1) Scan and connected to peripheral_1

2) Trying to read characteristics attribute - fails as this is encrypted and needs authentication.

3) Android initiates pairing - passkey entered

4) Starts encryption - Link is now encrypted.

5) Read characteristics attribute succeeds.

6) disconnect peripheral_1

7) re-connect peripheral_1

😎 Android client starts encryption on connected(it does not wait for reading characteristics)

9) read characteristics attribute succeeds.

10) disconnect peripheral_1

11) Connect to peripheral_2

12) Trying to read characteristics attribute - fails as this is encrypted and needs authentication.

13) Android initiates pairing - passkey entered

14) Starts encryption - Link is now encrypted.

15) Read characteristics attribute succeeds.

16) disconnect peripheral_2

17) re-connect peripheral_1

18) Trying to read characteristics attribute - fails as this is encrypted and needs authentication.

19) Android initiates pairing - passkey entered

20) Starts encryption - Link is now encrypted.

21) Read characteristics attribute succeeds.

Make a note of step (8) and (18) : Android starts encryption immediately after connected to peripheral_1 but in step (18) it does not even though peripheral_1 is BOND_BONDED as per .getBondState(peripheral_1), why?

>> Otherwise, double check that you are giving the peripheral time to save the bond data.

If peripheral does not get enough time, I would have seen this issue with single peripheral. With single peripheral the bonding happens first time and subsequent sessions it connects, read

characteristics, with out an bonding again.

PS: I did accidentally changed the appearance of one of the device to "unknown" and other was "generic_tag", In this case the bonding was not lost and both the devices happliy works.

This seems bit weird.

Any help is much appreciated

0 Likes
Anonymous
Not applicable

I suspect it is an app-side thing for the Android software, and I don't know anything about that

But, having the devices' appearances differing allowing them to both work correctly seems to point to the Android trying to distinguish the device based on the name alone, and when they both have the same name, it rewrites the bonding information associated with that device when connecting to the second peripheral?

That would explain why it tries just directly connecting versus trying to read the characteristic (it tries to encrypt/bond and doesn't succeed, so it skips to reading the characteristic and then returns to re-authenticate when that fails with security error)

PS: Referring to the peripheral needing time to bond, it was more a thought than a serious consideration, but worth asking about

If the Android Client is the one initiating pairing/bonding/encryption each time, then it would be code on the Android that effects the different behavior on connecting; Otherwise, it could be that the peripheral is initiating the security from it's side when it was recently connected or something similar?

0 Likes
Anonymous
Not applicable

>> If the Android Client is the one initiating pairing/bonding/encryption each time,

Yes, it is Android client.  From more testing and air traces looks like Android behavior.

Thank you very much for your thoughts .

Anonymous
Not applicable

You'rew welcome! Glad you figured it out/got it working!

epratt

0 Likes
Anonymous
Not applicable

Nope, I could not get this working as I don't have any control on SMP layer of Android stack.

Raised ticket on Android issue tracker. Seems that is not going forward

0 Likes
Anonymous
Not applicable

Bummer! Well, identifying the problem is the first step in fixing it

Potentially, you could mess with having the peripheral request the security handshake from its side first to preempt the android stack issue, but it is a long shot for that.

0 Likes