Connection using old pairing information saved

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.

Parents
  • 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

  • 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.

  • 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.

     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.

    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.

  • 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?

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

    Yes  seeing the old services appear on reconnect.

    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.

  • Yes  seeing the old services appear on reconnect.

    Can you post a screencast  from the app showing this? 

    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?

  • My Flash partitions are like this-

    &flash0 {
    
    	partitions {
            compatible = "fixed-partitions";
            #address-cells = <1>;
            #size-cells = <1>;
            boot_partition: partition@f8000 {
                label = "mcuboot";
                reg = <0x000f8000 0x006000>;
            };
            slot0_partition: partition@1200 {
                label = "image-0";
                reg = <0x00001200 0x0007ae00>;
            };
            slot1_partition: partition@7c000 {
                label = "image-1";
                reg = <0x0007c000 0x00078000>;
            };
            scratch_partition: partition@f7000 {
                label = "image-scratch";
                reg = <0x000f7000 0x00001000>;
            };
            /*
             * The flash starting at 0x000f8000 and ending at
             * 0x000fffff is reserved for use by the application.
             */
            /*
             * Storage partition will be used by FCB/LittleFS/NVS
             * if enabled.
             */
            storage_partition: partition@f4000 {
                label = "storage";
                reg = <0x000f4000 0x00003000>;
            };
        };
    };

    app:
      address: 0x1200
      end_address: 0x7B000
      region: flash_primary
      size: 0x7AE00
    mcuboot:
      address: 0xF8000
      end_address: 0xFE000
      placement:
        after:
        - mcuboot_secondary
      region: flash_primary
      size: 0x6000
    mcuboot_pad:
      address: 0x1000
      end_address: 0x1200
      placement:
        before:
        - mcuboot_primary_app
      region: flash_primary
      size: 0x200
    mcuboot_primary:
      address: 0x1000
      end_address: 0x7C000
      orig_span: &id001
      - app
      - mcuboot_pad
      region: flash_primary
      sharers: 0x1
      size: 0x7B000
      span: *id001
    mcuboot_primary_app:
      address: 0x1200
      end_address: 0x7C000
      orig_span: &id002
      - app
      region: flash_primary
      size: 0x7AE00
      span: *id002
    mcuboot_secondary:
      address: 0x7C000
      end_address: 0xF8000
      placement:
        after:
        - mcuboot_primary
        align:
          start: 0x1000
      region: flash_primary
      share_size:
      - mcuboot_primary
      size: 0x7B000
    device_info:
      address: 0xf4000
      end_address: 0xf5000
      placement:
        align:
          start: 0x1000
        before:
        - pairing_info
      region: flash_primary
      size: 0x1000
    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
      region: flash_primary
      size: 0x1000
    unused_page:
      address: 0xf7000
      placement:
        after:
        - mcuboot_secondary
      size: 0x1000
    nrf5_mbr:
      address: 0x0
      end_address: 0x1000
      placement:
        after:
        - start
      region: flash_primary
      size: 0x1000
    settings_storage:
      address: 0xfe000
      end_address: 0x100000
      placement:
        align:
          start: 0x1000
        before:
        - end
      region: flash_primary
      size: 0x2000
    sram_primary:
      address: 0x20000000
      end_address: 0x20040000
      region: sram_primary
      size: 0x40000

Reply
  • My Flash partitions are like this-

    &flash0 {
    
    	partitions {
            compatible = "fixed-partitions";
            #address-cells = <1>;
            #size-cells = <1>;
            boot_partition: partition@f8000 {
                label = "mcuboot";
                reg = <0x000f8000 0x006000>;
            };
            slot0_partition: partition@1200 {
                label = "image-0";
                reg = <0x00001200 0x0007ae00>;
            };
            slot1_partition: partition@7c000 {
                label = "image-1";
                reg = <0x0007c000 0x00078000>;
            };
            scratch_partition: partition@f7000 {
                label = "image-scratch";
                reg = <0x000f7000 0x00001000>;
            };
            /*
             * The flash starting at 0x000f8000 and ending at
             * 0x000fffff is reserved for use by the application.
             */
            /*
             * Storage partition will be used by FCB/LittleFS/NVS
             * if enabled.
             */
            storage_partition: partition@f4000 {
                label = "storage";
                reg = <0x000f4000 0x00003000>;
            };
        };
    };

    app:
      address: 0x1200
      end_address: 0x7B000
      region: flash_primary
      size: 0x7AE00
    mcuboot:
      address: 0xF8000
      end_address: 0xFE000
      placement:
        after:
        - mcuboot_secondary
      region: flash_primary
      size: 0x6000
    mcuboot_pad:
      address: 0x1000
      end_address: 0x1200
      placement:
        before:
        - mcuboot_primary_app
      region: flash_primary
      size: 0x200
    mcuboot_primary:
      address: 0x1000
      end_address: 0x7C000
      orig_span: &id001
      - app
      - mcuboot_pad
      region: flash_primary
      sharers: 0x1
      size: 0x7B000
      span: *id001
    mcuboot_primary_app:
      address: 0x1200
      end_address: 0x7C000
      orig_span: &id002
      - app
      region: flash_primary
      size: 0x7AE00
      span: *id002
    mcuboot_secondary:
      address: 0x7C000
      end_address: 0xF8000
      placement:
        after:
        - mcuboot_primary
        align:
          start: 0x1000
      region: flash_primary
      share_size:
      - mcuboot_primary
      size: 0x7B000
    device_info:
      address: 0xf4000
      end_address: 0xf5000
      placement:
        align:
          start: 0x1000
        before:
        - pairing_info
      region: flash_primary
      size: 0x1000
    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
      region: flash_primary
      size: 0x1000
    unused_page:
      address: 0xf7000
      placement:
        after:
        - mcuboot_secondary
      size: 0x1000
    nrf5_mbr:
      address: 0x0
      end_address: 0x1000
      placement:
        after:
        - start
      region: flash_primary
      size: 0x1000
    settings_storage:
      address: 0xfe000
      end_address: 0x100000
      placement:
        align:
          start: 0x1000
        before:
        - end
      region: flash_primary
      size: 0x2000
    sram_primary:
      address: 0x20000000
      end_address: 0x20040000
      region: sram_primary
      size: 0x40000

Children
Related