After bonding, I receive write events from the central, but after reconnecting, the write events no longer come through.

[keigo.imaizumi]

Nice to meet you.

I'm looking to embark on BLE development using nrf52840.
The requirements include one-to-one communication with one central and one peripheral, and pairing using LE Secure Connection is necessary (just works).
I will be developing the peripheral side of this. The BLE requirements are based on the specifications of the central side.

Now, initially, I tried implementing it myself based on various online information and samples.
I have successfully paired, and I can receive write events from the central side.
However, when I turn off the power on the central side, then turn it back on and perform a reconnection, I no longer receive write events from the central side.

Specifically, I am manipulating the central device to perform a write operation on the peripheral.
However, I only receive BLE_GAP_EVT_CONN_PARAM_UPDATE, and no other events.

First, let me share the logs!
If there's anything suspicious, please let me know. I can also provide the code.
Thank you.

SEGGER J-Link V7.88j - Real time terminal output
SEGGER J-Link (unknown) V1.0, SN=1050228242
Process: JLinkGDBServerCLExe
<info> app_timer: RTC: initialized.
<info> app: ble_stack__init
<info> app: Service UUID:0000, UUID Type: 2
<info> app: Erase bonds.
<info> peer_manager_handler: All peers deleted.
<info> app: PM_EVT_PEERS_DELETE_SUCCEEDED
<info> app_timer: RTC: initialized.
<info> app: ble_stack__init
<info> app: Service UUID:0000, UUID Type: 2
<info> app: Erase bonds.
<info> peer_manager_handler: All peers deleted.
<info> app: PM_EVT_PEERS_DELETE_SUCCEEDED
<info> app: PM_EVT_CONN_CONFIG_REQ
<info> app: BLE_GAP_EVT_CONNECTED
<info> app: PM_EVT_CONN_SEC_START
<info> app: PM_EVT_CONN_SEC_PARAMS_REQ
<info> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
<info> app: BLE_GAP_EVT_LESC_DHKEY_REQUEST
<info> nrf_ble_lesc: Calling sd_ble_gap_lesc_dhkey_reply on conn_handle: 0
<info> app: BLE_GAP_EVT_CONN_SEC_UPDATE
<info> app: Security mode: 1. Security level: 2
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding
<warning> app: PM_EVT_CONN_SEC_SUCCEEDED
<info> app: BLE_GAP_EVT_AUTH_STATUS: status=0x0, bond=0x1, kdist_own:0x3 kdist_peer:0x2
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: New Bond, add the peer to the whitelist if possible
<info> app: whitelist_peer_cnt 1, MAX_PEERS_WLIST 8
<info> app: Bonded to a new peer, add it to the whitelist.
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_PEER_RANK
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_GATT_LOCAL
<warning> app: ble_evt_handler:53
<info> app: BLE_GATTS_EVT_WRITE
<info> app: Notification enabled
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Central address resolution, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_CENTRAL_ADDR_RES
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash changed.
<info> app: PM_PEER_DATA_ID_GATT_LOCAL
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.      
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.      
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.      
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 00 02 00 1E 00 1A 00|........
<info> app:  01 61 C6 00 54 53 11 00|.a..TS..
<info> app:  A5 16 FF 00            |....    
<info> app: BLE_GATTS_EVT_WRITE
<info> app: command_char_handles
<info> app:  01 01 FF FF 00 00 A7 0B|........
<info> app:  AF 16 00 01 00 00 00 52|.......R
<info> app:  7C 07                  ||.     

======
Here, intentionally turning the power of the central device OFF/ON to trigger a reconnection.
======

<info> app: Disconnected, reason 8.
<info> app: PM_EVT_CONN_CONFIG_REQ
<info> app: PM_EVT_CONN_SEC_PARAMS_REQ
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash not changed.
<info> app: PM_PEER_DATA_ID_PEER_RANK
<warning> app: PM_EVT_BONDED_PEER_CONNECTED
<info> app: PM_EVT_LOCAL_DB_CACHE_APPLIED
<info> app: BLE_GAP_EVT_CONNECTED
<info> app: PM_EVT_CONN_SEC_START
<info> app: BLE_GAP_EVT_SEC_INFO_REQUEST
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Encryption
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
<info> app: PM_EVT_PEER_DATA_UPDATE_SUCCEEDED
<info> app: Writing or overwriting the data.
<info> app: Flash not changed.
<info> app: PM_PEER_DATA_ID_PEER_RANK
<warning> app: PM_EVT_CONN_SEC_SUCCEEDED
<info> app: BLE_GAP_EVT_CONN_SEC_UPDATE
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:160, max_interval:160, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:80, max_interval:80, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:160, max_interval:160, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:80, max_interval:80, latency:0, timeout:810
<info> app: BLE_GAP_EVT_CONN_PARAM_UPDATE
<info> app: connection parameters updated. min_interval:160, max_interval:160, latency:0, timeout:810

[Hung Bui]

Hi Keigo, 
It seems like the central managed to reconnect so I am not sure why the write command was not sent. 
My suggestion is to use a sniffer to capture the communication. This would give us more insight of what could be wrong. You may have issue decrypting the paired connection with the sniffer if you secure connection, but you may consider turn off pairing for the test. 

Please double check the code of the central to see if it actually send the write command on the 2nd connection or not. 

[keigo.imaizumi]

Dear Mr. Hung Bui,

Thank you very much for responding to my inquiries!

Is it possible to communicate with the Central without pairing by turning off pairing?

Also, since the Central receives finished products from the trading company and is not involved in the internal software, I have no knowledge of it.
Furthermore, it seems that there are other companies creating peripherals that collaborate with this Central using Nordic.

However, before using Nordic chips, I successfully communicated with the Central using a peripheral with Linux's BlueZ.
At that time, even after reconnecting, the write events were received properly.
Therefore, it seems there may be an issue with the peripheral I am trying to implement with Nordic this time.

Thank you for your assistance.

[Hung Bui]

Hi Keigo-san, 

If you don't have control over the central device then it may not be possible to turn off pairing. 
One option is to get the LTK out from the peripheral and then input that to the sniffer so that the sniffer can decrypt the connection. 

I don't see any problem from the peripheral side. The central reconnected after the power reset. And then the link was re-encrypted, so everything looks normal at that point. The question is why the central didn't send any write command. 

[keigo.imaizumi]

Hello Mr. Hung Bui,

I am currently in the process of ordering the Sniffer.
It is expected to arrive sometime this week. Before that, I have a few questions.

1. After the bonding process is completed, what function in the nRF SDK should be used to retrieve the LTK from the peripheral? Also, considering that my PC is a MacBook, would Wireshark be suitable for the tools?

2. I am not confident that my peripheral-side implementation is flawless.
   I have some questions regarding the implementation.
   In the case of LE Secure Connection + Just Works pairing method, what actions should the application take in response to PM_EVT_CONN_SEC_PARAMS_REQ, BLE_GAP_EVT_SEC_PARAMS_REQUEST, and BLE_GAP_EVT_SEC_INFO_REQUEST events?
   Currently, based on various samples, my application is merely detecting events without taking any action.
   
   

   case BLE_GAP_EVT_SEC_PARAMS_REQUEST: {
           ble_gap_evt_sec_params_request_t const* p_sec_params_request = &p_ble_evt->evt.gap_evt.params.sec_params_request;
           NRF_LOG_INFO("BLE_GAP_EVT_SEC_PARAMS_REQUEST");
           UNUSED_PARAMETER(p_sec_params_request);
       } break;
   
   case BLE_GAP_EVT_SEC_INFO_REQUEST: {
           ble_gap_evt_sec_info_request_t const* p_sec_info_request = &p_ble_evt->evt.gap_evt.params.sec_info_request;
           NRF_LOG_INFO("BLE_GAP_EVT_SEC_INFO_REQUEST");
           UNUSED_PARAMETER(p_sec_info_request);
       } break;
       
   case PM_EVT_CONN_SEC_PARAMS_REQ: {
           pm_conn_sec_params_req_evt_t const* p_conn_sec_params_req = &p_evt->params.conn_sec_params_req;
           NRF_LOG_INFO("PM_EVT_CONN_SEC_PARAMS_REQ");
           UNUSED_PARAMETER(p_conn_sec_params_req);
       } break;

   
   
   

3. When BLE_GAP_EVT_CONN_PARAM_UPDATE is received, is there anything specific that the peripheral should do?

Thank you.

[keigo.imaizumi]

Hi Mr. Bung Bui-San.

LTK, but if I do the following, will the BLE_GAP_EVT_AUTH_STATUS event get a value for s_gap_sec_key?

When I want to see encrypted packets in sniffer,
Is it enough to know the LTK?

case BLE_GAP_EVT_SEC_PARAMS_REQUEST: {
        ble_gap_evt_sec_params_request_t const* p_sec_params_request = &p_ble_evt->evt.gap_evt.params.sec_params_request;
        NRF_LOG_INFO("BLE_GAP_EVT_SEC_PARAMS_REQUEST");
        // BLE_GAP_EVT_AUTH_STATUS -> insert to s_gap_sec_key
        sd_ble_gap_sec_params_reply(p_ble_evt->evt.gap_evt.conn_handle, BLE_GAP_SEC_STATUS_SUCCESS, &p_sec_params_request->peer_params, &s_gap_sec_key);
        UNUSED_PARAMETER(p_sec_params_request);
    } break;


case BLE_GAP_EVT_AUTH_STATUS: { // pairing complete event
        ble_gap_evt_auth_status_t const* p_auth_status = &p_ble_evt->evt.gap_evt.params.auth_status;
        // success pairing
        if (p_auth_status->auth_status == BLE_GAP_SEC_STATUS_SUCCESS) {
            NRF_LOG_INFO("BLE_GAP_EVT_AUTH_STATUS: Pairing Success!!");
            if (p_auth_status->bonded) {
                NRF_LOG_INFO("bonded:0x%x, kdist_own:0x%x kdist_peer:0x%x", p_auth_status->bonded, *(uint8_t*) (&p_auth_status->kdist_own), *(uint8_t*) (&p_auth_status->kdist_peer));
                NRF_LOG_INFO("own ltk:");
                NRF_LOG_HEXDUMP_INFO(s_gap_sec_key.keys_own.p_enc_key->enc_info.ltk, s_gap_sec_key.keys_peer.p_enc_key->enc_info.ltk_len);
                NRF_LOG_INFO("peer ltk:");
                NRF_LOG_HEXDUMP_INFO(s_gap_sec_key.keys_peer.p_enc_key->enc_info.ltk, s_gap_sec_key.keys_peer.p_enc_key->enc_info.ltk_len);
            }
            // error??
            else {
                NRF_LOG_ERROR("No bonded:0x%x", p_auth_status->bonded);
            }
        }
        // failed pairing
        else {
            NRF_LOG_ERROR("BLE_GAP_EVT_AUTH_STATUS: Pairing Failed!! resaon:0x%x", p_auth_status->auth_status);
        }

[Hung Bui]

Hi Keigo, 

keigo.imaizumi said:

LTK, but if I do the following, will the BLE_GAP_EVT_AUTH_STATUS event get a value for s_gap_sec_key?

It's been a long time since I tested the LTK with nRF5 SDK and the sniffer but as far as I know the ltk key when you receive BLE_GAP_EVT_AUTH_STATUS  is the one that you should input to the sniffer. I am not so sure it should be own or peer key, I think it depends on which key is agreed when the 2 device pair. The sniffer trace (before encryption) should tell which key should be used. 

This same key will be re-used when the 2 re-connect. You can check that in the peer manager in the peripheral when they reconnect. 

Regardless if you can decrypt the encrypted link, please try to capture the sniffer trace, at least we can check if they can re-pair properly or not. 

From the log I don't see any problem with your peripheral regarding re-encryption the link. 

[keigo.imaizumi]

Hello, Hung Bui-San.

I can now see communication between Central and Peripheral using the sniffer.

However, I'm getting the error "Encrypted packet decrypted incorrectly (bad MIC)." Is there a solution?
I dumped the LTK "00 04 00 20 01 0a 00" in the lower left of the image and entered it into WireShark as SC LTK with 0x00040020010a00 (or in MSB),
but it didn't work.

[Hung Bui]

Hi Keigo, 

You would need to input the key and then try to capture a new connection (with the 2 same device, they will re-use the LTK). 

Could you send us your sniffer trace , even though it has "Encrypted packet decrypted incorrectly (bad MIC)." Both when you first bond the 2 devices and when you re-connect. 

[keigo.imaizumi]

I will send a packet sniffer.

No. 2358 is the first connection and bonding. No. 2682 marks the beginning of a reconnection. If there are any suspicious points, your guidance would be greatly appreciated! I've been struggling with this issue for days and haven't been able to resolve it.

[Hung Bui]

Hi Keigo, 
I don't see anything suspicious from the sniffer trace. 
It seems that the re-encryption worked properly and the 2 devices managed to re-connect and re-pair with no problem. 
The question, I guess, is why the central doesn't want to send the write request on reconnection. If the link can be decrypted it would be much easier to inspect. 
Please make sure you type the key and click the arrow button after you enter it. 

If your central accept legacy pairing you can try disable LESC and only do legacy pairing, this way the sniffer can automatic decrypt Just Work encryption without you providing the key. 

[keigo.imaizumi]

Hello Mr. Hung Bui,

I'm sorry, but I'm not sure how to obtain the key.
I'm a beginner when it comes to bonding.
Could you please provide guidance on how to obtain the key?
By the way, is the key you mentioned the public key that appears in the sniffer? (Is it either x or y?)

Also, what type of key should be set in WireShark? (The part where you choose SC LTK or SC Private Key, etc.)
I apologize for the basic nature of these questions, as this is my first time delving into protocol analysis. Your guidance would be greatly appreciated!

Thank you.

[Hung Bui]

Hi Keigo, 
I will try to do the test here but if you take a look at the documentation you can find the instruction: 
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_ble%2FUG%2Fsniffer_ble%2Faction_bonded.html

I think what you did was correct but for some reason it didn't work. I will check