nFR Connect unable to read a characteristic of length MTU - 1 (22 bytes) on iOS

[brianreinhold]

The tag options did not include just nRF Connect as an option so I picked something that had nRF Connect in it. This issue has nothing to do with the SDK.

This is a question of whether the client (iOS) or the peripheral (a health device) is wrong. When reading the reg cert data list characteristic of length 22 bytes on iOS a dialog pops up saying 'read not long' and no value is returned.

On Android, doing a read with the same device (but not nFR Connect but my application the read succeeds. My application also fails on iOS the same way nRF Connect fails.

So who is wrong? Looking at the spec there appears to be two solutions for the same situation on the peripheral side when the length is exactly equal to MTU-1.

• Return error 'read not long'
• Return success with value 0

The first one fails on iOS and the second one succeeds. On Android both succeed. This appears to be a client (iOS) issue. Can anyone back me up on this?

[Kenneth]

Hi,

22bytes was a bit odd number, maybe the error is somehow related to the max allowed MTU size if Data Length Exention (DLE) is not used?

When DLE is not used, then the max allowed MTU is 20bytes, ref for instance: 
https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/

"The MTU value affects the amount of overhead data (specifically the ATT header which is 3 bytes). The minimum ATT MTU allowed is 27 bytes. This allows a max of 20 bytes of ATT payload (3 bytes are used for the ATT header, and 4 bytes for the L2CAP header)."

I am thinking there may be something related to the above that cause Android and iOS to behave differently, maybe one throw an error while the other workaound it in some way. Is the max length of the characteristic 22bytes? Is DLE used here?

It would be interesting to get an nRF sniffer log of Android vs. iOS in this case and nRF Connect vs. your application, to check the actual commands and data on the link. Are you able to provide 4 logs by using nRF sniffer?

https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le 
https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/intro.html 

Best regards,
Kenneth

[brianreinhold]

This is a read, not an indication/notification. And it works fine on Android. The device sending the error does not support the newer versions of Bluetooth. That should have nothing to do with this issue.

The question I am asking is are you aware of this problem on iOS (with nRFConnect or any other client)?

Who is wrong? The device or the client?

[Kenneth]

I am not aware of any specific problem, I would assume the problem is on iOS (anywhere from app to link layer), but sniffer logs would help.

Kenneth

[brianreinhold]

The problem is not with nRF Connect, it is a slave to iOS. What surprises me is that a company as big as Apple could have an issue with something like this...and that no one seems to know about it.

But as far as you are concerned, the device (server) is behaving correctly and Apple is in error. iOS should not discard the read but give the application the 22 bytes obtained in the first read.