Skip to content
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 l2cap segmentation error in concurrent subscription #28

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

davidalo
Copy link

@davidalo davidalo commented Apr 20, 2022

We are having some issues when we subscribe to different characteristics in the same server and get data from them simultaneously, we are getting corrupted packages.
After some research we discovered that the problem was in l2cap layer, segments were being mixed and this was causing reassembly inconsistencies.
When l2cap layer needs to fragment the packets, it seems this layer does not support unordered segments. With this patch we ensure these segments are sent in order for each upper-layer's packet.

As an example, we need to send two packets of 135 bytes, so l2cap layer needs to fragment it in 5 segments of 27 bytes.

Packet 1 starts being sent, so l2cap layer starts sending segment 1,2,3
In the middle of that transmission, Packet 2 is requested to be sent, so its segments start being sent: 1,2,3, etc.

On the other side, we would receive something like (P1=Packet1, P2=Packet2):

P1.1, P1.2., P1.3, P2.1, P1.4 -> which is reassembled as Packet1 but it's not correct.
P1.5, P2.2, P2.3, P2.4, P2.5 -> which is reassembled as Packet1 but it's not correct.

With this patch we aim to solve this. See orca-io@edd7ec2

Jon-Bright and others added 11 commits July 1, 2021 16:53
This checks that the request is valid, replies to the other side in any event (with an accept/reject) and, if accepted, also updates the connection parameters to HCI.
…o copy the data buffer.

The bug that otherwise happens is:
1. HCI.mainLoop gets a byte buffer, reads into it, calls handlePacket
2. handlePacket calls handleL2CAP, which unmarshals into an aclData. This aclData references the original b slice
3. handleL2CAP adds the aclData to a channel
4. handlePacket returns the buffer to the pool
5. Repeat from 1, getting the same buffer _while the aclData referencing it is still in the channel_
Triggering this needs a relatively high data rate, but was possible repeatedly for me with a Polar H10.
…rcap/gatt.

NB: I still intend to drop this fork once I've got everything that I want working and any resulting pull requests to bettercap are merged.
…callee is checking for six bytes, but nobody was checking for 5 bytes :)
…ent sending in l2cap.conn.write to avoid sending unordered segments for the same l2cap channel
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants