Problem with multiple connection in multirole device

RE: Problem with multiple connection in multirole device

Hung Bui — Thu, 15 Sep 2022 10:50:08 GMT

Hi Jakub,

Glad to know that you found the root cause. It's always a challenge to work with legacy code.

RE: Problem with multiple connection in multirole device

kubazdz — Wed, 14 Sep 2022 13:27:26 GMT

Ok, I've found the root of the problem. There was pm_sec_params_set(NULL); call in BLE_GAP_EVT_DISCONNECTED event in peripheral role event handler. (idk why, it is a legacy code but it didn't cause issues before dual role was implemented), which resulted in NULL sec params pointer after peripheral role disconnection. The ticket can be closed, thanks

RE: Problem with multiple connection in multirole device

kubazdz — Wed, 14 Sep 2022 13:26:38 GMT

RE: Problem with multiple connection in multirole device

kubazdz — Wed, 14 Sep 2022 11:58:37 GMT

Ok, I've managed to track the issue but I could use some advice. So when until everything is ok, then when link_secure_central is called, p_sec_params are not NULL, but the failure happens when the phone disconnects, and peripheral wants to connect again, then p_sec_params == NULL and therefore return link_secure_authenticate(conn_handle, NULL); in security_dispatcher.c:967 is called. Any idea what can be the cause of the fact that security parameters are not set?

RE: Problem with multiple connection in multirole device

Hung Bui — Thu, 08 Sep 2022 11:34:06 GMT

Hi Jakub,
Could you let me know more about your setup ? Why you can program it but not debug it ?
Can you reproduce the issue on a development kit ?
If you test with ble_app_hrs_rscs_relay do you see the same problem ?
If not have you checked the sdk_config.h file to see if there is any difference ?

The conn_handle is simply increment from 0 or from the first free connection handler. I don't see an issue if the conn_handle is 1 or 0 or other as long as you use the correct conn_handle for the correct connection you want to control.

What is a "correct" connection handle then ? It's the connection handle that originally returned from BLE_GAP_EVT_CONNECTED

However, I don't think the issue is with the connection handle. It may have something to do with either sd_ble_gap_encrypt() that's called by link_secure_central_encryption().

Please try to debug the smd_link_secure() function or use log to debug, and find what exactly throwing NRF_ERROR_INVALID_ADDR.

RE: Problem with multiple connection in multirole device

kubazdz — Thu, 08 Sep 2022 09:28:38 GMT

Thanks for your answer. I don't have debug setup to set breakpoints, the only way I can debug is via logs. What I've managed to establish while playing around is:

1. This is the procedure to force the issue (I'm posting steps to show when exactly something goes wrong):
- pair with phone -> OK
- pair with peripheral - > OK
- connect with phone, connect and disconnect with peripheral while phone connected -> OK
- disconnect with phone -> OK
- connect with the peripheral (no matter if yo reconnect with phone or not) -> ERROR

2. The error hapens in pm_handler_on_pm_evt(p_evt) when p_evt == PM_EVT_BONDED_PEER_CONNECTED

3. The connection handles are ok each time it happens (always 0 for peripheral and 1 for phone)

4. For some reason phone gets conn_handle = 1 and peripheral gets conn_handle = 0 even if phone bonds first. Is it supposed to be that way?

It looks like during those operations the peer_manager looses bonding information of peripheral device. It seems like it happens when the phone disconnects. Could you please tell me how is address linked with conn_handle, and what are the possible reasons that pm_conn_secure won't have bonded device's address in it's memory?

RE: Problem with multiple connection in multirole device

Hung Bui — Wed, 07 Sep 2022 11:01:54 GMT

Hi Jakub,

The error log suggested a bad memory address (NRF_ERROR_INVALID_ADDR) . So we need to look into how you called pm_conn_secure() when you connected to the peripheral.

You may want to add a breakpoint and step into the code when the central (relay) try to encrypt the link after the connection is established. Double check if the connection handle is correct.