SD_BLE_GAP_DISCONNECT event not received in some cases

[karnram]

If we try to force terminate an ogoing BLE connection by invoking sd_ble_gap_disconnect, we don't receive the SD_BLE_GAP_DISCONNECT event in some cases even after the supervision timeout.It is not easily reproducible and we have not been able to capture sniffer logs for the same. We did defensively added an application side timeout logic which fires up after 20 seconds to cleanup the connection context in such cases. One of the key step as part of connection cleanup is to restart the BLE advertisement in Connectable mode (as we change it to NonConnectable mode after first connection to prevent more than one concurrent connections). But this step (invoking sd_ble_gap_adv_start) fails with NRF_ERROR_CONN_COUNT in such cases. It seems like softdevice still hasn't cleaned up the connection context for first connection and it rejects advertising again in connectable to prevent more than one concurrent connections. I have following specific questions:

1. What can cause softdevice to completely miss raising SD_BLE_GAP_DISCONNECT event in some cases? Can we configure any additional timeout (otherthan supervision timeout) in softdevice to generate an explicit timeout event in such cases?

2. Is there a way to force softdevice to cleanup the connection context in case of such failures.

[karnram]

ovrebekk said:

Are you able to identify at which of these handshake steps it disconnects, or how old the connection is at the time it happens?

Yes, it disconnects at first handshake failure after 10 seconds. 

I tried disconnecting the connection using a lower timeout like 5 seconds, but still I was not able to reproduce the issue in my local setup. I did see INVALID_STATE error when disconnecting within 1 second of connection:

[07:11:37.614] <error>: Error, cannot execute sd_ble_gap_disconnect, err_code: 8, NRF_ERROR_INVALID_STATE

Did you hear from an internal team if there is really a minimum time before which we cannot call disconnect? 

ovrebekk said:

When you say a reproducibility rate of 0.03%, do you mean the error has occurred on 0.03% of the devices you have produced in that period?

No, I meant 0.03% of disconnection attempts (throughout the network) failed with such behavior.

ovrebekk said:

Is the issue discovered in production, or is it a field return from customers?

Discovered in production.

[ovrebekk]

Hi

karnram said:

Did you hear from an internal team if there is really a minimum time before which we cannot call disconnect? 

There shouldn't be, no. As soon as the CONNECTED event occurs you should be able to disconnect. 

Does your log show that the connected event occurs 1 second before you try to disconnect?

karnram said:

No, I meant 0.03% of disconnection attempts (throughout the network) failed with such behavior.

Thanks. So this means it happens randomly on different devices?
In other words, it doesn't seem to be hardware related, but an issue that all devices could potentially be affected by?

Best regards
Torbjørn

[peica]

we meet the same issue. after a short timeout like 6 seconds, we will call the sd_ble_gap_disconnect to stop the connection(return OK). but could  not trigger the  BLE_GAP_EVT_DISCONNECTED event. 

the BLE_GAP_EVT_DISCONNECTED will arrive again when we got a BLE_GATTC_EVT_TIMEOUT.

[ovrebekk]

Hi

Can you please open a new ticket on this, and share any additional information you might have?

If you have a sniffer trace of the BLE activity that could be very helpful. 

Feel free to point to this case, or mention my name, and it will be assigned to me. 

Best regards
Torbjørn