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.

  • Seeing this log with  changes pairing_info->flags=0 and pairing_info->keys =BT_KEYS_IRK | BT_KEYS_LTK_P256

    00> [00:01:01.855,712] <dbg> bt_keys: bt_keys_find_irk: 76:B0:CA:9C:DB:FE (random)
    00> [00:01:01.856,048] <dbg> bt_keys: bt_keys_find_irk: cached RPA 76:B0:CA:9C:DB:FE for F4:E8:C7:5E:82:43 (public)
    00> [00:01:01.856,109] <dbg> bt_smp: bt_smp_accept: conn 0x20003e58 handle 1
    00> [00:01:01.856,140] <dbg> bt_smp: bt_smp_connected: chan 0x200042b0 cid 0x0006
    00> [00:01:01.856,384] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Watchdog is getting fed here : adv 0 and conn 1
    00> Connected
    00> [00:01:01.857,025] <dbg> bt_smp: smp_send_security_req: 
    00> [00:01:01.857,208] <dbg> bt_keys: bt_keys_get_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:01:01.857,391] <dbg> bt_smp: smp_init: prnd 7ca7b088296fa458824ee3c559362555
    00> [00:01:02.029,693] <dbg> bt_smp: bt_smp_encrypt_change: chan 0x200042b0 conn 0x20003e58 handle 1 encrypt 0x00 hci status 0x06
    00> Security failed: F4:E8:C7:5E:82:43 (public) level 1 err 2
    00> [00:01:02.119,689] <dbg> bt_smp: bt_smp_disconnected: chan 0x200042b0 cid 0x0006
    00> MTU exchange failed (err 14)[00:01:02.120,086] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:01:02.120,269] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Disconnected (reason 0x13)

  • I got this log with pairing_info->flags=0 and pairing_info->keys =BT_KEYS_IRK | BT_KEYS_LTK

    00> --- 4[00:00:14.954,559] <dbg> bt_sdc_hci_driver: event_packet_process: LE Meta Event (0x0a), len (31)
    00> [00:00:14.954,589] <dbg> bt_hci_core: bt_recv: buf 0x200344e4 len 33
    00> [00:00:14.954,711] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
    00> [00:00:14.954,711] <dbg> bt_hci_core: rx_work_handler: buf 0x200344e4 type 1 len 33
    00> [00:00:14.954,742] <dbg> bt_hci_core: hci_event: event 0x3e
    00> [00:00:14.954,742] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0a
    00> [00:00:14.955,108] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: status 0x00 handle 0 role 1 peer 63:18:F5:4A:01:4D (random) peer RPA 00:00:00:00:00:00
    00> [00:00:14.955,261] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: local RPA 00:00:00:00:00:00
    00> [00:00:14.955,535] <dbg> bt_keys: bt_keys_find_irk: 63:18:F5:4A:01:4D (random)
    00> [00:00:14.955,566] <dbg> bt_sdc_crypto: bt_encrypt_le: key
    00>                                         f7 dd 7e c0 dd 48 69 41  15 f0 2a 92 a7 1e 27 8a |..~..HiA ..*...'.
    00> [00:00:14.955,596] <dbg> bt_sdc_crypto: bt_encrypt_le: plaintext
    00>                                         f5 18 63 00 00 00 00 00  00 00 00 00 00 00 00 00 |..c..... ........
    00> [00:00:14.955,657] <dbg> bt_sdc_crypto: bt_encrypt_le: enc_data
    00>                                         4d 01 4a 8f 75 36 78 66  55 13 c4 02 20 4e dd f0 |M.J.u6xf U... N..
    00> [00:00:14.956,024] <dbg> bt_keys: bt_keys_find_irk: RPA 00:00:00:00:00:00 matches F4:E8:C7:5E:82:43 (public)
    00> [00:00:14.956,512] <dbg> bt_id: bt_lookup_id_addr: Identity 63:18:F5:4A:01:4D (random) matched RPA 63:18:F5:4A:01:4D (random)
    00> [00:00:14.956,542] <dbg> bt_adv: bt_le_adv_resume: Host cannot resume connectable advertising (-12)
    00> [00:00:14.956,573] <dbg> bt_smp: bt_smp_accept: conn 0x20003e58 handle 0
    00> [00:00:14.956,604] <dbg> bt_smp: bt_smp_connected: chan 0x200042b0 cid 0x0006
    00> [00:00:14.956,878] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Watchdog is getting fed here : adv 0 and conn 1
    00> Connected
    00> [00:00:14.957,519] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x2016 param_len 2
    00> [00:00:14.957,519] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20034930
    00> [00:00:14.957,550] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x20034930 opcode 0x2016 len 5
    00> [00:00:14.957,580] <dbg> bt_hci_core: process_events: count 2
    00> [00:00:14.957,611] <dbg> bt_hci_core: process_events: ev->state 4
    00> [00:00:14.957,611] <dbg> bt_hci_core: send_cmd: calling net_buf_get
    00> [00:00:14.957,641] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
    00> [00:00:14.957,641] <dbg> bt_hci_core: send_cmd: Sending command 0x2016 (buf 0x20034930) to driver
    00> [00:00:14.957,672] <dbg> bt_hci_core: bt_send: buf 0x20034930 len 5 type 0
    00> [00:00:14.957,672] <dbg> bt_sdc_hci_driver: hci_driver_send: 
    00> [00:00:14.957,702] <dbg> bt_sdc_hci_driver: cmd_handle: 
    00> [00:00:14.957,733] <dbg> bt_sdc_hci_driver: hci_driver_send: Exit: 0
    00> [00:00:14.957,763] <dbg> bt_hci_core: process_events: ev->state 1
    00> [00:00:14.957,794] <dbg> bt_sdc_hci_driver: event_packet_process: Command Status (0x2016) status: 0x00
    00> [00:00:14.957,824] <dbg> bt_hci_core: bt_recv: buf 0x20034930 len 6
    00> [00:00:14.957,824] <dbg> bt_hci_core: hci_cmd_status: opcode 0x2016
    00> [00:00:14.957,855] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2016 status 0x00 buf 0x20034930
    00> [00:00:14.957,946] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
    00> [00:00:14.957,977] <dbg> bt_hci_core: process_events: count 3
    00> [00:00:14.957,977] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:14.958,007] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:14.958,007] <dbg> bt_hci_core: process_events: ev->state 4
    00> [00:00:14.958,038] <dbg> bt_hci_core: bt_send: buf 0x2003643c len 11 type 2
    00> [00:00:14.958,038] <dbg> bt_sdc_hci_driver: hci_driver_send: 
    00> [00:00:14.958,068] <dbg> bt_sdc_hci_driver: acl_handle: 
    00> [00:00:14.958,099] <dbg> bt_sdc_hci_driver: hci_driver_send: Exit: 0
    00> [00:00:14.958,129] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
    00> [00:00:14.958,190] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x20034930 opcode 0x2016 len 0
    00> [00:00:14.958,190] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x2032 param_len 7
    00> [00:00:14.958,221] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20034930
    00> [00:00:14.958,251] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x20034930 opcode 0x2032 len 10
    00> [00:00:14.958,282] <dbg> bt_hci_core: process_events: count 3
    00> [00:00:14.958,312] <dbg> bt_hci_core: process_events: ev->state 4
    00> [00:00:14.958,312] <dbg> bt_hci_core: send_cmd: calling net_buf_get
    00> [00:00:14.958,343] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
    00> [00:00:14.958,343] <dbg> bt_hci_core: send_cmd: Sending command 0x2032 (buf 0x20034930) to driver
    00> [00:00:14.958,374] <dbg> bt_hci_core: bt_send: buf 0x20034930 len 10 type 0
    00> [00:00:14.958,374] <dbg> bt_sdc_hci_driver: hci_driver_send: 
    00> [00:00:14.958,404] <dbg> bt_sdc_hci_driver: cmd_handle: 
    00> [00:00:14.958,435] <dbg> bt_sdc_hci_driver: hci_driver_send: Exit: 0
    00> [00:00:14.958,465] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:14.958,465] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:14.958,496] <dbg> bt_sdc_hci_driver: event_packet_process: Command Status (0x2032) status: 0x00
    00> [00:00:14.958,526] <dbg> bt_hci_core: bt_recv: buf 0x20034930 len 6
    00> [00:00:14.958,557] <dbg> bt_hci_core: hci_cmd_status: opcode 0x2032
    00> [00:00:14.958,557] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2032 status 0x00 buf 0x20034930
    00> [00:00:14.958,679] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
    00> [00:00:14.958,709] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x20034930 opcode 0x2032 len 0
    00> [00:00:15.046,112] <dbg> bt_sdc_hci_driver: event_packet_process: Event (0x13) len 5
    00> [00:00:15.046,142] <dbg> bt_hci_core: bt_recv: buf 0x20034714 len 7
    00> [00:00:15.046,142] <dbg> bt_hci_core: hci_num_completed_packets: num_handles 1
    00> [00:00:15.046,173] <dbg> bt_hci_core: hci_num_completed_packets: handle 0 count 1
    00> [00:00:15.106,353] <dbg> bt_sdc_hci_driver: event_packet_process: LE Meta Event (0x05), len (13)
    00> [00:00:15.106,353] <dbg> bt_hci_core: bt_recv: buf 0x200344e4 len 15
    00> [00:00:15.106,475] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
    00> [00:00:15.106,475] <dbg> bt_hci_core: rx_work_handler: buf 0x200344e4 type 1 len 15
    00> [00:00:15.106,506] <dbg> bt_hci_core: hci_event: event 0x3e
    00> [00:00:15.106,506] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x05
    00> [00:00:15.106,536] <dbg> bt_hci_core: le_ltk_request: handle 0
    00> [00:00:15.106,750] <dbg> bt_keys: bt_keys_find: type 32 F4:E8:C7:5E:82:43 (public)
    00> [00:00:15.106,933] <dbg> bt_keys: bt_keys_find: type 1 F4:E8:C7:5E:82:43 (public)
    00> [00:00:15.106,964] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x201b param_len 2
    00> [00:00:15.106,964] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20034930
    00> [00:00:15.106,994] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x201b len 5
    00> [00:00:15.107,055] <dbg> bt_hci_core: process_events: count 3
    00> [00:00:15.107,055] <dbg> bt_hci_core: process_events: ev->state 4
    00> [00:00:15.107,086] <dbg> bt_hci_core: send_cmd: calling net_buf_get
    00> [00:00:15.107,086] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
    00> [00:00:15.107,116] <dbg> bt_hci_core: send_cmd: Sending command 0x201b (buf 0x20034930) to driver
    00> [00:00:15.107,116] <dbg> bt_hci_core: bt_send: buf 0x20034930 len 5 type 0
    00> [00:00:15.107,147] <dbg> bt_sdc_hci_driver: hci_driver_send: 
    00> [00:00:15.107,147] <dbg> bt_sdc_hci_driver: cmd_handle: 
    00> [00:00:15.107,299] <dbg> bt_sdc_hci_driver: hci_driver_send: Exit: 0
    00> [00:00:15.107,330] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:15.107,330] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:15.107,391] <dbg> bt_sdc_hci_driver: event_packet_process: Command Complete (0x201b) status: 0x00, ncmd: 1, len 6
    00> [00:00:15.107,391] <dbg> bt_hci_core: bt_recv: buf 0x20034930 len 8
    00> [00:00:15.107,421] <dbg> bt_hci_core: hci_cmd_complete: opcode 0x201b
    00> [00:00:15.107,421] <dbg> bt_hci_core: hci_cmd_done: opcode 0x201b status 0x00 buf 0x20034930
    00> [00:00:15.107,543] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
    00> [00:00:15.196,228] <dbg> bt_sdc_hci_driver: event_packet_process: Event (0x05) len 4
    00> [00:00:15.196,258] <dbg> bt_hci_core: bt_recv: buf 0x200344e4 len 6
    00> [00:00:15.196,289] <dbg> bt_hci_core: hci_disconn_complete_prio: status 0x00 handle 0 reason 0x13
    00> [00:00:15.196,411] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
    00> [00:00:15.196,411] <dbg> bt_hci_core: rx_work_handler: buf 0x200344e4 type 1 len 6
    00> [00:00:15.196,441] <dbg> bt_hci_core: hci_event: event 0x05
    00> [00:00:15.196,441] <dbg> bt_hci_core: hci_disconn_complete: status 0x00 handle 0 reason 0x13
    00> [00:00:15.196,502] <dbg> bt_hci_core: process_events: count 3
    00> [00:00:15.196,533] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:15.196,533] <dbg> bt_hci_core: process_events: ev->state 1
    00> [00:00:15.196,563] <dbg> bt_hci_core: process_events: ev->state 0
    00> [00:00:15.196,594] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 2 events
    00> [00:00:15.196,655] <dbg> bt_smp: bt_smp_disconnected: chan 0x200042b0 cid 0x0006
    00> MTU exchange failed (err 14)[00:00:15.197,052] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:00:15.197,235] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Disconnected (reason 0x13)

  • LTK is coming out as correct but somehow the security is failing with error 2 (BT_SECURITY_ERR_PIN_OR_KEY_MISSING)


    Attaching logs-

    00> [00:00:06.161,285] <dbg> bt_smp: bt_smp_accept: conn 0x20003890 handle 0
    00> [00:00:06.161,315] <dbg> bt_smp: bt_smp_connected: chan 0x20003ce8 cid 0x0006
    00> [00:00:06.161,590] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Watchdog is getting fed here : adv 0 and conn 1
    00> [00:00:06.162,292] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> LTK (reversed for display): 
    00> 69 52 43 a8 bb 67 71 28 be a5 78 b2 dd 2a 87 85 [00:00:06.162,658] <inf> bt_keys: Legacy LTK: 0x695243a8bb677128bea578b2dd2a8785 (central)
    00> Connected
    00> [00:00:06.162,719] <dbg> bt_smp: smp_send_security_req: 
    00> [00:00:06.162,902] <dbg> bt_keys: bt_keys_get_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:00:06.163,085] <dbg> bt_smp: smp_init: prnd 525ebd9b8275ecb9bb25ef4e1dd06728
    00> [00:00:06.335,876] <dbg> bt_smp: bt_smp_encrypt_change: chan 0x20003ce8 conn 0x20003890 handle 0 encrypt 0x00 hci status 0x06
    00> Security failed: F4:E8:C7:5E:82:43 (public) level 1 err 2
    00> [00:00:06.425,872] <dbg> bt_smp: bt_smp_disconnected: chan 0x20003ce8 cid 0x0006
    00> [00:00:06.426,239] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:00:06.426,422] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Disconnected (reason 0x13)


    For testing- I have kept the address and IRK same as the previous one as this will be static for the phone I am using and to check the endianess. Either the RAND and EDIV are not able to resolve the LTK and thus failing in encryption or LTK itself is wrong.

  • I think my key exchange is failing in le_ltk_request and inside this bt_smp_request_ltk is called which looks for ediv and rand values and the flags like BT_KEYS_LTK_P256 or BT_KEYS_PERIPH_LTK, which in our case is only BT_KEYS_LTK and hence callback of bt_conn_security_changed which disconnects with security reason being 2 BT_SECURITY_ERR_PIN_OR_KEY_MISSING.

  • Have you tried using BT_KEYS_PERIPH_LTK instead? We lack documentation for these flags as they are intended for internal use within the stack.

Reply Children
  • Yeah I tried that but then the retrieved LTK becomes 0 like this-

    00> [00:00:06.927,886] <dbg> bt_smp: bt_smp_accept: conn 0x20003890 handle 0
    00> [00:00:06.927,917] <dbg> bt_smp: bt_smp_connected: chan 0x20003ce8 cid 0x0006
    00> [00:00:06.928,161] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Watchdog is getting fed here : adv 0 and conn 1
    00> [00:00:06.928,863] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> LTK (reversed for display): 
    00> 6c 53 4d d6 09 e2 6f 7e e2 9d 86 4c d4 f5 7f 63 LTK (reversed for display): 
    00> 64 a4 LTK (reversed for display): 
    00> 52 3b 87 4f 80 65 1d 0e LTK (reversed for display): 
    00> 8a 27 1e a7 92 2a f0 15 41 69 48 dd c0 7e dd f7 [00:00:06.929,748] <inf> bt_keys: Legacy LTK: 0x00000000000000000000000000000000 (peripheral)
    00> Connected
    00> [00:00:07.103,607] <dbg> bt_keys: bt_keys_find: type 32 F4:E8:C7:5E:82:43 (public)
    00> [00:00:07.103,790] <dbg> bt_keys: bt_keys_find: type 1 F4:E8:C7:5E:82:43 (public)
    00> LTK retrieved
    00>  63 7f f5 d4 4c 86 9d e2 7e 6f e2 09 d6 4d 53 6c[00:00:07.193,450] <dbg> bt_smp: bt_smp_disconnected: chan 0x20003ce8 cid 0x0006
    00> [00:00:07.193,786] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:00:07.193,969] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Disconnected (reason 0x13)
     

  • Made wrong assumption in getting the LTK in log, after using BT_KEYS_PERIPH_LTK, I should be looking for peripheral_ltk structure.
    Made the changes for saving the values in this structure and still facing this issue, attaching the logs.

    00> [00:00:07.677,642] <dbg> bt_smp: bt_smp_accept: conn 0x20003890 handle 0
    00> [00:00:07.677,673] <dbg> bt_smp: bt_smp_connected: chan 0x20003ce8 cid 0x0006
    00> [00:00:07.677,917] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Watchdog is getting fed here : adv 0 and conn 1
    00> [00:00:07.678,619] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> LTK (reversed for display): 
    00> 27 e0 61 11 26 93 bb 5c da b0 e1 2e 44 13 ba eb LTK (reversed for display): 
    00> 8d cd LTK (reversed for display): 
    00> 69 5e 3b bf e1 40 a6 15 LTK (reversed for display): 
    00> 8a 27 1e a7 92 2a f0 15 41 69 48 dd c0 7e dd f7 [00:00:07.679,504] <inf> bt_keys: Legacy LTK: 0x27e061112693bb5cdab0e12e4413baeb (peripheral)
    00> Connected
    00> [00:00:07.846,557] <dbg> bt_keys: bt_keys_find: type 32 F4:E8:C7:5E:82:43 (public)
    00> [00:00:07.846,740] <dbg> bt_keys: bt_keys_find: type 1 F4:E8:C7:5E:82:43 (public)
    00> LTK retrieved
    00>  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[00:00:07.936,401] <dbg> bt_smp: bt_smp_disconnected: chan 0x20003ce8 cid 0x0006
    00> [00:00:07.936,737] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> [00:00:07.936,920] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
    00> Disconnected (reason 0x13)

  • While saving the key information with respect to this flag, should I store LTK in pairing_info->ltk and EDIV,RAND in pairing_info->peripheral_ltk structure?

    Not understanding the flow for legacy pairing.

  • Its failing here in comparing EDIV and RAND values with the key`s one so that the LTK can be copied and connection can be passed on-



Related