The disconnection problem when using nRF52832 on Redmi 5A

[Karr]

Hi, I found that there is a BLE_HCI_DIFFERENT_TRANSACTION_COLLISION when I use nRF52832 in secure connections.
The connection would disappear in 32 secs, but there won't be any problem if i don't use secure connections.
My cell phone is Redmi 5A, Android 8.1, and the bluetooth used is 5.0.
But the connection is fine when using Samsung Galaxy J2 Prime and Oppo A33.
Below is the log of wireshark. Does anyone know how to solve this problem?Redmi 5A.pcapng

[daviddedwin]

Taking a quick look at the LL transactions I can see that the LL_LENGTH_REQ from Slave and the LL_VERSION_IND from the Master are outstanding at the same time, this is NOT a specification violation for max one outstanding LL transaction.

The Redmi is reporting that the long packets are not supported on its LL controller based on responding with a LL_UNKNOWN_RSP. You are correct that the Qualcomm controller on the Redmi is reporting a Bluetooth version of 5.0. The nRF52832 VERSION_IND is reporting BT Spec version 5.1 and subversion 0x0101.

It looks like you are using s132_nrf52_7.2.0 (I think the firmware ID is reported in the Subversion number). The sniffer is reporting that the link is successfully encrypted master to slave and slave to master  so the probability of a LL security procedure failure is lower but should be checked.

The last transaction from the master to the slave that is acked by the slave is packet number 4729 which is ~63 seconds from the CONNECTION_IND, however you mention that a link loss happens at 32 seconds, is this the correct sniffer capture that you are talking about with the BLE_HCI_DIFFERENT_TRANSACTION_COLLISION ?  Can you confirm this.

Packet number 2916 from the master has a MIC failure but the CRC is correct, which is a bit odd as such a failure should result in an immediate link loss, however the link is lost only after 30 seconds. This can be the root cause of the link loss with the Redmi. This can also result in the odd error code that you see. The slave eventually stops responding to the master after 30 seconds as the link should not proceed once a packet with a MIC failure has been received.

[Kenneth]

Try to add the following line of codes to the BLE_GAP_EVT_CONNECTED event:

//Add to BLE_GAP_EVT_CONNECTED event:

ble_opt_t opt = {0};
opt.gap_opt.auth_payload_timeout.conn_handle = m_conn_handle;
opt.gap_opt.auth_payload_timeout.auth_payload_timeout = 300; 
err_code = sd_ble_opt_set(BLE_GAP_OPT_AUTH_PAYLOAD_TIMEOUT, &opt);
APP_ERROR_CHECK(err_code);

This should initiate a ping request from the peripheral, before the peer send a ping request. It looks like the peer send two ping requests in a row (see two LL_PING_REQ with different sequence numbers) without waiting for peripheral to respond to the first (there should be a LL_PING_RSP between the two LL_PING_REQ), this is a violation of the BLE spec, the above code snippet should work around this problem by initiating the ping request from the peripheral instead. Presuming that is the issue.

[daviddedwin]

The two ping requests as Kenneth states is the likely culprit, as the slave radio stops immediately afterwards and that reflects the BLE_HCI_DIFFERENT_TRANSACTION_COLLISION behaviour.

The work around suggested says that the slave starts the ping requests  and the master seeing the ping requests would see that there are packets arriving with an authenticated MIC (verifying the peer LL) and hence would not send its own (broken) ping requests. The master's ping requests timer seems to be running at 30 seconds, so a ping request coming from the slave should run faster than that to preempt the master from sending the ping requests.

Would be good to see the results after you add the work around to see if the Redmi LL is only slightly broken or has other trouble.

[Karr]

It does works out after testing. It had been bothered me for so long. Thank you so much for solving this problem! Appreciate your help.