Qualifying Test Case "Client Characteristic Configuration" for BAS with SIG

[Ron]

Hi,

I am using NRF51822  SDK12; S130 and trying to qualify Batter level service with the SIG's PTS device (dongle)

So far encountered a problem with  Test Case: BAS/SR/DES/BV-02-C, the Verdict is INCONCE, other test cases were OK.

I have monitored the test with nRF sniffer + Wireshark, as you can see there is no response to the read request from the SIG PTS -

I have attempted to recreate the test myself using nRFConnect and seen the Same issue, 

No response and eventually the nRF Connect Application disconnects after pressing the "Client Characteristic Configuration" 

However if I enable the notification before that it works out OK,

Obviously the PTS does not enable the notification earlier to reading the CCCD and it fails, but that is how the qualification works

I have attempted to do the same thing with a nordic example, only change I introduced was taking off the security key, It has the exact same behavior, 

I am wondering if someone has encountered this problem and can help?

How am I suppose to qualify the battery level service?

Thanks!

---------------------------

P:S This is the log from the PTS 

- Discover All Characteristics of Service Request completed successfully.
- Discover All Characteristic Descriptors Request completed successfully.
- The IUT successfully returned the Characteristic Properties for Battery Level
- Read Request completed successfully.
- GATTValue::AssignData, Cannot be parsed from the specified buffer. Field Name = Properties.
- GATTValue::CreateFields, Failed to assign data to the Field named 'Properties'.
- The data received for 'Client Characteristic Configuration' did not conform to the schema. An invalid number of bytes were received.
- Connection terminated successfully.
-Final Verdict: INCONC
BAS/SR/DES/BV-02-C finished

This is how I created the test plan 

[Ron]

Note - Once we enabled Battery level (0x2A19) notification once, we can disable it and still be able to read the CCCD status (0x2902)

[bjorn-spockeli]

Hi Eran, 

I did a quick test with the ble_app_gls example from SDK v12.2.0 where I disabled bonding by modifying the ble_gap_sec_params_t sec_param passed to pm_sec_params_set() in peer_manager_init(). 

#define SEC_PARAM_BOND                  0//1                                           /**< Perform bonding. */
#define SEC_PARAM_MITM                  0//1                                           /**< Man In The Middle protection required (applicable when display module is detected). */
#define SEC_PARAM_LESC                  0                                           /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS              0                                           /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_DISPLAY_ONLY                /**< Display I/O capabilities. */
#define SEC_PARAM_OOB                   0                                           /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE          7                                           /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE          16                                          /**< Maximum encryption key size. */

static void peer_manager_init(bool erase_bonds)
{
    ble_gap_sec_params_t sec_param;
    ret_code_t           err_code;

    err_code = pm_init();
    APP_ERROR_CHECK(err_code);

    if (erase_bonds)
    {
        err_code = pm_peers_delete();
        APP_ERROR_CHECK(err_code);
    }

    memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

    // Security parameters to be used for all security procedures.
    sec_param.bond           = SEC_PARAM_BOND;
    sec_param.mitm           = SEC_PARAM_MITM;
    sec_param.lesc           = SEC_PARAM_LESC;
    sec_param.keypress       = SEC_PARAM_KEYPRESS;
    sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;
    sec_param.oob            = SEC_PARAM_OOB;
    sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
    sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
    sec_param.kdist_own.enc  = 0; // 1
    sec_param.kdist_own.id   = 0; // 1
    sec_param.kdist_peer.enc = 0; // 1
    sec_param.kdist_peer.id  = 0; // 1

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}

I am not seeing any issues with the read request from the nRF Connect app on Android being ignored if I read the CCCD status without enabling Notifications first. Could you upload the Wireshark trace so that I can take a closer  look at the metadata?

Best regards

Bjørn

[Ron]

Hey Bjorn

Thank you for your help,

I am adding the Wireshark log for the failed CCCD read attempt-nRFconnect_GLSunsecured_ReadUUID0x2902_Fail_00.pcapng

According to my understanding the request is sent in message 1004 and it used handle 0x015 for the CCCD. (handle was determined to be 0x015 message 849 - response to Find Information Request.) there is no response shown on the Wireshark's log and the nRF Connect eventually disconnected.

Fail

nRFconnect_GLSunsecured_ReadUUID0x2902_Fail_00.pcapng

I am also adding the Wireshark's log for a successful read after notifications are enabled -

See message 1198, 1201

nRFconnect_GLSunsecured_ReadUUID0x2902_EnableNotificationPass.pcapng

Pass

nRFconnect_GLSunsecured_ReadUUID0x2902_EnableNotificationPass.pcapng

....................................

I used a GLS example in which I simply commented out the peer_maanger_init(), 

int main(void)
{
    uint32_t err_code;
    bool     erase_bonds;

    // Initialize.
    err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);

    timers_init();
    buttons_leds_init(&erase_bonds);
    ble_stack_init();
//    peer_manager_init(erase_bonds);
//    if (erase_bonds == true)
//    {
//        NRF_LOG_INFO("Bonds erased!\r\n");
//    }

I also tried to do what you suggested (disabling the bonding) but the nRFconnect still required PIN for pairing, I actually don't understand how do you do it without entering a PIN, or did you read somehow the random PIN generated and used it?

-----------------

Thanks again!

[bjorn-spockeli]

Hi Eran, 

Apologies, I forgot to mention that I also commented out the code that starts the Security Request timer upon receiving the BLE_GAP_EVT_CONNECTED event in on_ble_evt() in main.c

case BLE_GAP_EVT_CONNECTED:
{
    m_peer_to_be_deleted = PM_PEER_ID_INVALID;
    NRF_LOG_INFO("Connected\r\n");
    err_code           = bsp_indication_set(BSP_INDICATE_CONNECTED);
    APP_ERROR_CHECK(err_code);
    m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
    // Start Security Request timer.
    //err_code = app_timer_start(m_sec_req_timer_id, SECURITY_REQUEST_DELAY, NULL);
    //APP_ERROR_CHECK(err_code);
} break; // BLE_GAP_EVT_CONNECTED

Not starting the Security Request timer will stop the nRF from requesting a pin for pairing as the pairing request will never be sent. With the changes to the sec params and commenting out the Security Request timer code in on_ble_evt() you can safely add the peer_manager_init code back in again. 

Best regards

Bjørn

[Ron]

Hey Bjørn 

Ok, I Have now implemented it as you directed, and it works! But why?

Why is initializing the peer manager necessary for reading the CCCD (If I do not enable notification earlier?)

I will mention that In my existing project I do not use the peer manager since I have not introduced security yet, so I understand that now I have to, I would very much like to understand this.

Thanks again for all of your help.