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.
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
8) 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
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?
>> 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 .
You'rew welcome! Glad you figured it out/got it working!
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
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.