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

[Help wanted] l2cap not working together with android #126

Open
Hero9909 opened this issue Sep 26, 2024 · 3 comments
Open

[Help wanted] l2cap not working together with android #126

Hero9909 opened this issue Sep 26, 2024 · 3 comments

Comments

@Hero9909
Copy link

i tried to run the code from the example on a esp32-wroom-32.

i adapted the code to let it build and run.

the GATT communication is working fine, but as soon as i try to swap to a l2cap communication an communication cannot be established

on the android side this error appears, the stacktrace indicates that android tries to read from the channel
java.io.IOException: read failed, socket might closed or timeout, read ret: -1

on the esp32 side nothing happens except when i connect the gatt first, but there is no reaction that the channel got a package

i tried different settings:

  • with gatt server in paralell
  • without gatt server in paralell
  • on android side brute forcing the channel psm
  • on android creating a gatt connection before connecting to l2cap
  • on android connecting with an increasing delay

im really curios whats the problem beneath it. (still i suspect myself for being the problem)

@lulf
Copy link
Member

lulf commented Sep 26, 2024

Thanks for the report. Trouble only supports connection oriented l2cap channels, are you sue it's trying to create those? You can try to enable these log lines, and maybe also some in host.rs handle_acl() to see if it tries to establish the l2cap channel.

@Hero9909
Copy link
Author

Thanks, thats a good direction, i tried that immediately. And i also researched twice that android supports that, see https://developer.android.com/about/versions/10/features#bluetooth-le-coc
https://developer.android.com/reference/android/bluetooth/BluetoothDevice#createL2capChannel(int)

also i found a hidden api that might be exactly what i need, there is also a feature request demanding access to this part https://issuetracker.google.com/issues/36976247 which was still not accepted. so i have two options now, going native on the android side and try to get as deep as i can, or build the channel stuff on the rust side.

things gotten a bit more wierd than i would like the to be, but i cannot enable trace log level as this breaks somehow the programm? on debug level it works, so i think the logging while running ble is just too much at some point.

so, i decided to add an example of whats happening. i need to fill in the rust side but android looks somehow okay to me, at least representable and testable. Everything is build to be manually to avoid timings or multiple builds for different scenatios.

ill play around a bit more and try to build a testable setup. after that ill hit here again, maybe the problem can be narrowed down more easily.

https://github.com/Hero9909/l2cap-example

@lulf
Copy link
Member

lulf commented Sep 27, 2024

Thanks, thats a good direction, i tried that immediately. And i also researched twice that android supports that, see https://developer.android.com/about/versions/10/features#bluetooth-le-coc https://developer.android.com/reference/android/bluetooth/BluetoothDevice#createL2capChannel(int)

also i found a hidden api that might be exactly what i need, there is also a feature request demanding access to this part https://issuetracker.google.com/issues/36976247 which was still not accepted. so i have two options now, going native on the android side and try to get as deep as i can, or build the channel stuff on the rust side.

things gotten a bit more wierd than i would like the to be, but i cannot enable trace log level as this breaks somehow the programm? on debug level it works, so i think the logging while running ble is just too much at some point.

I think that's probably the esp-hal logging a lot on the trace level. I've not tried it, but you should be able to finetune the logging targets to make it less spammy: https://crates.io/crates/esp-println/0.6.0

ESP_LOGTARGETS if set you should provide the crate names of crates (optionally with a path e.g. esp_wifi::compat::common) which should get logged, separated by , and no additional whitespace between

Add that to this section

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

No branches or pull requests

2 participants