Difficulty connecting to BLE devices on specific adapter
Problem: difficulty connecting (timeout or not found) to BLE devices using internal bluetooth adapter.
When using the Mediatek MT7922 802.11ax with bluetooth 5.2 support I have trouble connecting to 3 different BLE devices. I'm running:
- Ubuntu 24.04, 6.11.0-17-generic
- Bluez
5.72-0ubuntu5 - bleak version
0.22.3 - python:
3.12.3
The devices are:
- P11 Smartwatch (running an nrf something)
- Colmi R02 smart ring (running BlueX RF03)
- Colmi R10 smart ring (running RTL8762)
I'm not trying to do anything particular complicated, just connect so that I can read/write some GATT characteristics.
Here's a minimal example I've used to see if the issue was the device being asleep or something else
import asyncio
import bleak
from bleak import BleakClient
async def main():
tries = 0
success = 0
while True:
tries += 1
client = BleakClient("70:CB:0D:D0:34:1C")
try:
async with client:
success += 1
print("Connection success")
except TimeoutError:
print("Timeout")
except bleak.exc.BleakDeviceNotFoundError:
print("not found")
print(f"{success} / {tries}")
asyncio.run(main())
This results in a mix of timeout and not found exceptions.
If I run the same script using a generic UGREEN USB bluetooth 4 adapter, I can successfully connect to all 3 devices consistently.
Here's the output of hciconfig , where hci1 is the USB adapter, and hci0 is the internal mediatek one.
hci1: Type: Primary Bus: USB
BD Address: 00:1A:7D:DA:71:11 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING
RX bytes:24125 acl:110 sco:0 events:847 errors:0
TX bytes:7005 acl:95 sco:0 commands:159 errors:0
hci0: Type: Primary Bus: USB
BD Address: 78:46:5C:01:23:70 ACL MTU: 1021:6 SCO MTU: 240:8
UP RUNNING PSCAN
RX bytes:19991554 acl:400 sco:0 events:393929 errors:0
TX bytes:556678 acl:306 sco:0 commands:3385 errors:0
I thought perhaps the issue was with BlueZ or the linux driver but if I use gattcat from bluer-tools (built on the official bluez rust bindings) I am able to connect and read attributes from all 3 devices using the internal Mediatek adapter. I think that helps isolate the issue to Bleak, since both are using Bluez/D-Bus and the same hardware.
One thing I do notice with gattcat is that it takes significantly longer to connect using the mediatek device compared to the usb one, so perhaps it's an issue with things timing out?
I've attached wireshark captures of the above script using both adapters, one successful, one not. One difference I notice is that the usb adapter receives LE Advertising Reports, where the internal mediatek one receives LE Extended Reports. I'm pretty new to bluetooth internals, so maybe that's just to be expected with Bluetooth 5+ adapters.
- https://cdn.tahnok.ca/u/working.pcapng
- https://cdn.tahnok.ca/u/broken.pcapng
Some ideas as an newcomer:
- difference in how bluez handles bt 5+ adapters, or other change in hci
- difference in the actual BLE protocol in 5?
- adapter is just slower, timeouts need to be longer?
- MTU something something?
I initially noticed this in my work on https://github.com/tahnok/colmi_r02_client where several people reported issues connecting.
Seems similar to https://github.com/hbldh/bleak/issues/1505
perhaps it's an issue with things timing out?
Did you try extending the default timeout in Bleak by passing timeout=30 or so to BleakClient()? The default is 10 seconds.
I get 403 error when trying to access the pcpng links. You can put them in a zip and attach them to a comment here on GitHub to make them easier to access.
I get 403 error when trying to access the pcpng links. You can put them in a zip and attach them to a comment here on GitHub to make them easier to access.
bleak_bug_pcaps.zip here's the pcaps, sorry I messed up some permissions when uploading them last time
Did you try extending the default timeout in Bleak by passing timeout=30 or so to BleakClient()? The default is 10 seconds.
I don't recall, I will try again when I have a chance
- difference in the actual BLE protocol in 5?
Looks like it could be. In the working example, it is receiving "regular" advertisements but in the not working case, it is receiving Extended advertisements which is something new in Bluetooth 5. The address you are looking for never shows up in the Extended advertisements, so I'm guessing it doesn't support that.
I haven't dug into BlueZ enough to see what makes it decide to use Extended advertisements or not when scanning, but there isn't any public API for controlling it that I have seen, so not sure what we can do about it.
The fact that gattool could connect to them implies to me there might be something that can be configured with BlueZ somehow, although I don't know what it could be
gattool doesn't use the D-Bus interface and requires admin privileges to have much lower-level control over the Bluetooth adapter.
Can you scan and see/connect to the device using bluetoothctl?
Another difference could be if it is a dual mode device and it is being detected that way. Or the tool just skips scanning and tries to connect directly.
Maybe same issue as #1728?