Some Android Devices can't complete Bluetooth connection, getting disconnected after 5 seconds due to 0x08 timeout #9
Comments
|
Has anyone on Raspberry Pi team been able to replicate this issue? |
|
Well I haven't - the fact that I don't own a Pixel 6 Pro made it harder to investigate, and the issue was overtaken by others before I got round to borrowing one. |
|
The listed kernel and BlueZ version are both old - we're on Linux 5.15 and BlueZ 5.55. Testing on a OnePlus 7T (running Android 11) with a 4B running current software works as expected. |
|
An S10 running Android 12 also connects to the current Pi 4 software. |
|
Just tested with some newer phones on latest release of Raspbian (Linux 5.15 and BlueZ 5.55). The following phones failed to connect via Bluetooth:
|
|
Does anyone have any leads on what might be going on here? I've worked on this quite a bit, and it seems to me like it might be a firmware issue since I have no been able to replicate it on other hardware. I'm happy to throw some engineering effort toward a fix if there's a solid direction. But, right now I'm still unable to pinpoint the root cause. |
|
Has there been any word on this? We actively sell a product that uses Raspberry Pi to handle Bluetooth, so we have had multiple customers unable to even get past initial setup because of this bug. Edit: I don't know if this helps at all, but all of the phones with issues seem to use the exact same BT/Wi-Fi chip: BCM4389 |
|
That's potentially useful information, but phone manufacturers don't seem to advertise which chips they use - I've only seen the Broadcom PR around the time of the S21 Ultra launch. The last time I tried to reproduce this problem using two borrowed phones, one of them didn't show the problem and the other didn't even detect the Pi, but I can ask around for new acquisitions. |
|
Has anyone tried with Pixel 7 maybe? |
|
My Pixel 7 seems to have the same issue 😢 |
Hi @pelwell, do you know if any progress was made on this? We have products on the market with users using an app to pair their device to WiFi, thanks to BLE. If they have an Android phone with the reported issue, the pairing process can't be achieved, which means that they can't use their product.. Thanksfully most of our customers have iPhones, but we can't give up the ones with Androids.. Please let me know if we could help in any way. |
|
Two tested phones - S10, Pixel 6 - connected without issue. I've repeated the test with a new service installation and the S10 - again, no problems - and cast the net wider for test devices. |
|
Didn't you say that on 1 of the 2 phones you borrowed, you weren't able to detect the Pi? |
|
That phone wasn't able to detect anything. |
|
The phones that I have had issues with are from the US. Are you using a phone designed for a different country? I wonder if there might be a different component causing the behavior difference. |
I can add that the Pixel 6 which did not work for me was configured for the EU (Germany). |
I'm in France, and this is the results I had:
|
The US version of the Galaxy S22 (unlocked) on Android 12 with newest firmware has been working for our team, so maybe a component can differ. Our Pixels earlier than the Pixel 5 work fine. Pixel 5 and newer can't connect. |
|
As luck would have it, a US visitor brought their Pixel 7, and for the first time I have a log of a failure to throw at Infineon/Cypress. |
|
I had some luck with BT firmware from murata-wireless/cyw-bt-patch@bed4497 and bluez 5.65. The device became visible to Pixel 6 and 7 and connectable only after I bumped the firmware version for our chip to one from the commit. Though it's only based on Cypress, so no clue if Infineon provides the exact same binaries. |
|
That commit doesn't appear to change the 43455 firmware. Do you mean the version of |
|
I took whatever firmware version was in the tree of the commit I mentioned linked to, which was/is the latest master at the time of writing this comment. |
|
I just tried that firmware and it fails the same for the loaner Pixel 7. |
|
Good news - we have a trial firmware from Infineon that allows the Pixel 7 to connect. It will probably take a few days for them to build the relevant change into an official release for us, but the end is in sight. |
|
I just tried a thing suggested by someone in the bluez team, which was rolling back to 1.2-4+rpt2, and it did solve the problem with a Galaxy S22 / Android 12! It was able to connect and exchange info with the CM4, which was impossible before. Any clue what could have possibly change since this version? (had the issue with both 1.2-4+rpt8 and 1.2-4+rpt9). |
Could you share the command that you used to downgrade BlueZ to that specific version? |
Unfortunately I'm not using a command, but Yocto to build an image with a specific version of bluez-firmware 😞 |
Same here. From some experiments, bluez 5.55 (dunfell) worked ok only with some old (like 2+ years old) version of the cypress firmware, but didn't work with the new. I've then tried 5.61 and 5.65 (kirkstone) which worked fine with the new firmware, but did not work with the old one. Also, switching the firmware+bluez I hit a problem with some Android phones defaulting to ATT MTU of 23 bytes (well 27). Before the negotiation would settle on 251 bytes IIRC. I actually suspect that the firmware contains some heuristic to pick the right/most compatible behavior depending on the version of the host contoller (bluez in this case). |
|
I did, and the md5sum seems to sync up. I have few things I want to test first. Previously, I had some luck when it set the MTU back down to 20. |
|
It worked on Pixel 6a (Android 13) and Samsung S21 Ultra (Android 13)! |
|
I'm puzzled why I'm not having the same, positive, experience with this firmware... What versions are y'all running? Here's what I'm working with on a Raspberry Pi CM4: $ bluetoothctl --version
bluetoothctl: 5.62
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"And, I'm still seeing this little guy in > HCI Event: Disconnect Complete (0x05) plen 4 #263 [hci0] 24.233041
Status: Success (0x00)
Handle: 64
Reason: Connection Timeout (0x08)
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 24.233073
LE Address: 6D:08:B0:C5:A3:B4 (Resolvable)
Reason: Connection timeout (0x01) |
|
Interesting. Do you have any success with the firmware update on a fresh Buster image? I believe that should come with bluez 5.50 instead, which might help. I know for me at least I've had trouble with newer versions of bluez, especially with NoInputNoOutput pairing, but that's an entirely separate topic. Anyway, here's what my 3B+ looks like: $ bluetoothctl --version
bluetoothctl: 5.50
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" |
|
@cspensky CM4 and Pi 400 both use the Synaptics 43456, which has different firmware (and a completely separate support system). Can you open a new issue - just a brief note saying that 43456 is also affected - so we can track it separately? |
|
@pelwell I'll happily file an issue and try to get that ball rolling (it's actually pretty urgent on our end). However, I'm a bit confused by which company is actual responsible for this chip. Would you be able to provide some insights on where the proper support ticket should be file? Also, here's what I'm seeing in my |
|
I meant open an issue here - it can link back to this one, but it will allow us to separate the two threads and close them independently. |
|
Infineon have given us an official release containing the fix. After initial testing it will be added to this repo, then added to future releases. In the meantime you can download it from here: https://drive.google.com/file/d/1mgj2sybw7wpSWSMXmlj_0i-z20NS85wd/view?usp=share_link Full disclosure - it's just arrived, and therefore is currently completely untested by me. Installation instructions: and to revert: N.B. If you've followed these instructions before for the test firmware, be careful not to overwrite your good backup. |
|
BCM4345C0_003.001.025.0190.0382_RPI_3P.hcd firmware seems to be working okay with my Pixel 6, which was not working previously. Phone: Pixel 6 |
|
Thanks for the feedback! |
|
@pelwell any idea if the CM 4 firmware is in the works? I opened a case with Infineon yesterday, but it sounds you already have an active case with them. |
|
I've not had a response from Synaptics on my case yet, but I was able to pass on some more detail about the problem from from Infineon, so hopefully it shouldn't take so long. |
|
It still works on my Pixel 6a (Android 13) and Samsung S21 Ultra (Android 13)! |
Original rirmware name: BCM4345C0_003.001.025.0190.0382_RPI_3P.hcd See: #9 Signed-off-by: Phil Elwell <[email protected]>
Original rirmware name: BCM4345C0_003.001.025.0190.0382_RPI_3P.hcd See: RPi-Distro#9 Signed-off-by: Phil Elwell <[email protected]>
|
@pelwell having similar BLE connection issues with some BLE remotes with PiZeroW (original not Zero2): any chance Infineon would apply similar fix to their other parts? Thanks |
|
I'll raise it with them - they should know enough to be able to fix it (or say that it isn't possible). |
|
@macmpi Could you capture a btmon log (text output or the binary file written by |
|
Sure. Give me a few days to get hold/rebuild the affected setup (device used for sth else currently). |
|
There's another case open with Infineon. I'll let you know if they demand logs. |
|
I have limited access to a suitable test phone, but trying it now on a Zero W (BCM43438-based) it worked for me. |
|
So - I'm not anything to do with raspi dev, but I'm an Android App developer for an app that uses BLE to transfer blobs of data from Android to Device and back (bytes from say 10 bytes up to 400 bytes at a time, depending on application.) The Samsung BLE issues are well documented - https://forum.developer.samsung.com/t/samsung-android-10-ble-connectivity-regression/509/101 Here is some info I have gathered. The issue all boils down to MTU, as others have guessed. So - we have a range of test phones. A lot of Pixel 3a's on Android 10 - 12, a few Pixel 6a's, various Samsung S series (S9+, S10, S21), at least one Samsung A series (can't remember the exact model, possibly A30) and a number of S and A series tablets. All of the Samsung devices on Android 10 and above have a very similar issue with MTU - if you set the MTU as something that is not a multiple of 23, they will drop the connection on the first outgoing transfer. The Pixel 3a will support right up to 517. The Samsung devices seem stable above 230 and below 517 (so long as it is a multiple of 23), but I've stuck with 230 as is falls in to the magic multiple of 23 and also is below the UBLOX controller limitation we have for one of the devices. The important key fact here is that we actively request an MTU of the given value, Android accepts the request and then the data we receive is in blocks up to the size we requested, less the BLE header (~3 bytes.) So - under the hood the controller might still be sending data in small blocks, but the transfer is way, way faster than sending 20 byte blocks, so I don't think that is what is happening. The speed the end device thinks is set is the MTU we requested also. As I alluded to, until recently, I was unable to push the Samsungs above 23 (so ~20 bytes of data, and ~3 bytes of BLE header.) The epiphany happened when I read this article: https://punchthrough.com/maximizing-ble-throughput-part-2-use-larger-att-mtu-2/ (edit: and this one too https://punchthrough.com/ble-throughput-part-4/ ) Somewhere near the bottom it says "Using ATT_MTU sizes that are multiples of 23 bytes or (Link Layer Data Field – L2CAP Header Size(4 bytes)) is ideal." and that is how I hit on the divisible by 23 realisation. It works - and I got the Samsung devices up to close to 517 using that (~512 I think.) The Pixel 6a is a different story. A sad one. I can't currently convince it to go above 23. This is what led me here, looking for anyone else with this issue and to see if there was a magic number for the MTU. In my software I basically need to trawl what the Android phone Manufacturer and Model is and create a blacklist. That probably won't help you guys. If anyone can work out how to convince a Pixel 6a to allow and use a connection with an MTU over 23, I'd definitely eager to hear your solution! |
|
@pelwell is this pulled in to main build now? Or still just the testing firmware from the above comment? |
|
The 43455 update is packaged. The 43456 update was merged later and hasn't yet been packaged. @XECDesign ? |
|
I am seeing issues that are very similar to those reported here. Unfortunately, the issue is arising in a rpi 3b+ which is embedded in a deployed prototype hardware device which I don't have great access to for debugging. Basic question (linux not my forte): if I'm using a raspbian lite install, say 2 months old, is the BCM firmware patch you speak about in this thread likely to be there already, or must I patch it myself per above instructions? |
Yes - you can confirm by running the following and comparing your results with these: |
|
Thanks @pelwell. I confirm that I have the patch. Actually, however, having asked the question, I then realised that I have disabled the onboard bluetooth on the pi in question (I use this dongle https://www.amazon.co.uk/dp/B09MZ8715D?psc=1&ref=ppx_yo2ov_dt_b_product_details). The issues I am seeing are suspiciously similar though. Every device I have personally tested works, but then one of the consumers of my hardware (a sports scoreboard) using a pixel 6 pro was seeing repeated disconnects after 5-10 seconds. I'll have to try and get my hands on a pixel 6 pro somehow and debug. |
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:
I have 2 raspberry pi's running 2 different distros without any modifications and a sample app from the BlueZ study guide for Linux:
Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7lLinux raspberrypi 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/LinuxOn 4.19.97 the connection works without a problem.
On 4.19.118, the device connects and after 5 seconds it gets disconnected.
I am looking at these 2 versions as an attempt to narrow the issue to where it seems to start happening.
The main differences between 4.19.97 and and 4.19.118 in regards to Bluetooth
4.19.17:
4.19.118:
Steps to reproduce the behaviour
sudo apt-get install python-dbussudo systemctl stop bluetooth$ grep Exec /lib/systemd/system/bluetooth.servicesudo /usr/lib/bluetooth/bluetoothd -d -nsudo python server_advertisement.pyThe client will connect, attempt to discover services and after 5 seconds of inactivity the device will be disconnected.
4.19.17 Logs from Android Pixel 6 Pro - Successful connection 👍
btmon:
bluetoothctl output
journal output including bluetoothd logs
Client nRF Logs (timestamp from another run)
4.19.118 Logs from Android Pixel 6 Pro - Failed connection 👎
btmon
journal output including bluetoothd
nRF Client log:
Not every BLE connection fails to 4.19.118, below are btmon logs from connections from iPhone 6s, Android Pixel 1 and another Raspi connecting via bluetoothctl.
4.19.118 Logs from Android Pixel 1 - Successful connection 👍
btmon
Journal:
4.19.118 Logs from iPhone 6s - Successful connection 👍
btmon
journal with blutoothd logs
4.19.118 Logs from Raspberry Pi - Successful connection 👍
btmon:
bluetoothctl
journal
PS: I have reported a similar issue to the Linux Bluetooth Kernel, but that issue seems to be related to the Ecred flow. The workaround to enable the ecred kernel option moves the process along, but still fails during connection in a few instances. @pelwell
The text was updated successfully, but these errors were encountered: