-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix intermittent BLE connection failures #23598
Conversation
1. Rename two BTP constants to match BTP_CONN_RSP_TIMEOUT and BTP_ACK_TIMEOUT from the spec. 2. Move the constants to BleConfig.h 3. Use BTP_ACK_TIMEOUT in both secure and unauthenticated session for ACK timeout calculation. Signed-off-by: Damian Krolik <[email protected]>
c716f14
to
7d3f5bb
Compare
PR #23598: Size comparison from e072098 to 7d3f5bb Increases (38 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, nrfconnect, psoc6, qpg, telink)
Decreases (7 builds for cc13x2_26x2, esp32)
Full report (40 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
PR #23598: Size comparison from e072098 to 326cbe1 Increases (49 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, nrfconnect, psoc6, qpg, telink)
Decreases (12 builds for cc13x2_26x2, esp32, linux, psoc6)
Full report (51 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
I also found |
@Emill The value in the spec seems to be a default if you have no better idea of what to set the value to, not a requirement. |
I don't know why the column says "Default" rather than something like "Value". Allowing implementations to choose custom timeouts would break the protocol: "The timer’s duration timer SHALL be defined as any value less than one-half the acknowledgement timeout interval. This ensures that on a healthy BLE connection, a peer will always receive acknowledgements for sent packets before its acknowledgement-received timer expires." If the peers select their own ack timeout, it could happen that one-half ack interval of one peer is longer than the full ack interval of the other peer. In that case the connection would be torn down when idling. Another section also hints that the timeouts on the two devices are "the same": "When a client sends a handshake request, it SHALL start a timer with a globally-defined duration of BTP_CONN_RSP_TIMEOUT seconds. If this timer expires before the client receives a handshake response from the server, the client SHALL close the BTP session and report an error to the application. Likewise, a server SHALL start a timer with the same duration when it receives a handshake request from a client." |
That seems like a problem that should get fixed in the spec, then... @robszewczyk |
BTP_CONN_RSP_TIMEOUT
andBTP_ACK_TIMEOUT
from the spec.BTP_ACK_TIMEOUT
in both secure and unauthenticated session for ACK timeout calculation.Fixes #23438