PM_EVT_CONN_SEC_FAILED

RE: PM_EVT_CONN_SEC_FAILED

Simon — Wed, 12 Jun 2019 22:14:01 GMT

I wouldn't recommend you to use the code I provided, it was written in a rush and not my proudest work. You should start a new case, and present your problem there.

Best regards,

Simon

RE: PM_EVT_CONN_SEC_FAILED

EGawtry — Sun, 09 Jun 2019 19:56:18 GMT

I have a similar issue that prevents Linux BLE from working. (Works great on Windows.)

I am confused, your "Add This" code doesn't have a case statement to match (and the compiler complains). It also falls through.

Please help!

-Erik

RE: PM_EVT_CONN_SEC_FAILED

Simon — Wed, 08 May 2019 08:34:35 GMT

That's great, I'm happy you finally figured it out.

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Tue, 07 May 2019 15:21:13 GMT

Hi Simon. I've been assuming that the problem resided on my nRF52 development boards because that is where I am developing new code, which is operating as a Central and Peripheral. Performing an erase all on these boards never changed the PM_EVT_CONN_SEC_FAILED symptom.

Today I performed an erase all on our custom BLE device which acts as a peripheral. It is the device that my Central/Peripheral must automatically connect to. The erase all and reprogramming of the custom peripheral device caused the failed Central/Peripheral nRF52 boards to start working again.

RE: PM_EVT_CONN_SEC_FAILED

Simon — Tue, 07 May 2019 15:01:56 GMT

No problem. Let me know if you have any more issues.

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Tue, 07 May 2019 14:06:21 GMT

My mistake, sorry. I will set the breakpoint as suggested and proceed from there.

RE: PM_EVT_CONN_SEC_FAILED

Simon — Tue, 07 May 2019 07:29:49 GMT

[quote user="mzarling"][/quote]

<info> peer_manager_handler: Connection security failed: role: Central, conn_handle: 0x0, procedure: Bonding, error: 133

Is this what you asked for?

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Tue, 07 May 2019 04:56:07 GMT

Hi Simon. I never said that I got a procedure failed of 133 (0x85), so I'm not sure your suggested changes in im_ble_evt_handler() are relevant.

RE: PM_EVT_CONN_SEC_FAILED

Simon — Mon, 06 May 2019 09:31:25 GMT

I am not too familiar with the log message and what it means, and I could not find much information about it either.

I might be on thin ice here, and I am not sure if I understand everything perfectly, but I'll take a shot.

You said you got a procedure failed of 133 (0x85), which corresponds to a BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP. If I understand everything correctly, this comes from the smd_params_reply() function in the security_dispatcher.c file. Specifically these lines:

if ((im_peer_id_get_by_conn_handle(conn_handle) != PM_PEER_ID_INVALID) &&
            (role == BLE_GAP_ROLE_PERIPH) &&
            !allow_repairing(conn_handle))
        {
            // Bond already exists. Reject the pairing request if the user doesn't intervene.
            send_config_req(conn_handle);
            if (!allow_repairing(conn_handle))
            {
                // Reject pairing.
                sec_status = BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP;
            }
        }

However, could you set a break point at sec_status = BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP; to check if this line is executed.

This line should be run if there is a valid peer associated with the connection handle, if the role is peripheral and repairing is not allowed. The problem for you (I guess) is that the function im_peer_id_get_by_conn_handle() returns a valid peer id.

How should you avoid this? First take a look at the id_manager.c file and the function im_ble_evt_handler(). After a connection, it will look for the address of the newly connected peer among the peer data in flash. If it finds the address, it will associate the connection handle with the matching peer id thorugh the line:

m_connections[gap_evt.conn_handle].peer_id = bonded_matching_peer_id;

and the peer id will not be invalid anymore, and you will get a BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP as described above.

 case BLE_GAP_ADDR_TYPE_RANDOM_STATIC:
               while (pds_peer_data_iterate(PM_PEER_DATA_ID_BONDING, &peer_id, &peer_data))
                {
                    if (addr_compare(&gap_evt.params.connected.peer_addr,
                                     &peer_data.p_bonding_data->peer_ble_id.id_addr_info))
                    {
                        bonded_matching_peer_id = peer_id;
                        break;
                    }
                }

The easiest way to solve this, would be to simply erase all the flash, but lets try another approach. Inside the function im_ble_evt_handler() add this code snippet under switch (gap_evt.params.connected.peer_addr.addr_type)

.
.

switch (gap_evt.params.connected.peer_addr.addr_type)
    {
        /////Add this///
        while (pds_peer_data_iterate(PM_PEER_DATA_ID_BONDING, &peer_id, &peer_data))
        {
            if (addr_compare(&gap_evt.params.connected.peer_addr,
                             &peer_data.p_bonding_data->peer_ble_id.id_addr_info))
            {
                pds_peer_id_free(peer_id);
                break;
            }
        }
        /////Add this///
    case BLE_GAP_ADDR_TYPE_PUBLIC:
    .
    .

Similarly if your address is resolvable, you switch out addr_compare() with im_address_resolve(). This code snippet will erase all peer data from flash related to the address. This code snippet is only supposed to run once, in order to delete the peer data from flash, and you should stop the code execution after these lines. This is a quite messy way of doing it, and is is probably a more easy and clean approach, my apologies for that.

You could also try this.

Best regards,

Simon

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Thu, 02 May 2019 21:53:43 GMT

I have run out of things to try. I purchased a couple more dev boards, in case it happens again. As long as I don't switch back and forth between my firmware and "ble_app_hrs_rscd_relay" example on the same dev board, the problem doesn't happen. But I have 2 previous dev boards I can't use now because of this. I even program them with the BLE peripheral heart rate example, and they don't work.

Did you see my question earlier? When I did a full erase in nRF Connect, the log showed "Non-volatile memory has been read. 1 non-empty memory blocks identified".

Is that normal?

RE: PM_EVT_CONN_SEC_FAILED

Simon — Thu, 02 May 2019 20:58:29 GMT

I am sorry for the long delay. Have you resolved the issue? If not I will look into it the upcoming days.

Best regards,

Simon

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Fri, 26 Apr 2019 12:42:03 GMT

Have you had a chance to look into this more?

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Wed, 24 Apr 2019 16:01:19 GMT

I just tried nrfjprog --eraseall and still no luck.

I still have one nRF52 board that works fine with the same firmware. I get PM_EVT_CONN_SEC_SUCCEEDED when connecting to a peripheral. Almost certainly if I program it with the example "ble_app_hrs_rscs_relay" and then go back to my custom firmware, then this nRF52 board will no longer work correctly.

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Wed, 24 Apr 2019 15:25:36 GMT

I performed a Recover (full erase) in nRF Connect. The nRF52 dev board still throws PM_EVT_CONN_SEC_FAILED when connecting to a peripheral.

In nRF Connect, the log shows "Non-volatile memory has been read. 1 non-empty memory blocks identified." This is after the full erase. Is this normal?

RE: PM_EVT_CONN_SEC_FAILED

Simon — Wed, 24 Apr 2019 14:50:33 GMT

I don't think all the contents of the flash gets erased when doing it from SEGGER. Could you try to erase flash either by using nRF Connect for Desktop or the command nrfjprog --eraseall?

Best regards,

Simon

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Wed, 17 Apr 2019 15:14:04 GMT

Thank you Simon. I look forward to continuing our discussion when you get back. Have a great holiday.

RE: PM_EVT_CONN_SEC_FAILED

Simon — Wed, 17 Apr 2019 14:04:30 GMT

After bonding, the bonding information is stored in flash, and my suspicion is that this data prevents you from bonding again somehow. But, this should get resolved by erasing all the content of the chip.

I haven't been able to get a full grasp of your problem, and need some more time.

I'll be gone for some days due to easter break, but will be back the 23.04 and will look further into your issue then.

Best regards,

Simon

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Wed, 17 Apr 2019 12:39:12 GMT

I'm using Segger Embedded Studio and used Target -> Erase All from the menu.

RE: PM_EVT_CONN_SEC_FAILED

Simon — Wed, 17 Apr 2019 07:39:13 GMT

What command did you run in order to erase the content of the chip, did you use nrfjprog --eraseall?

Best regards,

Simon

RE: PM_EVT_CONN_SEC_FAILED

mzarling — Tue, 16 Apr 2019 15:06:48 GMT

<info> peer_manager_handler: Connection security failed: role: Central, conn_handle: 0x0, procedure: Bonding, error: 133

Is this what you asked for?

RE: PM_EVT_CONN_SEC_FAILED

Simon — Tue, 16 Apr 2019 11:59:16 GMT

Are you able to reproduce the error? If so, take a look at the log in pm_handler_pm_evt_log(..) (In the peer_manager_handler.c) and check which procedure failed (pm_conn_sec_procedure_t) and the error code (pm_sec_error_code_t).

Best regards,

Simon