Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

RE: Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

Hung Bui — Fri, 06 Jan 2023 10:03:37 GMT

Hi Ricardo,

You are right. The requirement is that MTU exchange is once per client. Meaning there could be up to 2 MTU exchanges, initialize by the client on each side.

However, there is another requirement from the spec:

This is also reflected in our API:

In this case, the phone replied to the nRF52 with Server RX 230 in the earlier exchange and then on the 2nd exchange it request with client RX = 23 which is violating the spec.

From what I can see in the trace, the softdevice still operate normally even with this violation that it still reply with correct read response (fragmented and then re-assembled) :

My understanding is that the phone had an issue interpret the response and gave GATT error.

I understand your concern that if you have no control over the peer there could be a chance that this issue may rise and you want to have a way to check if the peer have received the data correctly. As far as I know there isn't a way to have a confirmation of a read. You can have a confirmation when you do a write (write request or write with response) but not with a read.

What you can do is either make a server on the phone and write data from the nRF52 to the server on the phone instead of a read. Or if you want to keep it as a read, you can have an extra characteristic on the nRF52 that the phone can write a receipt when it managed to read. It can be a hash of the data of the read for example.

RE: Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

RRWC — Thu, 05 Jan 2023 20:37:08 GMT

Hello Hung Bui,

I'm sending the sniffer trace as requested. This file contains pre-connection advertising and all data shown in the screenshots (same trace).

devzone.nordicsemi.com/.../BLE_5F00_23MTU_5F00_read_5F00_fail.pcapng

Regarding the MTU exchange, I'm still a bit confused. The specification says that the client should only send the MTU request once per connection. However, it was the nRF52832 that actively requested the MTU change on the first change (to 230 Bytes). Wouldn't that allow the phone to request to change the MTU once during the connection even if the device already requested it once? Just for the record, actually in my app the phone is the Client (as usual the data is on the peripheral, the nRF52832). The use of the terms Client and Server in this case leaves room for ambiguous interpretations in my opinion. I would appreciate it if you confirm that the MTU should only be exchanged once regardless of the side starting the MTU update request, although this is just to better understand the specification. I don't intend to change it more than once in my application, I will explain more of my test case below.

Regarding my test case, the ideal condition is when the MTU is 230 bytes and Data length is 234 bytes. This is what my device will request. However, these values also depend on what the phone and its BLE stack decide. What I really want to test is if data transfer, internal data update and overall device operation are OK in case of 23 byte MTU and 27 byte data length being selected by the Central. I have no need nor intention to explicitly change the MTU to 23 bytes, but I would like to check compatibility with phones selecting this MTU even when the peripheral configuration allows a higher MTU.

Extending a little bit this explanation, this is a final product test (not a prototype). We have more freedom and control over the nRF52832 side so we prefer to fix bugs in the firmware side even if they are caused by wrong implementation in the other devices stack to ensure wide compatibility. However, our tests use the firmware as close to the final version as possible (exactly the same for most tests). We want to test that the final firmware version will correctly handle the 23 byte MTU request from the master with the current configuration and not to change the configuration on the nRF52832 side to test and send a different configuration to the field. Also, if the phone is able to send this request once even after the device changed the MTU before we'll look for a way to keep things working even in that scenario, if possible.

Thank you in advance,

Ricardo.

RE: Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

Hung Bui — Thu, 05 Jan 2023 10:08:10 GMT

Hi RRWC,

Thanks for the detailed information. Could you please send us the sniffer trace files ?

I did a quick test here and found a similar issue. So that if the MTU was 23 bytes at the initial phase and the phone doesn't request a change to larger one (247 in my case) the read worked fine. It's what I observed in my first reply where I give an example of 100 bytes read and with the NRF_SDH_BLE_GATT_MAX_MTU_SIZE set to 23.

In your case you set NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 230 I assume. And then in nRF Connect app you request an ATT MTU of 23.

The problem of this is that the ATT_MTU request should only be sent once in a connection. In your case, the phone actually request it twice. First when connected (automatically request to 230 bytes) and then you in the app request a 2nd one with 23 bytes.

This violate the Bluetooth Spec:

In the code for NRF52 you can find the same requirement :

You can't call sd_ble_gattc_exchange_mtu_request() twice in a connection.

So from my point of view it's a wrong implementation in the phone's BLE stack that it allows att exchange to be requested twice.
Could you describe your use case on why you want to change the ATT MTU back to 23 bytes ?

Please be aware that ATT_MTU can only be exchanged once, but the Data length extension can be changed multiple times. If you want to limit the size of the on air packets you can change the data length instead of the ATT_MTU.

Another note is that Data length usually = ATT_MTU + 4 . This is why you see 27 bytes data length when you request 23 byte ATT MTU. It's due to the 4 bytes overhead on link layer.

RE: Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

RRWC — Wed, 04 Jan 2023 20:40:41 GMT

Hello Hung Bui, thank you for your reply.

I am in fact using NRF Connect app to test. All tests reported above where performed using the NRF Connect. This makes it easier to identify if the problem is on the nRF52832 side or on our end user APP.

I performed a sniffer trace as requested. I'll walk through the normal behavior and the problem case described earlier using screenshots from the sniffer trace and from nRF Connect.

Normal Behavior

After the connection everything runs smoothly. The screenshots bellow show normal operation with parameters automatically negotiated between nRF52832 and a Samsung Galaxy S21 (same results with a Samsung Galaxy M51 and an Asus Zenfone Max pro M1)

Connection establishment and parameter negotiation

Below are screenshots of all parameters that have been automatically negotiated right after the connection was established.

[Slave] Connection parameter update request. Parameters accordingly to the desired parameters informed in the first post.

[Slave] Request data length change to 234 bytes

[Master] Reply data length update request

[Slave] Request MTU change to 230 bytes

[Master] Reply MTU update request

[Master] Data length update request. Not sure why the master decides to renegotiate data length, but I believe this is not related to the problem as everything continues to work normally after this.

[Slave] Request PHY change to 2 MB

[Master] 2 MB PHY accepted

[Slave] Reply data length update requested by the master

[Master] Reply parameter update request

[Slave] Parameter negotiation request. Not sure why it happens again here, but the parameters are set as desired.

[Master] Reply parameter negotiation

[Master] Connection parameters accepted

Data transmission with MTU 230 bytes

Shortly after the above negotiations ended I read some characteristics.

[Master] Read 7 byte characteristic

[Slave] Send 7 byte characteristic data:

[Master] Read 512 byte characteristic

[Slave] Send successfully 512 byte characteristic

nRF Connect side:

In these nRF Connect logs you can see almost all the steps shown from the sniffer side so far. Everything works.

Changing MTU to 23 bytes

Now a command is issued from nRF connect to change the MTU to 23 bytes. This is done using the "..." menu in the upper right corner. With this command, the master will request an MTU of 23 bytes.

Note that previously the slave was responsible for requesting the MTU change to 230 bytes. You said the MTU can only be changed once per connection, but I believe each side can request the change once per connection (at least it seems that way considering the behavior, I really don't remember exactly what the BLE spec says about it right now) . In fact, after requesting a new MTU using nRF Connect you will not be able to request it again on the same connection.

[Slave] Reply MTU request from master

[Master] New data Length request. This is not a command directly issued via nRF Connect. Probably the Android BLE stack decided that 27 bytes make smore sense with a 23 byte MTU.

[Slaves] Reply data length request

Reading characteristics with 23 bytes MTU and problem

After the above negotiation, characteristics a few bytes long can be read normally, but longer characteristics cannot.

[Master] Read 7 byte characteristic

[Slave] Successfully send 7 bytes characteristic data

[Master] Try 512 bytes characteristic read

[Slave] 512 bytes characteristic data is partially send. Data never displayed in master.

[Slave] Last data packet error detail

The connection remains active and it is even possible to read the data of the characteristics, although if there is too much data the error will be repeated.

Error in nRF Connect side

Below you can see the steps that led to the error in the nRF Connect log. After the first error, new readings are performed, with success in the case of short features and with error in the case of long features.

As far as I know the BLE stack should automatically split the data and send it even using the 23 byte MTU and 27 byte data length. However, for some reason, only characteristics containing only few bytes of data are being transferred. Can you help me understand if there is something not configured correctly or where is the problem?

Regarding the read with authorization question, currently the device is notified when the reading starts. However, using the above example, I have no information about the failure to deliver the data. Is there an proper callback to confirm that all data registered in the characteristic were successfully delivered?

Thank you in advance,

Ricardo

RE: Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

Hung Bui — Thu, 29 Dec 2022 14:50:03 GMT

Hi RRWC,

Could you try to capture a sniffer trace ? Which phones did you use to test ? Could you use NRF Connect app to test ?
Error 133 is a generic error , so it doesn't tell much.

Please note that the MTU can only be updated once. If by default it's 23 and changed to anything else, you can't change it back to 23.
I did a quick test here and it seems that it worked fine with the ATT_MTU of 23. (NRF_SDH_BLE_GATT_MAX_MTU_SIZE)

You can see that the read blob was successful and the length was 23 bytes on each packet.

I attached here my quick example with a characteristic with 100 bytes length initial value. Please replace the ble_nus.c of the ble_app_uart example. If you do a read from the phone on the TX characteristic it should give you 100 bytes array.

devzone.nordicsemi.com/.../0602.ble_5F00_nus.c

Regarding your question about how the application aware that the peer has read the characteristic. You can implement read with authorization. Please see here. You'll need to use is_defered_read when declare the characteristic.