LL_CONNECTION_UPDATE_IND before response to Connection Parameters Update Request causes disconnect

[Saxman58]

Our peripheral application sends an L2CAP Connection Parameters Update Request to change the connection interval 30 seconds after connecting.  For most hosts, it works fine.  But with an Android 6 tablet it disconnects right after the switch to the new connection interval.  Wireshark shows the following packet sequence.

• Slave sends L2CAP Connection Parameters Update Request
• Master sends L2CAP Connection Parameters Update Request (Accepted)
• Slave sends empty PDU in response
• Master sends LL_CONNECTION_UPDATE_IND with details of the new parameters and when to switch
• At the proper time, the two sides change to the new connection interval and everything is fine

But with the Android 6 tablet, the order of the Master's packets is reversed, and the slave (our device) disconnects right after the interval switch:

• Slave sends L2CAP Connection Parameters Update Request
• Master sends LL_CONNECTION_UPDATE_IND with details of the new parameters and when to switch
• Slave sends empty PDU in response
• Master sends L2CAP Connection Parameters Update Request (Accepted)
• At the proper time, the two sides change to the new connection interval for just the first interval
• After that the slave immediately disconnects, stops responding and starts advertising again
• The host eventually gives up due to the lack of responses and also disconnects

We are using an nRF52833 with S113 SoftDevice, and version 17.0.2 of the SDK.  We get the same results when we change the requested range of the connection interval (e.g.- 100-200 msecs, 200-400, 20-200...) and the Android system always picks an interval within the requested range, so that doesn't seem to be the problem.

Does the order of the master's response matter?  The order that works matches what you show in your Peripheral Connection Parameter Update message sequence chart (https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s113.api.v7.2.0/group___b_l_e___g_a_p___c_p_u___m_s_c.html).  Does the BLE stack get confused and disconnect if the LL_CONNECTION_UPDATE_IND comes before the L2CAP acceptance of the request?

We don't seem to have this problem with later versions of Android (such as 9.x), but I don't have one here to try with Wireshark to see if its order is different.

Normal order works:

Reverse order from master.  Slave disconnects right after switching connection interval time.

[Saxman58]

The tablet is a Samsung 8" Galaxy Tab E, model SM-T377V running Android 6.0.1 (we have many like this in the field, so I didn't upgrade for testing).  The hardware version is T377V.01, but I don't know how to find the Bluetooth IC used.  At least some Samsung Galaxy models use Broadcom chips.  Websites say this model is Bluetooth 4.1 in the US and 4.0 elsewhere, but I can't confirm that and don't know if that is up to date.

[daviddedwin]

You can also take control of the   sd_ble_gap_data_length_update procedure, and see if the resulting update event does not arrive and the link disconnects with a reason code as below and fall back to a new connection without Data Length extensions.

Check the error code that BLE_GAP_EVT_DISCONNECTED would provide, I hope it would be a 0x22 (LL Response timeout) instead of a generic Connection Timeout (0x08).

You are correct that it appears to be at a 4.1 or 4.0 based on the LL_FEATURE_REQ from the master and it actually does not support the data length extension as the feature bit for that seems to be set to false.

As you have surmised you may be able to better control the procedure from the Android and maybe use a handshake to signal the nRF that is ok to start the DLE or not do so at all.