Repository navigation
Upstream draft: esp32 BLE reports the MTU exchange before the connection - #11
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A draft issue for micropython/micropython, for Brad to post; nothing has been posted. It's in
docs/upstream/esp32-ble-mtu-before-connect.md, beside the WebREPL Ctrl-C draft.What it says: on the esp32 port, a central that exchanges the MTU as it connects (Windows always does) gets
_IRQ_MTU_EXCHANGEDabout 60 ms before_IRQ_CENTRAL_CONNECT. aioble then drops the MTU, and the board sends 20-byte notifications on a 247-byte link. The cause is in the IDF's NimBLE: it reports the connection only after reading the peer's version and features, while ATT is already answering. The NimBLE the other ports use (mynewt 1.4) reports the connection at once.The repro in the draft was run today: Windows + bleak against an S3 showed MTU-first 5 times out of 5; a second S3 as the central showed the normal order 5 times out of 5, which is why board-to-board tests never caught it.
We carry no firmware patch for this. bledev works around it in Python (PyDevices/pydevices#81). The draft offers either fix, in the NimBLE binding or in aioble, and doesn't promise a PR beyond offering one.