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.

[Vidar Berg]

NRF_DFU_APP_DATA_AREA_SIZE will prevent the area from being overwritten by the update images during DFU. So, if you still see that the data is being overwritten, I suggest you try to inspect the memory to find out what it is being overwitten with.

[Gaurav]

Vidar Berg This is sorted, FDS pages was the issue.

If I have bonded with 2-3 devices, which bonded info will be copied to the memory ideally?

[Vidar Berg]

If you have to select one, I would probably suggest keeping the bond from the device that initiated the DFU process.

[Gaurav]

Sure I am right now saving only the last connected phone`s data.

Just one more clarification, I am using static memory mapping and I have split my memory area 0xf4000-0xf7000 into two parts (one from 0xf4000-0xf5000,0xf6000-0xf7000) now, will the updates with consolidated memory (0xf4000-0xf7000) cause issues in DFUs.

[Vidar Berg]

The nRF5 bootloader does not perform any read/write access towards the reserved data in the Application data region, so the content of these flash pages will not affect DFU in any way. I guess what you will need to verify is that your new app correctly handles the existing data. 

[Gaurav]

I have done these changes on my Zephyr application, so DFUing another versions without changes will not affect?

[Gaurav]

Vidar Berg said:

I guess what you will need to verify is that your new app correctly handles the existing data. 

This is my partition after making changes for storing pairing info

pairing_info:
  address: 0xf5000
  end_address: 0xf6000
  placement:
    align:
      start: 0x1000
    before:
    - nvs_storage
  region: flash_primary
  size: 0x1000  
nvs_storage:
  address: 0xf6000
  end_address: 0xf7000
  placement:
    align:
      start: 0x1000
    before:
    - unused_page

And this is before making changes-

nvs_storage:
  address: 0xf5000
  end_address: 0xf7000
  placement:
    align:
      start: 0x1000
    before:
    - unused_page
  region: flash_primary
  size: 0x2000

[Vidar Berg]

I don't really know the details of your implementation or why you made these changes. But in general, it is important that they memory layout does not change when upgrading from one nRF Connect SDK application to another. This is why you get a build warning when performing a multi-image build without a static partition file. 

[Gaurav]

Vidar Berg said:

I don't really know the details of your implementation or why you made these changes

I made these changes because on intialization the memory space of 0xf5000 which was being used for storing pairing info copied from nRF5SDK version was getting wiped out because the nvs_storage was containing these regions and flash storage or nvs init would wipe out these memory thats why I split these memory block so that the memory space remains untouched by nvs_storage too.

[Gaurav]

Vidar Berg said:

But in general, it is important that they memory layout does not change when upgrading from one nRF Connect SDK application to another.

Thats why I was taking this confirmation. I have been running tests around this hypothesis since morning, done DFU of 2-3 versions on top of the migration one and didnt faced any issues.