MTU exchange leads to LMP error if sd_ble_gap_data_length_update is called

[Cyril]

Hello,

we are facing a weird issue with a few models of smartphone since we increased the max MTU size. We are testing at the office with the Xperia E6553 but the Samsung Galaxy S5 Neo from one of our customers may also suffer from the same bug. 
After connection, I have an error: BLE_HCI_STATUS_CODE_INVALID_LMP_PARAMETERS.

I noticed that the issue doesn't appear using the bootloader even if I request a different MTU size from the smartphone app (nRF Connect). The only difference with the app is the request of the desired MTU that is not performed from the bootloader itself. However, on the app, we are using nrf_ble_gatt.c and an MTU exchange request is always sent so I removed the call to sd_ble_gap_data_length_update and it's now working well. The MTU still change but I don't call sd_ble_gap_data_length_update anymore, only sd_ble_gattc_exchange_mtu_request and I'm not sure that's the way this issue should be solve...

We are using SDK 13.0.0, nRF52832, SD 4.0.2.

Do you have an idea about the origin of that bug/issue?

Cheers

[bjorn-spockeli]

HI Cyril, 

just to make sure I understand the changes you have done in nrf_ble_gatt.c . Is it so that you commented out the following snippet in on_connected_evt()

// Send a data length update request if necessary.
if (p_link->data_length_desired > p_link->data_length_effective)
{
    data_length_update(conn_handle, p_gatt);
}

which is called when the BLE_GAP_EVT_CONNECTED is received? If so, did you examine the the data_length_desired and data_length_effective variables that is checked in a debug session? Does sd_ble_gap_data_length_update return anything else than NRF_SUCCESS? 

It would also be helpful if you could capture a sniffer trace when the sd_ble_gap_data_length_update call is included in the application code. 

Best regards

Bjørn 

[Cyril]

Hello,

Yes you're right, I removed the call to data_length_update(conn_handle, p_gatt);

Here is the GATT information before trying to update data_length:

No error code is returned by sd_ble_gap_data_length_update.

Here is the Wireshark trace using the Sony Xperia E6553, Android 7.1.1

connection_fail.pcapng

Let me know if you have an idea.

[bjorn-spockeli]

Hi Cyril, 

I apologize for the delayed reply. 

Is the BLE_HCI_STATUS_CODE_INVALID_LMP_PARAMETERS printed in the debug log output from the nRF52832? And is you application peripheral only or a combined central and peripheral?

From the trace I found the following:

The nRF52832 is issuing a LL_LENGTH_REQ with the following parameters

• Max RX Octets:  127
• Max RX Time:     1128us
• Max TX Octets:  127
• Max TX Time:    1128us

the link master replies with a LL_LENGTH_RSP

• Max RX Octets:  140
• Max RX Time:     256us
• Max TX Octets:  770
• Max TX Time:    1284us

According to the BLUETOOTH SPECIFICATION Version 5.0 | Vol 6, Part B, Section 2.4.2.21 LL_LENGTH_REQ and LL_LENGTH_RSP, the following rules apply:

• MaxRxOctets shall be set to the sender’s connMaxRxOctets value, as
  defined in Section 4.5.10. The MaxRxOctets field shall have a value not less
  than 27 octets.
•  MaxRxTime shall be set to the sender’s connMaxRxTime value, as defined
  in Section 4.5.10. The MaxRxTime field shall have a value not less than 328
  microseconds.
• MaxTxOctets shall be set to the sender’s connMaxTxOctets value, as
  defined in Section 4.5.10. The MaxTxOctets field shall have a value not less
  than 27 octets.
• MaxTxTime shall be set to the sender’s connMaxTxTime value, as defined
  in Section 4.5.10. The MaxTxTime field shall have a value not less than 328
  microseconds.

Hence, it appears that the Link master is passing an invalid value in its LL_LENGTH_RSP, i.e. Max RX Time: 256us < 328us.  However, it is wierd that the Link Master replies with these values at all because in the LL_FEATURE_REQ from the Master to the Slave it states that it does not support  LE Data Packet Length Extension. 

We cant do much about the invalid LL_LENGTH_RSP from the peer, but modifying the code so that   LL_LENGTH_REQ is sent not sent by the nRF52832 should be OK, the nRF52832 will still reply to LL_LENGTH_REQ from centrals. The con is that you will not be able to use the increased payload size unless the central initiates the LL_LENGTH_REQ. 

Bjørn

[Cyril]

Thank you Bjorn for the clarification. That makes sense. 

We are not sending LL_LENGTH_REQ anymore and there is no LL_LENGTH_REQ from the peer when using the Sony Xperia E6553.
I do have the request from master using another phone though (One Plus 3T) with RX and TX time set to 1096us, and the nRF stack is responding as expected.
Despite that, I can transfer packets with higher MTU using the Sony smartphone anyway... which shouldn't be possible (as far as the LE Data Packet Length Extension is not supported).

How can we know that the data length exchange is required or not?

Best,

Cyril