Reading long attribute with ATT MTU > 493 not working

[guti]

nRF52832 on a nRF52DK
connectivity_4.1.1_1m_with_s132_5.1.0.hex
pc_ble_driver_py v0.14.2

Steps to reproduce:
- connect to a peer device
- discover services and attributes
- update the ATT MTU size
- read the value of long attribute (in my case the maximum 512 bytes long)

With ATT MTU size = 493:
After calling adapter.read_req(conn_handle, uuid, offset=0) a `gattc_evt_read_rsp` event gets raised, which contains the data of the attribute. So everything works as expected.
BLE traffic (captured with Ellisys Bluetooth Analyzer) with att_mtu set to 393:
/resized-image/__size/1040x974/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-87b6c731786a47a5a4d102215f6a7c55/3730.att_5F00_mtu-393.PNG

With ATT MTU size = 494:
After calling adapter.read_req(conn_handle, uuid, offset=0) the `gattc_evt_read_rsp` event does not get raised, what ends in an error as the returned result is None.
According to the BLE traffic the "Read response" with according data has been send correctly over the air, though:
/resized-image/__size/1040x970/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-87b6c731786a47a5a4d102215f6a7c55/6765.att_5F00_mtu-394.PNG

Where is the problem here? Is the ATT MTU size not supposed be set to such a high value?

side notes:
# According to the Bluetooth Core Specificiation v5.0 & v5.2, Vol 3, Part F,
# 3.2.9: "The maximum length of an attribute value shall be 512 octets."
# And according to v5.0 & v5.2, Vol 3, Part F, 3.4.4.5 & 3.4.6.1:
# Reads and writes of long attributes (e.g. ATT_READ_BLOB_REQ or
# ATT_PREPARE_WRITE_REQ) use an ATT header size of 5 bytes.
# Reads and writes of not long attributes use an ATT header length of 3 bytes
# (e.g. for ATT_READ_REQ).
# Therefore the maximum transmission unit for the ATT protocol amounts to 517:
# 512 bytes (attribute data) + 5 bytes (ATT header)
# Just for info: the maximum MTU size accepted by the BLEAdapter is 927

Kind regards!

[Sigurd]

Hi,

Could you upload the sniffer logs?

What device is the peer device ? Another nRF52 device?

Do you have any logs from the peer device? Does the peer device crash? or does it get a BLE disconnect with timeout as the reason? 

[guti]

The peer device is a RSL10, which does not crash. We receive a disconnection indication - probably due to a timeout:
The sniffer log shows a time difference of ~4s after the read until the next peer device advertising.

I rather not upload the whole sniffer log, but here is an extended extract oft the read:
/resized-image/__size/1040x1328/__key/communityserver-discussions-components-files/4/att_5F00_mtu-394-read-extract.PNG
Sorry for the bad quality, but that's due to the upload...

The Read Response Packet can be seen on air, with expected length and content.
But the gattc_evt_read_rsp (corresponds to driver.BLE_GATTC_EVT_READ_RSP) event does never occur.
Notice: this only applies if the ATT MTU size was updated to a value > 393.
With a value  value <= 393, the gattc_evt_read_rsp does occur.

The ATT MTU size is updated by calling adapter.att_mtu_exchange(conn_handle, mtu): corresponds to sd_ble_gattc_exchange_mtu_request.

[Sigurd]

Hi,

I'm a bit surprised that it worked with 493, the file connectivity_4.1.1_1m_with_s132_5.1.0.hex is AFAIK compiled with NRF_SDH_BLE_GATT_MAX_MTU_SIZE set to 250.

How does the ATT MTU Exchange Transaction in the sniffer log looks like ?

I compiled a version with support for MTU at 512: 8156.test.hex

Do you see the same issue with test.hex ?

[guti]

Hi,

ok, so I retried with the connectivity_4.1.1_1m_with_s132_5.1.0.hex and still came to the result that it is possible to set the ATT_MTU to 493.
The ATT Exchange MTU Transaction shows:
- ATT Exchange MTU Request Packet with Client RX MTU 493
- ATT Exchange MTU Response Packet from our peripheral with 512.
Unfortunately I can not upload the file ("The file or URL is not allowed to be inserted.")

With the test.hex it is possible to set MTU to 512.

I will continue investigating this as soon I am back in the office on 10th of November.

Thank you very much for your feedback so far.