RTOS/CC2640R2F: API to get the central device is already bonded or not

Hi Lee,

Thanks,

Please find the attachment for sniffer log whenBondingScreenShot.zip the bond is removed from central device

I attached it again.

Pls unzip and open in the wireshark.

Please let me know if you still facing the issue.

ThanksBondingScreenShot(1).zip

Can you also attach a normal log?

I am not sure if there is anything we can do to help you on the phone side since we don't have control on the software on the phone.   

2260.log.zipHi RachelP,

We already updated to the version simplelink_cc2640r2_sdk_1_30_00_25.

Now i have attached the log with three use cases

1.After first time bonding reboot the device with bonding deleted at central side.Refer the log bonding_delete_central.pcapng. In this case next time the services and charactristics has the old values and not able to write in to any characteristics

2. After first time bonding delete the bonding at peripheral side(flashing the stack and Application again).Refer the deletebonding peripheral.pcapng. This time the services are not discovering

3. Third one is first time bonding at both the sides. this case everything is fine. Refer the log normalscenario.pcapng.

the Use case 1 and 2 is blocker for us. kindly check at your side and confirm us.

Please provide your feedback to rsolve the issue.

Thank you

with Regards,

Thangaraj.P

Part Number: CC2640R2F

Tool/software: TI-RTOS

Hi ,

I am usnig Ble stack version v3.0.1 (simplelink_cc2640r2_sdk_1_30_00_25.) along with cc2640R2F chipset.

Example Project used : simplelink_cc2640r2_sdk_1_30_00_25.examples\rtos\CC2640R2_LAUNCHXL\blestack\simple_peripheral

uint32_t passkey = 0; // passkey "000000"
uint8_t pairMode =GAPBOND_PAIRING_MODE_INITIATE;
uint8_t mitm = FALSE;
uint8_t ioCap = APBOND_IO_CAP_NO_INPUT_NO_OUTPUT;
uint8_t bonding = TRUE;

All the characteristics in the custom services are configured with and the setting with ENCRYPT_READ and ENCRYPT_WRITE

Now i have attached the log with three use cases

1.After first time bonding reboot the device with bonding deleted at central side.Refer the log bonding_delete_central.pcapng. In this case next time the services and characteristics has the old values and not able to write in to any characteristics

2. After first time bonding delete the bonding at peripheral side(flashing the stack and Application again).Refer the deletebonding peripheral.pcapng. This time the services are not discovering

3. Third one is first time bonding at both the sides. this case everything is fine. Refer the log normalscenario.pcapng.

the Use case 1 and 2 is blocker for us. kindly check at your side and confirm us.

Please provide your feedback to resolve the issue.

Thank you

Please find the log in the attachement

I already [posted in another thread. There is no response

Bondinglog.zip

with Regards,

Thangaraj.P

Hi Thangaraj,

I was unable to recreate your issue with an iPhone 6s. What phone/app are you using as your central device? Can you recreate this issue using Simple Central?

Here is the procedure I used to test the central forgetting the bonding information:

1. I made the modifications to the Simple Peripheral GAP Bond Manager settings that you indicated.
2. Flashed Simple Peripheral app and stack
3. Connect to phone, read and write the characteristics
4. Forget device on iPhone
5. Power cycle Simple Peripheral device
6. Reconnect to phone, read and write the characteristics

Here is the procedure I used to test the peripheral forgetting the bonding information:

1. Connect to phone using same project as above
2. Disconnect from phone and confirm that device information is saved by going to the Bluetooth settings
3. Reflash app & stack projects on launchpad to erase bonding information
4. Reconnect to phone, read and write characteristics.

In both cases, the phone and the LaunchPad re-paired with each other successfully. I didn't have any issue with reading and writing to the Simple Profile characteristics. I was unable to look through your sniffer log since the new one you sent also contained many malformed packets. Can you give me steps to decrypt your sniffer log? I would recommend trying with a different central device or trying to reproduce the issue using the Simple Central example project.

Hi RachelP,

Thanks

The step you mentioned to recreate the problem is perfectly fine.

But we have to make the change in the file simple_gatt_profile.c file in the characteristics property from READ and WRITE to ENCRYPT_READ and ENCRYPT_WRITE.

if i make the below change in the simple_gatt_profile.c file the problem what i mentioned is occurring. changes are marked in the color . Please try it out. I am using the nRF app for testing.

static gattAttribute_t simpleProfileAttrTbl[SERVAPP_NUM_ATTR_SUPPORTED] =

{

 // Simple Profile Service

 {

   { ATT_BT_UUID_SIZE, primaryServiceUUID }, /* type */

   GATT_PERMIT_ENCRYPT_READ,                         /* permissions */

   0,                                        /* handle */

   (uint8 *)&simpleProfileService            /* pValue */

 },

   // Characteristic 1 Declaration

   {

     { ATT_BT_UUID_SIZE, characterUUID },

     GATT_PERMIT_ENCRYPT_READ,

     0,

     &simpleProfileChar1Props

   },

     // Characteristic Value 1

     {

       { ATT_BT_UUID_SIZE, simpleProfilechar1UUID },

       GATT_PERMIT_ENCRYPT_READ | GATT_PERMIT_ENCRYPT_WRITE,

       0,

       &simpleProfileChar1

     },

     // Characteristic 1 User Description

     {

       { ATT_BT_UUID_SIZE, charUserDescUUID },

       GATT_PERMIT_ENCRYPT_READ,

       0,

       simpleProfileChar1UserDesp

     },      

   // Characteristic 2 Declaration

With Regards,

Thangaraj.P

Hi Thangaraj,

We are still trying to figure out why the CC2640R2 is having trouble when the peer device loses its keys. However, there is a way to erase the bonds so that you can re-encrypt your connection. Please see the following thread for that workaround:

https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/588602/2187245#2187245

For the case where the CC2640R2 loses its keys, it doesn't look like the CC2640R2 doing anything wrong in this scenario. The master tries to start encryption but the CC2640R2 responds with "PIN or key missing" as it should. At this point, the master should start a new key exchange. I believe this is because for, for iOS devices, they are looking for a different response. I am also attaching the full sniffer log from the Ellisys below.

/cfs-file/__key/communityserver-discussions-components-files/538/slaveerasesbonds.btt

Hi Thangaraj,

For future posts, lets refer to the problem that occurs when the master forgets its keys as Case 1 and when the slave forgets its keys as Case 2 to reduce confusion.

We are still working on Case 1. For the workaround, instead of using a button press, you could use the GAP Bond Manager pairing callbacks instead to force the bonds to erase on a failed pairing. This would avoid manual intervention

We do not have a fix for Case 2 because, as you can see from the sniffer capture, the CC2640R2 is sending the correct response. The master should send another pairing request at this point. For iOS devices, the Bluetooth Accessory Design Guidelinesare pretty clear about how to prompt a pairing request from the peripheral. You can look at the GATT Security section of the TI Bluetooth low energy Software Developer's Guide for information on how to implement this.

Hi Thangaraj,

I am attaching a version of simpleperipheral.c with pairing callbacks added so the device will automatically reset when pairing fails due to the DH Key Check Error. This should allow you to continue testing while we investigate Case 1. If your device doesn't advertise after the reset, make sure you are using the latest version of the TI Emulators.

/cfs-file/__key/communityserver-discussions-components-files/538/7522.simple_5F00_peripheral.c

Hi RachelP,

please let us know what the state of the art is w.r.t. this issue in TI's BLE stack.
For us as well as our customers it's a bit of a nuisance having to ensure that keys are deleted always on both BLE devices, Central and Peripheral.

Can you please further let me know the bug ID that you are using for following up this issue.
Background: I need this reference when ploughing through the TI BLE stack Release Notes document for finding out what version of the TI BLE stack Release Notes fixes the problem.

Many thanks in advance for your reply.

Regards,
Frank.

Hello Frank,

Your timing is quite opportune. The new SDK 1.40 With BLE Stack 3.1.0 where this anomaly is addressed is available for download at SIMPLELINK-CC2640R2-SDK.

Best wishes