-
-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
characteristic larger than 253 bytes freezes the onRead callback #912
Comments
this is on an esp32 S3 I should have mentioned. I tried with two separate GATT handlers (on the linux/raspberry pi side) and same result. I swapped out NimBLE for BLEDevice (ArduinoBLE) and the problem went away so it seems certainly related to NimBLE As a side note I get about 50% more throughput with the ArduinoBLE implementation. |
Thanks for reporting this. The issue appears to be that the client is using a normal read rather than a long read. There is an unfortunate situation with the NimBLE stack itself where the
This is likely due to the MTU being half the size, increasing it to 517 should fix it. |
Hmm.. using gattlib (which drives Bluez) I am using
gattlib_read_char_by_uuid(...) which does.. whatever it does. I'll see if
maybe I can set a flag on the connection object. Thx for taking a look!
…On Thu, Mar 13, 2025 at 8:56 PM Ryan Powell ***@***.***> wrote:
Thanks for reporting this. The issue appears to be that the client is
using a normal read rather than a long read. There is an unfortunate
situation with the NimBLE stack itself where the onRead callback would be
called successively for the same read operation when a characteristic value
is longer than the MTU -3, I have tried to handle this here via detecting a
long read PDU so that the application callback is only called once, if the
client instead send normal read commands and the characteristic value is
more than the MTU - 3 then the callback will not be called. Stuck between a
rock and a hard place with this one sadly, my suggestion is to increase the
MTU or if possible, use long read commands.
—
Reply to this email directly, view it on GitHub
<#912 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALIKA6J3CLDGYSEPFLRXJ32UISLPAVCNFSM6AAAAABY6ZVE42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRTGA2DIMZTGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
[image: h2zero]*h2zero* left a comment (h2zero/NimBLE-Arduino#912)
<#912 (comment)>
Thanks for reporting this. The issue appears to be that the client is
using a normal read rather than a long read. There is an unfortunate
situation with the NimBLE stack itself where the onRead callback would be
called successively for the same read operation when a characteristic value
is longer than the MTU -3, I have tried to handle this here via detecting a
long read PDU so that the application callback is only called once, if the
client instead send normal read commands and the characteristic value is
more than the MTU - 3 then the callback will not be called. Stuck between a
rock and a hard place with this one sadly, my suggestion is to increase the
MTU or if possible, use long read commands.
—
Reply to this email directly, view it on GitHub
<#912 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALIKA6J3CLDGYSEPFLRXJ32UISLPAVCNFSM6AAAAABY6ZVE42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRTGA2DIMZTGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
follow-up: upping the MTU I will leave it to you to close/defer this issue since there seems to be an underlying tension. |
Thanks for confirming, I have opened #913 to resolve this properly. |
from standard characteristic read example:
Just stumbled across this, It is possible I'm doing something wrong? but there seems to be something magical happening at the 253-4 byte boundary, I suspect an int8 being used with some kind of two-byte header? I have not looked at the source yet, spent too many hours already zeroing in on this problem.
The text was updated successfully, but these errors were encountered: