CC2340R5: Issue with erasing bond information in GATT_client example

Hello Vignesh,

Thanks for reaching out.

Please help me confirming you are doing the following steps to make sure I understand your process well:

1. Central (executing basic_ble_GATT_client) connects to Peripheral (running basic_ble).
2. Both devices pair and bond (Pairing Status: Bond saved).
3. Central enables and receives notifications.
   
4. Central disconnects from peripheral and erase ALL bonds through GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, 0, NULL).
   
5. Central connects to Peripheral.
6. Both devices pair and bond (Pairing Status: Bond saved).
7. Central tries to enable notifications and Pairing Status: Bond saved changed to Pairing Status: Encrypted on central and peripheral.
   
8. Central cannot enable notifications.
9. Central can send data through GATT_Writeto peripheral.
   

Please also help me with the following questions to assist you further:

1. What you are describing is happening after only saving and then erasing 1 bond?
2. Who starts the paring/bonding process (central or peripheral)?
3. Have you done any modifications to either of the two projects (basic_ble and basic_ble_GATT_client) other than adding the GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, NULL, NULL) in the Menu_disconnectCB()  for basic_ble_GATT_client?
4. What configuration do you have for the Bond Manager in SysConfig?

   

Just for information, the basic_ble_GATT_client example in Github is running with the 7.20.00.29 SDK, however this may not be related to what you are seeing. The newest version is being updated online soon, but in the meantime you can check the following: CC23xx SDK 7.20 to CC23xx SDK 7.40

BR,

David.

Hi david,

        Thanks and here the details for your questions

• What you are describing is happening after only saving and then erasing 1 bond?

                -Yes, for testing in central we are saving bond of one peripheral device and erasing bond information only in central while disconnecting.

• Who starts the paring/bonding process (central or peripheral)?

                - In syscfg pairing mode set has initiate pairing request in central and wait for pairing request in peripheral so pairing happens when connected with link has established .

• Have you done any modifications to either of the two projects (basic_ble and basic_ble_GATT_client) other than adding the GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, NULL, NULL) in the Menu_disconnectCB()  for basic_ble_GATT_client?

                - we  didn't modified the code except the pairing mode in both central and peripheral and bond erase in central.

• What configuration do you have for the Bond Manager in SysConfig?

Peripheral:

Central:

And sorry for an mistake I have using an basic_ble_GATT_client in SDK version 

SDK Version : simplelink_lowpower_f3_sdk_7_20_01_10(peripheral and central)

CCS version: CCS 12.5.0

Where custom application using an SDK version 

SDK Version : simplelink_lowpower_f3_sdk_7_40_00_64 (peripheral and central)

CCS version: CCS 12.5.0

Thanks,

Vignesh.

Hello Vignesh,

Could we please help me check a couple of things here?

1. Verity that the function GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, 0, NULL) returns SUCCESS status when called from the Menu_disconnectCB() at the CENTRAL.
2. Verify if the bond have been erased at the PERIPHERAL. In this case, GAP_BOND_LOST_EVENT should be received when the bond has been removed on peer.

In addition, could you please confirm the steps I wrote in my first answer are the ones you are following to reproduce this scenario?

Do you happen to have a Bluetooth sniffer? Having the logs of what is happening over the air can be helpful here.

BR,

David.

Hi David,  

1. Verity that the function GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, 0, NULL) returns SUCCESS status when called from the Menu_disconnectCB() at the CENTRAL.

                 - Status returning as SUCCESS when calling an function GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, 0, NULL) .

         2. Verify if the bond have been erased at the PERIPHERAL. In this case, GAP_BOND_LOST_EVENT should be received when the bond has been removed on peer.

                -  GAP_BOND_LOST_EVENT not receiving in peripheral when the bond has been removed on peer.

here the code for GAP_BOND_LOST_EVENT added in a function void Connection_ConnEventHandler(uint32 event, BLEAppUtil_msgHdr_t *pMsgData) in app.connection.c

 void Connection_ConnEventHandler(uint32 event, BLEAppUtil_msgHdr_t *pMsgData)
{
    switch(event)
    { 
		case BLEAPPUTIL_BOND_LOST_EVENT:
        {
            gapBondLostEvent_t *gapbondmsg = (gapBondLostEvent_t *)pMsgData;

            MenuModule_printf(APP_MENU_PROFILE_STATUS_LINE16, 0, "BOND_LOST_EVENT "
                                         "connectionHandle = "MENU_MODULE_COLOR_YELLOW "%d " MENU_MODULE_COLOR_RESET
                                         "device address = "MENU_MODULE_COLOR_YELLOW "%s " MENU_MODULE_COLOR_RESET,
                                         gapbondmsg->connectionHandle,
                                         BLEAppUtil_convertBdAddr2Str(gapbondmsg->deviceAddr));
            break;
        }
	}
}

In addition, could you please confirm the steps I wrote in my first answer are the ones you are following to reproduce this scenario?

- Yes, those are the steps to reproduce the scenario.

Thanks,

Vignesh.

Hi Vignesh,

With regards to

vignesh s said:

         2. Verify if the bond have been erased at the PERIPHERAL. In this case, GAP_BOND_LOST_EVENT should be received when the bond has been removed on peer.

                -  GAP_BOND_LOST_EVENT not receiving in peripheral when the bond has been removed on peer.

If I may, if you erase the bond on the PERIPHERAL side, the GAP_BOND_LOST_EVENT is expected to be received on the CENTRAL side.

Can you please check this for us?

Also, can you answer David's question about you having access to a Bluetooth sniffer?

Best regards,

Hi Clement,

          I have erased the bond on the PERIPHERAL side while disconnection calling the  GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, NULL, NULL) in Menu_disconnectCB() at the Peripheral.

GAP_BOND_LOST_EVENT not receiving in central when the bond has been removed on peer. when again going for an connection to peripheral with authentication  and (Pairing Status: Bond saved) success. Now after MTU exchange trying to enable the Notification immediately where the  Pairing Status: Bond saved changed to Pairing Status: Encrypted on both central and peripheral.

Also, can you answer David's question about you having access to a Bluetooth sniffer?

  - sorry we don't have an Bluetooth sniffer.

we can reproduce an issue  following steps by David's first reply.

thanks.

Hello Vignesh, 

Thank for you the confirming this.

Could you also please confirm that BLEAPPUTIL_BOND_LOST_EVENT has also been added to .eventMask in connectionConnHandler inside app_connection.c?

Based on the steps I am working on reproducing the issue you see. Please bear with me.

In the meantime, and for sanity check, could we please try both of the projects to run on the same SDK? For this purpose, we have a migration guide you can follow for updating basic_ble_GATT_client  to the latest SDK: here

BR,

David.

Hi David,

     Could you also please confirm that BLEAPPUTIL_BOND_LOST_EVENT has also been added to .eventMask in connectionConnHandler inside app_connection.c?

    - Yes I have added  BLEAPPUTIL_BOND_LOST_EVENT in .eventMask in connectionConnHandler inside app_connection.c.

I have tried both Basic_ble_Peripheral project and basic_ble_GATT_client project  with same  SDK with the help of migration guide still the behavior was same as Old SDK.

SDK Version : simplelink_lowpower_f3_sdk_7_40_00_64 (peripheral and central)

CCS version: CCS 12.5.0

Thanks,

Vignesh.

Hello Vignesh,

Thanks for the answer.

I have conducted a series of tests: 1) using basic_ble configured as both central and peripheral, 2) using basic_ble configured as peripheral and central configured with host test with BTool, 3) using basic_ble configured as peripheral and basic_ble_GATT_client configured as center. In every test the Peripheral is config as "Wait for a pairing request" and the central to "Initiate a pairing request" as in your case.

I am not able to reproduce your case so far with the steps we discussed:

• Central (executing basic_ble_GATT_client) connects to Peripheral (running basic_ble).
• Both devices pair and bond (Pairing Status: Bond saved).
• Central enables and receives notifications.
  
• Central disconnects from peripheral and erase ALL bonds through GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, 0, NULL).
  
• Central connects to Peripheral.
• Both devices pair and bond (Pairing Status: Bond saved).
• Central enables notifications
• Pairing Status: Bond saved changes to Pairing Status: Encrypted on central and peripheral.
  
• Central enables notifications
• Central can send data through GATT_Write to peripheral characteristic 3, which will echo the same data through the characteristic 4 as a notification.
  

FYI: The notification data is not encrypted as I am using ECC Debug Keys.

Attached are some of the Bluetooth sniffer logs.

First Connection and Bonding:

After erasing the first bond (ERASE ALL BONDS) and generation a new connection and bond:

Central (when the previous steps are finished):

Peripheral (when the previous steps are finished):

Pleas help me with the following questions:

1. Could you please share a bit more about the notification issue you have?
2. What characteristic are you writing to for the notifications?
3. How do you know it is not sending any notification?
4. Are we missing a step here? Could you please double check the steps I am following to reproduce this?

Best Regards,

David.

Hi David,

        Thank you for reproduce our case

Please help me with the following questions:

1. 1. Could you please share a bit more about the notification issue you have?
2.                No, we are using example GATT Client so we didn't modified any notification functions.
3.  
4.         b. What characteristic are you writing to for the notifications?
5.               - Same as you sending Characteristics 3 data where 0x00,0x02,0x55,0xff.
6.  
7.         c  How do you know it is not sending any notification?
8.              - From GATT Client  sending an data to peripheral  in characteristic 3 and data receiving in peripheral as expected and which will echo the same data through the characteristic 4 as a notification. But the data is not receiving in GATT client.
9. 
   with an above steps I need to know?

Central (when the previous steps are finished):

According to this image data has send in characteristic 3 (Write send = 0xff ).

Data received in peripheral as expected and which will echo the same data through the characteristic 4 as a notification. But the data is not received in GATT client has 0xff.Still Notification received = 0x02. May I know why.

                  d . Are we missing a step here? Could you please double check the steps I am following to reproduce this?

                         - After bond erase central connected to peripheral now after bond save have u done notification enable from central.

Thanks,

Vignesh.

Hello Vignesh,

Thanks for pointing that out. I was focusing on the notifications being enabled, but I see there is something wrong with the reception of them after a bond erase. I have already reported this to the team to look in more detail on how it can be solved. Please bear with me.

I will be back with an status on Thursday.

BR,

David.

Hi David,

       Any update?

Thanks.

Hi Vignesh,

We have taken this discussion with TI's R&D team.

In order to debug further, they ask us to specify the GATT permissions for the notification characteristics you are trying to access.

Could you please provide the GATT permissions for the value and the characteristic configuration?

If needed, the existing permissions are specified below:

Appreciate your inputs,

Best regards,

Hi Clement,

      GATT permissions for the notification characteristics of peripheral 

   // Characteristic 4 Declaration
   GATT_BT_ATT( characterUUID,                GATT_PERMIT_READ,                      &simpleGattProfile_Char4Props ),
   // Characteristic Value 4
   GATT_BT_ATT( simpleGattProfile_char4UUID,  0,                                     &simpleGattProfile_Char4 ),
   // Characteristic 4 configuration
   GATT_BT_ATT( clientCharCfgUUID,            GATT_PERMIT_READ | GATT_PERMIT_WRITE,  (uint8 *) &simpleGattProfile_Char4Config ),
   // Characteristic 4 User Description
   GATT_BT_ATT( charUserDescUUID,             GATT_PERMIT_READ,                      simpleGattProfile_Char4UserDesp ),

Thanks.

Hi Clement,

     Any update?

Thanks.

Hi clement,

Any update?

we are waiting for an solution since week's. Please reply ASAP.

Thanks,

Vignesh. 

Hello Vignesh,

Apologies for the delay.

We have done some further inspection with the team and currently we are following a lead based on ATT_HANDLE_VALUE_NOTI not being received on GATT_EventHandler (app_data.c) after the bond has been erased. However the first function that process a received message -> gattClientProcessMsgCB (gatt_client.c) is actually receiving a ATT_HANDLE_VALUE_NOTI in both cases (before and after bond erase).

I am working with the team to provide you with more information about this an a potential workaround tomorrow.

In the meantime, can I ask if you have tried erasing a single-bond and if this could be contemplated by your use case?

BR,

David.

Hello Vignesh,

To keep you updated on this issue. We have additionally found that after the second bond has been established the MAP_linkDB_Authen(connHandle, keySize, mitmReq) returns LINBDB_ERR_INSUFFICIENT_KEYSIZE instead of SUCESS. This will set the notifyApp variable to FALSE, not allowing the stack to forward the message (notification) to the upper layer application. We are still looking into the issue. Please bear with us.

Thanks.

David.