Connection using old pairing information saved

[Gaurav]

I am running an experiment to use a static keys for pairing information without breaking the existing flow of pairing/bonding.
What I am doing is I am storing the pairing info of my central device and storing it into a structure and then erasing the flash to remove those information, and after reset I am retrieving those bonding information and connecting again using the same central devices but I am getting "Peer removed bonding info" response on my phone.

void store_ltk_in_zephyr(void)
{
    int id, err;
    struct bt_keys pairing_info = {
    .addr = {
        .type = BT_ADDR_LE_PUBLIC,
        .a.val = {0x43,0x82,0x5E,0xC7,0xE8,0xF4,0xFD}
    },
    .irk = {0x8A, 0x27, 0x1E, 0xA7, 0x92, 0x2A, 0xF0, 0x15, 0x41, 0x69, 0x48, 0xDD, 0xC0, 0x7E, 0xDD, 0xF7},
    .ltk = {
        .val = {0xc0, 0xe6, 0x9a, 0x0a, 0xf7, 0x4b, 0xdc, 0xb7, 0x7d, 0x23, 0xf4, 0xb4, 0x89, 0x8d, 0x96, 0x02},
        .ediv = {0x00,0x00},
        .rand = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00},
      }
    };

    // Store the keys using the settings API
    err = bt_keys_store(&pairing_info);
    if (err) {
        printk("Failed to store keys (err %d)\n", err);
    } else {
        printk("Keys stored successfully\n");
    }
}

In main, I am calling like this to load the info onto the flash- 

  settings_subsys_init();
  //smp_bt_register();
	bt_conn_auth_cb_register(&auth_cb_display);
  bt_conn_auth_info_cb_register(&conn_auth_info_callbacks);
	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
    k_sleep(K_MSEC(100));
		err = bt_enable(NULL);                                      //Trying one more time after this system reset
    if(err) NVIC_SystemReset();
	}
  store_ltk_in_zephyr();
  if (IS_ENABLED(CONFIG_SETTINGS)) {
    settings_load();
  }

And on connect I am using like this-

  bt_conn_set_security(conn, BT_SECURITY_L1|BT_SECURITY_FORCE_PAIR);

Do let me know, how can I connect with the same bonding info which I have made a copy of from the same bonding structure.

[Vidar Berg]

Hello,

To troubleshoot this, I recommend you start by enabling CONFIG_BT_LOG_SNIFFER_INFO to have the keys printed on boot. This would help confirm us confirm if they keys were successfully stored or not.

Best regards,

Vidar

[Gaurav]

I am reading the pairing info using nrfjprog --memrd 0xfe000 -n 1024, as I know its taking the info from the settings page and the address of the page is this -

Not getting any logs related to bonding on boot using CONFIG_BT_LOG_SNIFFER_INFO.

[Gaurav]

Vidar Berg On android, on every connection I have to do Refresh services to do the data transfer.
Why is that?

[Gaurav]

Vidar Berg said:

Sorry, I meant to ask if it got disabled. As mentioned in my code comment, CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION must be disabled to send the indication without the subscription being enabled.

Vidar Berg With this settings disabled, I am seeing the pairing info getting deleted from the flash that I have stored on the nRF5SDK version.
Pairing info I am storing in oxf5100 memory address and have saved space based on this on Zephyr version too.
Before disabling this settings, pairing info was correctly getting copied to the Zephyr version but not now.

Gaurav said:

On android, on every connection I have to do Refresh services to do the data transfer.
Why is that?

This also stands still, I have tested with 3-4 phones now.

[Vidar Berg]

There is no relation between the CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION setting and how bonds are managed. If you grep the SDK for "CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION," you can see that all it does is skip the "is subscribed" check when sending indications/notifications.

Gaurav said:

On android, on every connection I have to do Refresh services to do the data transfer.
Why is that?

This also stands still, I have tested with 3-4 phones now.

I have never seen anything like this before. The attribute cache should be updated when you perform a new discovery. Are you testing this with the nRF Connect app? And do you see old services appear again when you re-connect?

[Gaurav]

Vidar Berg said:

Are you testing this with the nRF Connect app? And do you see old services appear again when you re-connect?

Yes Vidar Berg seeing the old services appear on reconnect.

Vidar Berg said:

There is no relation between the CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION setting and how bonds are managed.

For this I did some test and the merged DFU zip could be the issue, because if I flash the Zephyr application then it works fine but after doing DFU I am seeing the flash memory is getting erased.

The first read is when the bonded information is stored in nRF5SDK version and the one after reset is the one read when the migration completes and Zephyr application starts to run.

[Vidar Berg]

Gaurav said:

Yes Vidar Berg seeing the old services appear on reconnect.

Can you post a screencast  from the app showing this? 

Gaurav said:

For this I did some test and the merged DFU zip could be the issue, because if I flash the Zephyr application then it works fine but after doing DFU I am seeing the flash memory is getting erased.

Can you show how you reserved the bond data in your zephyr app?