CC2651R3: Previously bonded devices can not connect in whitelist mode

Hi,

It is possible there may be some minor changes between the SDK releases which must be taken account of in the application. I recommend looking over the migration guides listed in the following page: https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/migration-cc13xx_cc26xx.html

These guides will mention any major changes between SDK versions that should be accounted for.

Best Regards,

Jan

Hi Jan,

I have patched the project with these changes however, the behavior I described remains unchanged/ erroneous

Hi,

Got it. Thank you for looking into this. I would like to ensure we are not missing anything regarding the procedure expected in 7.41. Can you take an SDK example project from 7.41, add the white list code and see if the project does perform whitelisting correctly?

Best Regards,

Jan

Hi Jan, I have added the necessary source code to the simple peripheral example in the SDK v7.41 to enable two advertising sets: pairable and whitelisting.

However, the same problem can be observed here, please see the screenshots in nRF Connect App:

- Connection while being in pairable adv mode: pairing and bonding is successful.

- Connection while being in whitelisting adv mode: connection for already paired and bonded device is rejected

Hi,

Thank you for the test. Can you share the code snippets you are using to enable the whitelisting? Does it follow the format outlined in task 3 of the Advanced Security Features SLA?

Best Regards,

Jan

Hi Jan,

Here are the requested details:

adv parameters for whitelist adv mode:

adv parameters for the pairable adv mode:

bond manager settings:

- code snippet that configures and enables whitelist adv mode

        //Advertisement for whitelisted devices
        BLE_LOG_INT_INT(0, BLE_LOG_MODULE_APP, "APP : ---- call GapAdv_create set=%d,%d\n", 0, 0);
        // Create Advertisement set #1 and assign handle
        status = GapAdv_create(&SimplePeripheral_advCallback, &advParams1,
                               &advHandleLegacy_ForWhitelistedDev);
        SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

        // Load advertising data for set #1 that is statically allocated by the app
        status = GapAdv_loadByHandle(advHandleLegacy_ForWhitelistedDev, GAP_ADV_DATA_TYPE_ADV,
                                     sizeof(advData1), advData1);
        SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

        // Load scan response data for set #1 that is statically allocated by the app
        status = GapAdv_loadByHandle(advHandleLegacy_ForWhitelistedDev, GAP_ADV_DATA_TYPE_SCAN_RSP,
                                     sizeof(scanResData1), scanResData1);
        SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

        // Set event mask for set #1
        status = GapAdv_setEventMask(advHandleLegacy_ForWhitelistedDev,
                                     GAP_ADV_EVT_MASK_START_AFTER_ENABLE |
                                     GAP_ADV_EVT_MASK_END_AFTER_DISABLE |
                                     GAP_ADV_EVT_MASK_SET_TERMINATED);

        // Enable legacy advertising for set #1
//        status = GapAdv_enable(advHandleLegacy_ForWhitelistedDev, GAP_ADV_ENABLE_OPTIONS_USE_MAX , 0);

- code snippet for configuring pairable adv

static void SimplePeripheral_ConfigurePairableAdv()
{
  bStatus_t status = FAILURE;

  //Advertisement for New Devices
  BLE_LOG_INT_INT(0, BLE_LOG_MODULE_APP, "APP : ---- call GapAdv_create set=%d,%d\n", 1, 0);
  // Create Advertisement set #2 and assign handle
  status = GapAdv_create(&SimplePeripheral_advCallback, &advParams2,
                         &advHandleLegacy_ForNewDev);
  SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

  // Load advertising data for set #2 that is statically allocated by the app
  status = GapAdv_loadByHandle(advHandleLegacy_ForNewDev, GAP_ADV_DATA_TYPE_ADV,
                               sizeof(advData2), advData2);
  SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

  // Load scan response data for set #1 that is statically allocated by the app
  status = GapAdv_loadByHandle(advHandleLegacy_ForNewDev, GAP_ADV_DATA_TYPE_SCAN_RSP,
                               sizeof(scanResData2), scanResData2);
  SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

  // Set event mask for set #2
  status = GapAdv_setEventMask(advHandleLegacy_ForNewDev,
                               GAP_ADV_EVT_MASK_START_AFTER_ENABLE |
                                   GAP_ADV_EVT_MASK_END_AFTER_DISABLE |
                                   GAP_ADV_EVT_MASK_SET_TERMINATED);
}

- code snippet for enabling pairable adv

static void SimplePeripheral_EnablePairableAdv()
{
   // Disable Bonded Devices Advertisement
  GapAdv_disable(advHandleLegacy_ForBonDev);

  // Enable pairing for new devices
  // Display_printf(dispHandle, 16, 0, "Pair Mode: Pairing Enabled");
  // uart_log
  // SimplePeripheral_serialPrint("Pair Mode: Pairing Enabled");
  GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairModeWaitForRequest);
  // GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairModeInitiatePairing);

  // Enable Advertisement for New Devices
  GapAdv_enable(advHandleLegacy_ForNewDev, GAP_ADV_ENABLE_OPTIONS_USE_MAX, 0);

  // Timer for Advertisement A
  Util_startClock(&timeoutClkForPairableAdv);

  // Timer for change pairing mode to pairing not allowed
  Util_startClock(&timeoutClkForPairingModeChange);
}

Please note that after a timeout, pairing mode is disabled and the device advertises in whitelist adv mode. Further on, already paired and bonded devices are expected to connect to the simple peripheral application.

static void SimplePeripheral_PairingNotAllowed()
{
  // Disable Pairing for new devices
  // Display_printf(dispHandle, 16, 0, "Pair Mode: Pairing Disabled");
  // uart_log
//  SimplePeripheral_serialPrint("Pair Mode: Pairing Disabled");
  GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairModePairingNotAllowed);
}

Hi Jan,

I prepared another example with the same code on top of the simple peripheral example with SDK v7.10.2.23. This results in whitelisting working as expected where already bonded devices are able to connect in whitelist adv mode. See screenshots for details:

connection (pair and bond) in pairable adv:

connection in whitelist adv (already bonded device):

Hi,

Got it. Thank you for running this test on the older SDK. This is very strange that the same behavior is causing issues in a newer SDK. I am guessing some bug fix or additional feature had an impact on how the whitelist advertising feature worked previously. I will look closer at the issues fixed between the SDKs to see if something jumps out at me. To confirm, the only changes to the simple_peripheral example are the four code snippets you shared and the sysconfig options you posted, correct?

Best Regards,

Jan

Hi Jan,

there are no further changes. Could you prepare a prototype with whitelisting functional on your side?

Hi,

Got it. Thank you for confirming. I will work to reproduce this on my side and provide an update by tomorrow.

Best Regards,

Jan

Hi,

My apologies, I was unable to work on this today. I will prioritize this tomorrow and provide an update sometime during the day. I truly apologize for any inconvenience this may be causing on your side.

Best Regards,

Jan

Hi,

My sincerest apologies for the extended delay. I was able to implement the allow-list filtering on my side. I added a few modifiactions to the simple_peripheral project to enable this functionality. First, I removed the long range advertising set and am only using a single one. This means I removed all references to advHandleLongRange. Afterwards, I limited the amount of connections to 1 connection (to cause the device to stop advertising after one connection).

When the connection is established, I add the device to the allow list

After the connection is established, I would read Characteristic 5 to initiate pairing. In the pairing callback, I added code to change the allow list policy. I did it in this location because the advertisements should be off by this point:

Using this project, I was able to connect to the CC26X2R1 device using an Android device, pair, disconnect & reconnect repeatedly, and when attempting to connect with another device it would never allow a connection to form.

I have uploaded the project here: 1512.simple_peripheral_CC26X2R1_LAUNCHXL_tirtos7_ticlang.zip

Can you try it on your side? Again, i apologize for the delay in providing these code snippets.

Best Regards,

Jan

Hi Jan,

Thanks very much for the project you prepared. However, I have a few more questions:

Our use case (demonstrated in the example projects I prepared):

- Two adv sets, 

advSet1: filter policy set to 'Process scan req from all devices and only conn req from devices in AL' [essentially used to connect devices that are paired and bonded before, default adv set]

advSet2: filter policy set to 'Process requests from all devices'. This adv set supports pairing and new device can pair and bond

What happens is:

- When the peripheral is advertising in advSet1, and if an unbonded central device attempts to connect, it should be denied connection. (GATT error)

- When the peripheral is advertising in advSet2, then it can connect and also pair and bond. For all subsequent connections the same central device must be able to establish connection while connecting via advSet1 (as the central device is now whitelisted). This fails in the SDK v7.41 but succeeds in v7.10

[Both these scenarios are handled as part of the gapbondmgr.c] workflow.

Now, comparing the project you have compiled:

1. The sysConfig setting for filter policy is configured as 'Process requests from all devices' which means any device can connect and if needed, bond and pair. 

So here, our use case is not consistent as the filter policy setting is not the same. Therefore, we can not reproduce the same behaviour with one adv set.

2. You are using the HCI custom API to add devices to the whitelist

I would assume the gapbondmgr component should take care of it and from the TI guide it not recommended to handle this in the application. Furthermore, if this is handled in the application, then one must also take care of the LRU bond list handling I believe. Is it intentional that we need to do it explicitly in the new SDK?

Could you please amend the your example application with two adv sets and try to reproduce the scenario I described. The setting for adv sets are described here: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1373648/cc2651r3-previously-bonded-devices-can-not-connect-in-whitelist-mode/5253981#5253981

In my application, I added a timer to disable pairable adv after 30 sec once the application boots up. Within this time, one must pair and bond and then the adv switches to whitelist adv. So expectation would be that the bonded device can connect.

Thanks, Kaiwalya

Hi Kaiwalya,

To clarify, I changed the filter setting to only allow connections from devices in the whitelist after the pairing event has been received. Essentially converting my advertising set from advSet2 to advSet1.

As a quick test, can you try using the HCI commands on your side to see if that works?

Best Regards,

Jan

Hi Jan,

I tried using the HCI API to add the device (which is paired) manually to the whitelist.

However, I am not able to connect in whitelist adv for subsequent connections (tested both on iOS and Android)

Hi,

Understood. Got it. I will attempt to use 2 advertising sets as you described to see if i can reproduce the behavior. In the meantime, can you confirm if you use my solution, then only the previously connected device can connect?

Best Regards,

Jan

Hi Jan, 

I have ported your application to CC2651R3 and here are the results:

- OnePlus Nord (Android 13) nRF Connect App

can connect for first time, pair and bond. Afterwards, connecting via whitelist does not work (GATT error 0x85)

...

- iPhone 12 mini (iOS 17.5.1) Lightblue App

can connect for first time, pair and bond. Afterwards, connecting via whitelist is working as expected.

Hi,

Using two advertising sets, I was able to reproduce the behavior you are seeing ( GATT ERROR on Android). I will file a ticket for this to get addressed by R&D as soon as possible. In the meantime, I think we should explore potential workarounds. It seems using a single advertising set at least works on iOS. I wonder if theres some additional logic that we can add to make it work consistently on the Android side as well. Below is the project I used to reproduce the behavior with two advertising sets:

  6253.simple_peripheral_CC26X2R1_LAUNCHXL_tirtos7_ticlang.zip

You mentioned this worked on 6.20 previously. Did you test any of the SDKs in between? It may be helpful if we can narrow into which SDK was the one that modified this behavior.

Best Regards,

Jan

Hi Jan, thanks for confirming the behavior with two advertisement sets. 

Jan said:

You mentioned this worked on 6.20 previously. Did you test any of the SDKs in between? It may be helpful if we can narrow into which SDK was the one that modified this behavior.

I could first reproduce this using SDK v7.40.00.77 and later also in SDKv7.41.00.17. Whereas, currently we reverted back to SDK v7.10.2.23 where this behavior was not observed.

Hi,

Understood. Thank you for sharing these results. I have updated the ticket and forwarded the information to R&D. They will address it in a future SDK release. I truly apologize for the inconvenience this may have caused. Are there any features or bug fixes present in future SDKs that you are interested in using in the 7.10 sdk?

Best Regards,

Jan