CC2340R5: Issue with authentication of notification characteristics

Hi Vignesh,

Thank you for reaching out.

May I kindly ask you to provide the code snippet used to turn on notification on the central side? Among others, I would like you ensure you are using an approach compatible with the permission on the CCD characteristic (maybe using GATT_SignedWriteNoRsp).

Best regards,

Hi clement, 

        I have tried using the GATT_SignedWriteNoRsp but getting an status as an invalid parameter.

thanks.

Hi,

Can you share how you are calling the GATT_SignedWriteNoRsp()? Particularly, can you share how you are setting up the payload?

Best Regards,

Jan

Hi Jan,

        Here the code for calling the GATT_SignedWriteNoRsp()

void Menu_doEnableNotification(uint8 index)
{
    bStatus_t status;
    attWriteReq_t req;

    uint8 configData[2] = {0x01,0x00};
    req.pValue = GATT_bm_alloc(menuCurrentConnHandle, ATT_WRITE_REQ, 2, NULL);

    // Enable notify for outgoing data
    if (req.pValue != NULL)
    {
        req.handle = 47;
        req.len = 2;
        memcpy(req.pValue, configData, 2);
        req.cmd = TRUE;
        req.sig = FALSE;
//      status = GATT_WriteNoRsp(menuCurrentConnHandle, &req);
        status = GATT_SignedWriteNoRsp(menuCurrentConnHandle, &req);
    }
    MenuModule_printf(APP_MENU_GENERAL_STATUS_LINE, 0, "Call Status: GATT Notification = "
                          MENU_MODULE_COLOR_BOLD MENU_MODULE_COLOR_RED "%d" MENU_MODULE_COLOR_RESET,
                          status);
}

thanks.

Hi,

Based on your code, I believe you should allocate with the ATT_WRITE_RSP instead. Can you try that and test?

Best Regards,

Jan

Hi Jan ,

        I have tried allocating with ATT_WRITE_RSP but  still getting an status as an invalid parameter.

thanks.

Hi,

Can you try setting the .sig parameter to true/1? This bit is the authentication signature status, so the command is likely being rejected because it is expecting this value to be 1.

Best Regards,

Jan

Hi Jan,

         I have tried setting the .sig parameter as TRUE now getting an status as an   bleLinkEncrypted                0x19  (The link is already encrypted).

For information : n syscfg pairing mode set has initiate pairing request in central and wait for pairing request in peripheral so pairing happens when  link has established .

Configurations for the Bond Manager in SysConfig

Peripheral:

Central:

Thanks,

Vignesh.

Hi Vignesh,

Understood. If the connection is already encrypted, then there is no need to use the signed version of the function, so that is why it is returning that return code. Since the link is already encrypted, then you should use the non-signed version of the operation. Can you verify if doing that resolves the behavior you are seeing?

Best Regards,

Jan

Hi Jan,

          Please can you tell which non-signed version should I use for this operation.

Thanks,

Vignesh.

Hi Vignesh,

I think the GATT_WriteNoRsp() API should work in this case. Can you verify if it implements the desired functionality.

Best Regards,

Jan

Hi Jan,

          I already tried where GATT_WriteNoRsp() API is working good iwith  GATT_PERMIT_READ  |GATT_PERMIT_WRITE  but with GATT_PERMIT_AUTHEN_READ  |GATT_PERMIT_AUTHEN_WRITE  status getting as success but notification not enabling on peripheral.

Thanks,

Vignesh.

Hi Vignesh,

Understood. Thank you for confirming. I would like to see what is actually occurring over the air. Do you have access to a sniffer log? Could you provide a log where you attempt to enable notifications with the GATT_WriteNoRsp() when using the AUTHEN permission?

Best Regards,

Jan

Hi Jan,

    Sorry that we don't have any BLE sniffer to get a log. Could you please check.

Thanks,

Vignesh.

Hi Vignesh,

Got it. I can try to reproduce this on my side with a sniffer. Could you provide us with a basic_ble project with the minimum modifications to recreate the behavior? I would like to ensure we are working off the same project.

Best Regards,

Jan

Hi Jan,

 BASIC_BLE.rar

Here the example basic_ble project with the  modifications in syscfg pairing mode set has initiate pairing request in central and wait for pairing request in peripheral so pairing happens when  link has established and GATT permissions for the notification characteristics 

   // 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 ),

//   GATT_BT_ATT( clientCharCfgUUID,            GATT_PERMIT_AUTHEN_READ | GATT_PERMIT_AUTHEN_WRITE,  (uint8 *) &simpleGattProfile_Char4Config ),

   // Characteristic 4 User Description
   GATT_BT_ATT( charUserDescUUID,             GATT_PERMIT_READ,                      simpleGattProfile_Char4UserDesp ),

Thanks.

Hi,

Can you also share the central code as well? This will ensure I have the same setup on my side for debugging?

Best Regards,

Jan

Hi Jan,

     Here the example Basic_BLE_GATT_Client project with the  modifications in syscfg pairing mode set has initiate pairing request in central. 

SDK Version : simplelink_lowpower_f3_sdk_7_40_00_64 (peripheral and central)

CCS version: CCS 12.5.0

BASIC_GATT_CLIENT.rar

Thanks,

Vignesh.

Hi Vignesh,

Got it. Thank you. I should have access to a bluetooth sniffer tomorrow and can run a quick test. I will update you with results.

Best Regards,

Jan

Hi Vignesh,

Ran a quick test, but I am not sure if I saw the issue. I was able to connect both boards, enable notifications, and receive notifications (after a GATT write). Please correct me if im wrong, but I thought the issue was that the notification enable was sent, but not received by the peripheral?

Log attached for your reference:

 https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/notificationLog.btt

Best Regards,

Jan

Hi Jan,

    Thank you for your initiate.

Here there are two test cases.

Case 1 - Where in peripheral configuration for notification characteristics has GATT_PERMIT_READ | GATT_PERMIT_WRITE. Now notification has enabling and GATT Write has happening and data receiving in peripheral and echoing the data to central.

Case 2 - Where in peripheral configuration for notification characteristics has GATT_PERMIT_AUTHEN_READ  |GATT_PERMIT_AUTHEN_WRITE. Now with Enable Notification status has giving as success but notification not enabling in peripheral and GATT Write has happening and data receiving in peripheral 

May I know what is the configuration for notification characteristics in peripheral where you used for reproducing the issue.

can you try with both both above cases. 

Thanks,

Vignesh.

Hi Vignesh,

My apologies, seems it was set to permit and not permit_authen. I will re-test this tomorrow and report back

Best Regards,

Jan

Hi Vignesh,

I have reproduced this on my side as well. I believe the issue may be that GATT_PERMIT_AUTHEN requires a different pairing or encryption setup. Can you specify which pairing/encryption configuration you are planning to use? Also, if you simply want to encrypt the attribute, then you can use the GATT_PERMIT_ENCRYPT permission. With this one, the data is encrypted (must be in a paired connection). I have tested the project and using the ENCRYPT version, I am able to successfully enable the notifications and see them be received:

Best Regards,

Jan

Hi Jan,

Thank you for your response.

 When using the GATT_PERMIT_ENCRYPT permission central can able to enable the notifications and as well in mobile while enabling notification its going for an authentication(Pairing). After successful authentication notification has enabled as expected and thank you for the effort.

Now I have changed  Basic_Ble_peripheral passcode as B_APP_DEFAULT_PASSCODE1  - 112233 with mobile while enabling notification its going for an authentication(Pairing). After successful authentication notification has enabled as expected  with updated passcode.

But in central I didn't modified an default passcode and trying to connect with peripheral as expected pairing fail has to happen but pairing success and Bond save has happening. May I know how the pairing has happening from central and why central and peripheral didn't validate the passcode. In peripheral why Pairing_passcodeHandler function has not executed.

whether I am missing or doing mistake from my side. Please let me know.

And sorry I don't have any Bluetooth sniffer log to provide.

I am using Gatt_client code without modifying  where I have already provided and in Basic_ble_peripheral have modified in B_APP_DEFAULT_PASSCODE1 in pairing.c and GATT_BT_ATT( clientCharCfgUUID, GATT_PERMIT_ENCRYPT_READ | GATT_PERMIT_ENCRYPT_WRITE,  (uint8 *) &simpleGattProfile_Char4Config ), in simple_gatt_profile.c.

Thanks,

Vignesh.

Hi Vignesh,

Glad to hear the last code snippet was helpful! Regarding the pin behavior, can you try performing a mass erase on both boards, reflashing and trying again? I would like to ensure there isnt any weird behavior occurring due to previous bonds being stored. Could you also confirm how you are changing the password? Is the define a local define or was it added to an SDK file?

Best Regards,

Jan

Hi Jan,

     I have performed freshly code loaded modules for testing so there is no any bond save happen previously.

Yes, I have created an #define B_APP_DEFAULT_PASSCODE1         112233  in pairing.c (Basic_ble_peripheral)

SDK file I didn't modified an  B_APP_DEFAULT_PASSCODE   where 123456.

Thanks,

Vignesh.                 

Hi Vignesh,

Understood, I think we need to see whats happening over the air to see what may be happening. Can you share the projects with me again (with these latest changes)? I can run a quick sniffer log to see whats going on.

Best Regards,

Jan

Hi Jan,

Here the projects with latest changes in peripheral #define B_APP_DEFAULT_PASSCODE1         112233  in pairing.c (Basic_ble_peripheral). In central I didn't modified anything where I have shared already attached now.

7024.BASIC_BLE.rar

0068.BASIC_GATT_CLIENT.rar

Thanks,

Vignesh.

Hi Vignesh,

Got it. Thank you. I will test this tomorrow and get back to you.

Best Regards,

Jan

Hi Vignesh,

I was able to reproduce the behavior you are seeing. Interestingly, even though the pairing success was seen. The peripheral does not allow the characteristic to read Char 5 which confirms the pairing was not accepted. I did a quick test with my smart phone and put in the wrong pin upon being prompted and got the following log:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/FailedPairPhone.btt

Which shows the pairing failing. This is expected.

When testing with your project, it seemed that the central was in charge of pairing and it went by its rules. However, I tried changing the IO capabilities of the central device and that seemed to fix the issue. The pairing fail would be seen over there as shown in the following log:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/displayAndKeyboardIOCapabilities.btt

Best Regards,

Jan

Hi Jan,

 Sorry for the late response.

I have tested by changing the IO capabilities of the central device as Both Keyboard and Display Capable and pairing failed as expected.

Now setting the both peripheral and gatt_client passcode as #define B_APP_DEFAULT_PASSCODE1         112233 where 
Pairing Status: Started - connectionHandle = 0 status = 0  to 
Pairing Status: Bond saved - connectionHandle = 0 status = 0 its takes approx. 104 seconds to complete the pairing and bond save. But pairing has to complete less than 10 sec but its taking 104 sec approx. may I know why? or I have missed something? 

May I know which IO capabilities need to update in both central and peripheral.

Thanks,

Vignesh.

Hi Vignesh,

Glad to hear you are seeing the expected pairing failure behavior now. To speed up pairing, you can try disabling the "Send Parameter Update Request" option in SysConfig:

vignesh s said:

May I know which IO capabilities need to update in both central and peripheral.

The IO capabilities selected depend both on the actual IO capabilities of the device and the desired security configuration that is desired. There is some information about this in the Bluetooth article linked below:

https://www.bluetooth.com/blog/bluetooth-pairing-part-1-pairing-feature-exchange/

Best Regards,

Jan

Hi Jan,

Thank you for the response.

Jan said:

To speed up pairing, you can try disabling the "Send Parameter Update Request" option in SysConfig:

I have tried but still takes approx. 104 seconds to complete the pairing and bond save.

Thanks,

Vignesh.

Hi Vignesh,

Understood, I think taking a sniffer log may be helpful here. Could you provide me with the exact pairing and bonding settings you are using? That way I can take a log early next week and see who is waiting on who.

Best Regards,

Jan

Hi Jan,

Thank you,

Jan said:

Could you provide me with the exact pairing and bonding settings you are using?

Here the images of bond settings in basic_ble and GATT_client

GATT_client:

basic_ble:

I have tried where 
Pairing Status: Started - connectionHandle = 0 status = 0  to 
Pairing Status: Bond saved - connectionHandle = 0 status = 0 its takes approx. 104 seconds to complete the pairing and bond save. But pairing has to complete less than 10 sec but its taking 104 sec approx.

Here our  actual requirement is Basic_ble IO capabilities- Display only device and Gatt_client IO capabilities was No Display or Input Device. We are trying to pair with default passkey.

Thanks,

Vignesh.

Hi Vignesh,

Got it. I will have access to a BLE sniffer sometime tomorrow, so I hope to take a log and see over the air what is causing the delay then. I will update you once I am able to record the log.

Best Regards,

Jan

Hi Vignesh,

I took two basic ble projects and made one the peripheral and the other the central. The only modifications I made were the following sysconfig changes:

Central:

Peripheral:

However, pairing time was fairly quick. Over the air I saw the following:

Which shows pairing completing in a few seconds. I have uploaded the projects below:

basic_ble_Peripheral.zip

basic_ble_central_project.zip

Can you see if you observe the same pairing delay on your side? If not, then could you provide me with your projects to test on my side?

Best Regards,

Jan

Hi Jan,

Thank you. 

I have tested with reference of bond settings both basic_ble_central and basic_ble_peripheral where pairing completing in a few seconds.

From starting  of the  thread I am using basic_ble_peripheral and basic_ble_GATT_client and testing has performed in these projects only. So, I didn't tried with basic_ble_central.

This has resolved my issue.

 I was testing basic_ble_GATT_client  with TI example  central example available on GitHub  SDK version 7.20 later I have migrated to SDK version 7.4 with the help of migration guide.

 https://github.com/TexasInstruments/ble_examples/tree/simplelink_low_power_f3_sdk-7.20/examples/rtos/LP_EM_CC2340R5/ble5stack/basic_ble_GATT_client

with this project its takes approx. 104 seconds to complete the pairing and bond save. Please can you check why its taking long to complete the pairing with  basic_ble_GATT_client .

Thanks,

Vignesh.

Hi Vignesh,

My apologies, during my testing I forgot you were working off GATT client. My guess is that there are some application code differences between the unmodified 7.40 basic_ble and the GATT client example which are causing this increased pairing time. I will be out of office tomorrow due to U.S. holiday, but i can take a closer look at the potential code differences on monday. In the meantime, could you see if the pairing, central, connection files in the GATT client project have any significant differences when compared to the basic ble project?

Best regards,

Jan

Hi Vignesh,

My apologies for the delay. We have released the 7.40 SDK version of the GATT Client project. As a quick test, could you try using that version of the project instead? The project had some application code improvements that may have an impact on the pairing time.

Best Regards,

Jan