SDK15.3.0 SD6.1.1 LL_LENGTH_REQ causing disconnects

[Jefferson]

I've seen many posts about LL_LENGTH_REQ causing disconnection on certain Android phones and the solution from Nordic is to add a 100ms delay.  Can someone from Nordic definitively say what the problem is and fix it officially in the SDK or SD?

https://devzone.nordicsemi.com/f/nordic-q-a/53262/ble-disconnects-with-samsung-phones

https://devzone.nordicsemi.com/f/nordic-q-a/39271/unexpected-connection-termination/155149#155149 

From my capture, I can see this sequence:

Exchange MTU Request from nRF

LL_LENGTH_REQ from nRF

Exchange MTU Response from phone

Shouldn't the nRF wait for the Exchange MTU Response before sending the LL_LENGTH_REQ?  Is the correct fix just to add 100ms delay before calling data_length_update()?  It doesn't seem to fix the problem for everyone.  I don't have enough devices to test to make a conclusion.

 

[Susheel Nuguru]

Shouldn't the nRF wait for the Exchange MTU Response before sending the LL_LENGTH_REQ?

It should probably wait, but which thread says that we could wait 100ms before calling the data_length_update?

Can you please upload the full trace log so that I could see a bit of the history of events before this error

[Jefferson]

The first link says put 100ms delay.  I want to check if the remote device supports packet length extension from LL_FEATURE_REQ and not call data_length_update() if not supported.  How do I do that?

- Which SD and SDK have you built your application on?

- Do you have an on-air sniffer log?

- Can you also check the disconnect reason on the nRF52840? Should be passed with the BLE_GAP_EVT_DISCONNECT event in p_ble_evt->evt.gap_evt.params.disconnected.reason, I expect reason to be one of the Bluetooth status codes as listed in ble_hci.h.

- You may try to comment out data_length_update(conn_handle, p_gatt); in on_connected_evt() in nrf_ble_gatt.c (or add a 100ms delay before calling it).

Best regards,
Kenneth

This is the log.length2.cfa

[Susheel Nuguru]

Jefferson said:

I want to check if the remote device supports packet length extension from LL_FEATURE_REQ and not call data_length_update() if not supported.  How do I do that?

Not calling data_length_update after LLCP Feature exchange procedure is completely OK AFAIK. Looking at the latest sniffer log you updated in log.length2.cfa. I cannot see any FEATURE_REQ packets here. 

I think it is easier if you help me reproduce the error you are getting. So that I cannot see it to myself on the sniffer on my desk that calling FEATURE_REQ and not calling DATA_LENGTH_UPDATE is causing disconnect.

Which phone are you testing this on the peer side?

[Jefferson]

I want to use packet length extension.  If I don't call data_length_update() I can't rely on the other side to do it.  LL_FEATURE_REQ is frame 5754.  LL_FEATURE_RSP is 5837 from Nordic.  Why does SD 6.1.1 show LE Data Packet Length Extension: Not used?  The phone causing problems is Galaxy Note 4.  I don't have this phone or any phone that causes the disconnect.  It is being reported by someone else who doesn't have a sniffer to capture data.  He is saying the phone doesn't respond to the LL_LENGTH_REQ.  If that is the case, the only solution to this problem is to not send LL_LENGTH_REQ if the other side doesn't support it in LL_FEATURE_REQ.  I don't see any SD API to allow me to check the remote features.

[Susheel Nuguru]

Unfortunately, I cannot reproduce this on any other phone I have and I do not have Galazy Note 4.

I would not understand why the SD6.1.1 would behave differently for the same sequence of requests from different phone.