MTU exchange leads to LMP error if sd_ble_gap_data_length_update is called

RE: MTU exchange leads to LMP error if sd_ble_gap_data_length_update is called

Cyril — Thu, 02 Aug 2018 13:57:11 GMT

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

RE: MTU exchange leads to LMP error if sd_ble_gap_data_length_update is called

bjorn-spockeli — Wed, 01 Aug 2018 08:59:13 GMT

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

RE: MTU exchange leads to LMP error if sd_ble_gap_data_length_update is called

Cyril — Wed, 25 Jul 2018 15:54:34 GMT

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

devzone.nordicsemi.com/.../connection_5F00_fail.pcapng

Let me know if you have an idea.

RE: MTU exchange leads to LMP error if sd_ble_gap_data_length_update is called

bjorn-spockeli — Wed, 25 Jul 2018 15:07:45 GMT

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