esp32 nimble server, if I unpair Android client side I'm never be able to r/w ENC GATTs

[manfre90]

Hi everyone,
I'm new and I'm struggling with the problem.
I'm using esp idf 4.4 and Nimble 1.3.0
First time I'm able to pair an android device inserting a passkey client side. Once the device is paired and bounded I'm able to read and write encrypted gatts like for forever.
The bond survive across reboots and capping max boundable device size.
If I unpair the esp32 on the client side, like unpairing in throught blueetooth Android option I'm no more able to r/w encrypted gapps.

To see charateristics and r/w over gatts svr i use "BLE tester" apk

This is ble_hs_cfg.

Code: Select all

 
ble_hs_cfg.sm_io_cap = 4;
ble_hs_cfg.sm_bonding = 1;
ble_hs_cfg.sm_our_key_dist = BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID;
ble_hs_cfg.sm_their_key_dist =  BLE_SM_PAIR_KEY_DIST_ENC| BLE_SM_PAIR_KEY_DIST_ID;
ble_hs_cfg.sm_mitm = 1;
ble_hs_cfg.sm_sc = 1; 

This is my sync call back:

Code: Select all

void sync_cb(void) {
// determine best adress type
ble_hs_id_infer_auto(0, &addr_type);      
uint8_t addr_val[6];
ble_hs_id_copy_addr(addr_type, addr_val, NULL);
printf("\033[0;36m");
printf("Indirizzo host:\n");
for (int j = 0; j < 6; j++) {
         printf("\033[0;36m");
         printf("%d ",addr_val[j]);
        } 
printf("\n");


ESP_LOGI("BLE_Sync", "Device address type %i", addr_type);
    

  advertise();    // start avertising
}

passkey injection is performed by this case of my gap event handler callback (inserted as cb in the main advertise function):

Code: Select all

#if SECU
    case BLE_GAP_EVENT_PASSKEY_ACTION:
      ESP_LOGI(tag, "PASSKEY_ACTION_EVENT started \n");
      struct ble_sm_io pkey = {0};                              
      int key = 0;                                             

      if (event->passkey.params.action == BLE_SM_IOACT_DISP {
        ESP_LOGI(tag, "BLE_SM_IOACT_DISP");
        pkey.action = event->passkey.params.action;
        pkey.passkey = 123456; // This is the passkey to be entered on peer
        ESP_LOGI(tag, "Enter passkey %d on the peer side", pkey.passkey);
        rc = ble_sm_inject_io(event->passkey.conn_handle, &pkey);
        ESP_LOGI(tag, "ble_sm_inject_io result: %d\n", rc);
      } 

The thing I was able to catch is, if I unpair client side like previous mentioned the next pair connection (which is suppose to be new client side) don't ask for passkey like the server already recognize the peer but debugging let me se the code is stuck over here in ble_sm.c

This code is from ble_sm.c standard lib

Code: Select all

static int
ble_sm_chk_repeat_pairing(uint16_t conn_handle,
                          ble_sm_proc_flags proc_flags,
                          uint8_t key_size)
{
    struct ble_gap_repeat_pairing rp;
    struct ble_store_value_sec bond;
    int rc;

    do {
        /* If the peer isn't bonded, indicate that the pairing procedure should
         * continue.
         */
        rc = ble_sm_read_bond(conn_handle, &bond);
        switch (rc) {
        case 0:
            break;
        case BLE_HS_ENOENT:
            return 0;
        default:
            return rc;
        }

        /* Peer is already bonded.  Ask the application what to do about it. */
        rp.conn_handle = conn_handle;
        rp.cur_key_size = bond.key_size;
        rp.cur_authenticated = bond.authenticated;
        rp.cur_sc = bond.sc;

        rp.new_key_size = key_size;
        rp.new_authenticated = !!(proc_flags & BLE_SM_PROC_F_AUTHENTICATED);
        rp.new_sc = !!(proc_flags & BLE_SM_PROC_F_SC);
        rp.new_bonding = !!(proc_flags & BLE_SM_PROC_F_BONDING);

        rc = ble_gap_repeat_pairing_event(&rp);
    } while (rc == BLE_GAP_REPEAT_PAIRING_RETRY);

    BLE_HS_LOG(DEBUG, "silently ignoring pair request from bonded peer");       //THE ATTEMPT, IS STUCK HERE I'M ABLE TO SEE THE PRINT BUT I CAN'T READ OR WRITE ENCRYPTED GATTS.

    return BLE_HS_EALREADY;
}

This happends only if I deattach the peer client side.

PS: keys seems stored in nvs pretty well like our_sec, pee_sec and p_dev_sec. Also cccds_sec subscription works well.


Thanks in advance for your help.