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

ignore l2cap signal #17

Open
anisbhsl opened this issue May 29, 2020 · 4 comments
Open

ignore l2cap signal #17

anisbhsl opened this issue May 29, 2020 · 4 comments

Comments

@anisbhsl
Copy link

I am running a custom service for BLE device. While trying to connect my mobile app with GATT server, it throws following log:

ignore l2cap signal:[ 06 00 05 00 13 02 02 00 00 00 ]

No communication is further carried out after this log message appears.

@anisbhsl anisbhsl changed the title ignore l2cap signal:[ 06 00 05 00 13 02 02 00 00 00 ] ignore l2cap signal May 29, 2020
@MoralCode
Copy link

I believe this is likely to be data of some kind that results from the specific devices/usecases you are trying to use this gatt library to emulate (i'm working with basically the same devices, Concept2 indoor rowing machines and their bluetooth-capable, PM5 model monitors)

I suspect this is something that happens during/prior to the connection process as I got this error when trying to use the official app against your emulator. I was also able to replicate this with my own custom-made app, although i still have yet to narrow down specifically what is causing this signal.

More research definitely needs to be done to definitively place blame on this gatt library as opposed to either a higher, application level issue, or some lower level l2cap dependency or something

@MoralCode
Copy link

MoralCode commented Dec 19, 2022

further investigation reveals im wrong in a number of ways.

  1. packet analysis (using a similar method to the instructions on the openscale wiki) reveals that the bytes in question (06 00 05 00 13 02 02 00 00 00 ) seem to appear within short/low level l2cap control/signalling packets, not the kind i would expect to contain data specific to the Concept2 machines
  2. this log message seems to not mean much other than "hey we got a thing that we dont yet know how to process" according to the source code in this repo. it also seems like PR Implement processing of L2CAP Connection Parameter Update Requests. #21 has been opened to fix this but hasnt yet been merged.

overall it seems like this signal is just a basic part of connecting to a device (which, based on my research, is one of the responsibilities of the l2cap layer of the bluetooth stack) that this library doesnt yet handle.

@anisbhsl
Copy link
Author

It was super difficult to fix. I don't remember much of the context now. Unfortunately, there isn't much activity around this library anymore.

@MoralCode
Copy link

do you have a fix that you implemented on your local machine that you could push to a fork? id be curious to see how you solved it.

I also noticed the lack of activity around this library, so I've been working on my own fork that merges in the open PR's on this repo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants