Nimble unable to change MTU (IDFGH-8130)

[FcoFabra]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

ESP32 - Android communication seems to fail if sending a message longer than 23 Bytes (20 bytes payload), when using Nimble.
Before any connection is performed, we run the folwing command to increase the MTU when the phone (client-central) connects to ESP32 (server-peripheral):

if (ble_att_set_preferred_mtu(247) != 0) {return RES_ERROR;}

We already sniffed traffic with a nRF dongle with the following result:
LL_LENGTH_REQ (from Android):
Max RX octets: 251
Max RX time: 2120 microseconds
Max TX octets: 27
MAX TX time: 328 microseconds

LL_LENGTH_RSP (from ESP32):
Max RX octets: 251
Max RX time: 2120 microseconds
Max TX octets: 27
MAX TX time: 328 microseconds

Once the communication starts, the ESP32 can send a notification with any content, but in the sniffed data we can see that only the first 20 bytes of data are sent. It means that ESP32 is honoring the limit of 27 octets for TX even when we used "ble_att_set_preferred_mtu()" before. We also tried to use this function in "BLE_GAP_EVENT_CONNECT" event without success.

It seems that there is a BUG in the way Nimble negotiates MTU!
Android informs that it is ready to receive up to 251 bytes, but when the ESP32 responds, it informs that it will also be able to send 27 bytes, despite the fact that we used "ble_att_set_preferred_mtu(247)" to increase the MTU negotiated.

A solution would be to negotiate the MTU like iOS does. From that point, any notification greater than 20 bytes will be split in chunks with L2CAP protocol. This is performed automatically, but this solution is A BAD IDEA, as a message of 160 bytes will be splitted in A LOT of packets, and the time required for transmission will increase too much.

• Are you planning to add MTU negotiation support to Nimble?
• Is it only available in Bluedroid as it seems to be?

I've found other functions that could help, but they are related to Bluedroid, not to Nimble:
esp_ble_gap_set_pkt_data_len(); esp_ble_gatt_set_local_mtu();

Using IDF 4.3.3

Best regards

[rahult-github]

Hi @FcoFabra ,

I think the issue is not that Nimble is not able to set MTU properly, but the fact that controller is still sending 27 bytes fragment. The MTU is more at protocol level. There is a need to configure controller to allow larger size fragments.

Recently , cb74a64 commit was made that added support for the HCI commands for Read / Write suggested default length command.

You can invoke these API to configure the controller. Hope this helps.

Thanks,
Rahul

[rahult-github]

Closing this issue. Feel free to reopen in case of any further comments.

[rahult-github]

Closing this issue. Feel free to reopen in case of any further comments.

[xyzzy42]

There nothing in the Espressif FAQ on DLE about needing to configure the controller to allow larger LL packets:

Yes, Bluetooth 4.2 DLE is supported in all versions of ESP-IDF. There is no sample code provided currently. You can implement this by calling corresponding APIs directly. Please refer to esp_ble_gap_set_pkt_data_len.

In fact, I can not find the functions for increasing LL packet size mentioned anywhere in Espressif documentation.

[lucic71]

There nothing in the Espressif FAQ on DLE about needing to configure the controller to allow larger LL packets:

Yes, Bluetooth 4.2 DLE is supported in all versions of ESP-IDF. There is no sample code provided currently. You can implement this by calling corresponding APIs directly. Please refer to esp_ble_gap_set_pkt_data_len.

In fact, I can not find the functions for increasing LL packet size mentioned anywhere in Espressif documentation.

I do have the same problem.

[phelicksg]

I have the same problem. I looked at the commit referenced above, and wrote a few lines to test it:

uint16_t out_sugg_max_tx_octets, out_sugg_max_tx_time;
  // check maximum data length size in BLE controller
  ble_gap_read_sugg_def_data_len(&out_sugg_max_tx_octets, &out_sugg_max_tx_time);
  int r1=ble_hs_hci_util_set_data_len(ble_conn_hdl, 54, out_sugg_max_tx_time);
  int r2=ble_gap_set_data_len(ble_conn_hdl, 54, out_sugg_max_tx_time);
  int r3=ble_gap_write_sugg_def_data_len(54, out_sugg_max_tx_time);
  int r4=ble_hs_hci_util_write_sugg_def_data_len(54, out_sugg_max_tx_time);
  ESP_LOGE ("myfunc", "r1=%d r2=%d r3=%d r4=%d max data length: %d max xmission time %d", r1, r2, r3, r4, out_sugg_max_tx_octets, out_sugg_max_tx_time); 

And indeed, this is what I get:

(first time my function is called):
E (531) myfunc: r1=514 r2=514 r3=0 r4=0 max data length: 27 max xmission time 328

(second time++ my function is called)

E (77781) myfunc: r1=0 r2=0 r3=0 r4=0 max data length: 54 max xmission time 328

(So, I assume that the value of 54 has been successfully set).

However, using Wireshark, I can see that only 20 bytes are being transferred:

And this is even though I am sending 34 bytes (I wrote a function to dump the os_mbuf):

E (146161) lineNoiseSend: buffer is of len 34 and of value: [13](?):[115](s):[101](e):[110](n):[115](s):[111](o):[114](r):[62](>):[32]( ):[97](a):[98](b):[99](c):[100](d):[101](e):[102](f):[103](g):[104](h):[105](i):[106](j):[107](k):[108](l):[109](m):[110](n):[111](o):[112](p):[27](?):[91]([):[48](0):[75](K):[13](?):[27](?):[91]([):[56](8):[67](C):

And that os_mbuf is sent like this:

err = ble_gattc_notify_custom(ble_conn_hdl, notify_char_attr_hdl, om);