Setup
I'm trying read ~1500 bytes from a remote device over bluetooth GATT. I have my data at the ready on the remote device. I use one characteristic read request and rely on Read Blob Requests (RBRs) to handle the rest.
On the remote device I'm running a BlueZ 5.47 stack with a DBus application on top. I also enable btmon to monitor all incoming and outgoing data.
My client device is an iPhone 13 with a simple scan-connect-and-read swift app.
Behavior AS IS
I send one read request. The client device correctly reacts with two read blob requests.
After this, communication falls silent. On my client device I received the 552 bytes from the RBR sequence while there should be ~1500 bytes.
Btmon output can be found in attachments.
Expected Behavior
When I try reading with a Raspberry Pi 4 it all works fine and I correctly receive my ~1500 bytes.
When my host device returns it's value, the BlueZ stack notices it's too large to fit in the MTU size. It automatically truncates the value to the correct size and add a flag to the response package to indicate to the client there's more data waiting.
Upon receiving this response, if the client device detects the flag has been set, it caches the value, records its size and reacts with a RBR with an offset. The offset indicates how many bytes the client has received and from which position it wants to read its value.
In the Bluetooth spec, the RBRs are described as follows:
To read the entire value of an attributes larger than (ATT_MTU- 1) octets, the read blob request is used. It is possible to read the first (ATT_MTU-1) octets of a long attribute value using the read request.
Why does this only work for the first two requests?
Further Comments
This is particularly strange behavior since when I try writing ~1500 bytes, everything works fine. My host device receives one write request containing the full value.
As I said, reading the value only works partially. After the second RBR communication falls silent. But why?
Bugfix Request
Stigma online is that characteristic reads and writes are capped at the MTU size. That's where the blob requests (Read Blob Request, Prepare Write Request) come in play.
These requests allow us to send and receive larger chunks or data albeit in multiple behind-the-scenes requests.
I think many people are waiting for this change although they might not immediately know about it. A similar issue also arises on Android systems with the Fluoride stack. How soon can this be fixed?