Android Pixel 6 Pro unable to complete Bluetooth Connection Reason code 0x08 and Wrong link type (-22) #4847
Comments
|
Running the newest Kernel, there's a new log message that helps narrow the issue: This commit refers to fixing the issue with the 0x17 which is the Enhanced Credit Based Flow Control |
|
Without changing the configuration, do other Android devices connect? If so, are they also attempting BLE connections, or is BLE the common factor in the failure cases? |
|
Wait - I see you have successful Pixel 1 and iPhone 6 logs there, both of them using BLE, which answers both my questions. The patch you link to is interesting, but it is already in the newest kernel and the problem clearly isn't fixed. Time to expense a Pixel 6 Pro? |
|
I was able to replicate this issue with these phones:
These phones work without an issue:
|
|
Thanks for the confirmation. I was slightly joking with my previous comment re: expenses, but investigating this issue is going to depend on getting hold of one of the devices that shows the problem. |
|
:) I hope you can find one of these devices. Here is something else that could help to narrow this issue. Mod info: Then by changing the content to Here are some notable differences: Changing the value to Y (enabling ecred) when the phone successfully connects, there are no warnings on the journal, and the btmon shows a valid RX and TX for the Enhanced Credit Connection: There are a few RX/TX about However, even with this configuration, sometimes the connection will fail. There are not visible errors on the journal. The L2CAP for the Enhanced Credit Connection seems to happen but the device still get disconnected with a timeout. I wonder if this is a different issue altogether that also leads to a 0x08 disconnect, this time not due to the disabled ecred param. Here are the full logs for completeness when the ecred is enabled but the client connection fails: journal with bluetoothd debug statements: The client starts a Please let me know if there is anything I can do to help. |
|
We are also encountering the exact behavior described in this issue and RPi-Distro/bluez-firmware#9. The only difference for us is that enabling ecred deos not seem to help. Would love to see it fixed, and happy to help. Is there anything I can do to help move this along? |
|
I just left a comment on the link above. |
|
@hando-gomes Sorry, not seeing a new comment on RPi-Distro/bluez-firmware#9. Were you referring to another link? |
|
I'm seeing the same thing on my end. Has anyone made any progress on this? It seems to be hanging indefinitely after characteristic write in my case Apr 20 08:35:31 chads-demo-reader bluetoothd[5072]: src/device.c:gatt_debug() Write Complete: err 0
Apr 20 08:35:36 chads-demo-reader bluetoothd[5072]: src/adapter.c:dev_disconnected() Device 6D:20:DB:B9:A7:76 disconnected, reason 1And I see it time out in > HCI Event: Disconnect Complete (0x05) plen 4 #247301 [hci0] 50873.494976
Status: Success (0x00)
Handle: 64
Reason: Connection Timeout (0x08)I have seen in connect successfully in very rare cases and after a lot of failures. Is it possible that it's the BLE parameters that need to be tweaked for these phones? I know Apple has very specific recommendations for iPhones (https://developer.apple.com/library/archive/qa/qa1931/_index.html) |
First this is against the spec since there is way too many Source CID: [Edit] This is a problem on btmon, it is not accounting the frame correctly causing 2 extra Source CIDs to be printed. It also makes no sense to limit the MTU to 256 for EATT when for ATT the MTU is 517. |
|
After some serious digging I've narrowed it down quite a bit. The issue seems to be with negotiating the MTU (at least in my case). If I remove the following line from my code, it seems to work as expected. gatt.requestMtu(512);The I believe this to be the same as RPi-Distro/bluez-firmware#9 |
|
Just to follow up. My previous fix only seems to fix part of the issue. After a few days, the phone seems to fail to connect again. Has anyone had any progress on this? |
|
I am experiencing the exact same issue. Using a Pixel 6 (non Pro, Android 13 Beta 4), I get the following messages running I tried raspbian (both bullseye and buster), ubuntu server and even manjaro (using bluez 5.64-2), but as the issue seems to be located in the kernel, it does not make a difference. The manjaro journal log looks like this: Did anyone find a solution/workaround? |
|
I finally got it working, but only with an external USB bluetooth dongle. I had a random one lying around, plugged it in, disabled the integrated bluetooth adapter using |
Which dongle did you use? |
It's a TP-Link UB400, but I would guess that other dongles would also work. |
|
Another workaround on the Pixel 6 with Android 12 is to enable Gabeldorsche Bluetooth in the phone's developer settings. Unfortunately, it seems that Gabeldorsche is going away with Android 13 from what I can tell, so this may not work for very long. |
Thank you so much @ln-12, i just bought the TP-Link UB400 you mentioned and i am able to connect my OPPO1920 to the pi |
|
Would like to confirm that some newer phones on latest release of Raspbian (Linux 5.15 and BlueZ 5.55) are still not working. The following phones failed to connect via Bluetooth: Pixel 6, Android 12 It appears that the new Gabeldorsche Bluetooth stack was widely adopted in Android 13, but it didn't fix the issue. Perhaps the stack wasn't entirely adopted yet because it previously allowed my Pixels to connect when I enabled Gabeldorsche in Developer settings. |
|
I am still having issues on my pixel 6 with android 13. Would love some
insight on a long-term fix.
…On Wed, Oct 5, 2022, 9:10 AM Austin Anderson ***@***.***> wrote:
Would like to confirm that some newer phones on latest release of Raspbian
(Linux 5.15 and BlueZ 5.55) are still not working. The following phones
failed to connect via Bluetooth:
Pixel 6, Android 12
Pixel 6, Android 13
Pixel 6 Pro, Android 13
Samsung Ultra 22, Android 12
Samsung Ultra 22, Android 13
It appears that the new Gabeldorsche Bluetooth stack was widely adopted in
Android 13, but it didn't fix the issue. Perhaps the stack wasn't entirely
adopted yet because it previously allowed my Pixels to connect when I
enabled Gabeldorsche in Developer settings.
—
Reply to this email directly, view it on GitHub
<#4847 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVJBSJ4PQXSALCKF6GMQGLWBWD6DANCNFSM5MZMCSQQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Locking thread to stop the cross-posting. Please use RPi-Distro/bluez-firmware#9. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
A few Android devices are unable to successfully establish a bluetooth connection to the Raspberry Pi 4.
The devices connect, and after 5 seconds, it is disconnected with a timeout reason code 0x08.
The following Android devices have shown this behavior:
After connection, this message can be seen in the journal and dmesg:
raspberrypi kernel: Bluetooth: Wrong link type (-22)The issue seems to be that during the discovery phase something goes wrong at the kernel level and the the device and raspi never completes the discovery phase. Bluez never receives the request for discovery and therefore the connection is closed due to timeout.
The log can be traced back to here:
linux/net/bluetooth/l2cap_core.c
Line 6382 in 2697f74
Steps to reproduce the behaviour
Download the Bluez study guide for Linux and transfer the code to the pi
Install python3-dbus
sudo apt-get install python3-dbusstop the bluetooth service
sudo systemctl stop bluetoothVerify the path for the bluetoothd ExecPath:
$ grep Exec /lib/systemd/system/bluetooth.serviceRun bluetooth service manually in debug and detached mode:
sudo /usr/libexec/bluetooth/bluetoothd -d -nRun the sample code
sudo python server_advertisement.pyLaunch nRF Connect app on one of these Android devices:
Scan and connect to raspi
The client will connect, start discovering services and after 5 seconds on inactivity the device will be disconnected.
Device (s)
Raspberry Pi 4 Mod. B
System
Logs
Logs when Android Pixel 6 Pro connects and then is disconnected.
Journal
btmon:
bluetoothctl
nRF Connect (Phone log)
Additional context
The same test was performed with these 2 other phones and the connection is successful and no warning about
Bluetooth: Wrong link type (-22)is output.Journal logs for Pixel 1 device:
Journal logs when connecting with iPhone 6S
The text was updated successfully, but these errors were encountered: