Software caused connection abort on service discovery example

• bleak version:0.7.1
• Python version:3.7.3
• Operating System:Debian 9.13
• BlueZ version (bluetoothctl -v) in case of Linux: 5.43

I want to connect a nordic nrf52DK Uart example from arm based linux os, I tried Ubuntu 16.4 and finally at debian 9.13 but still getting same error on services_discovery.py example.

discover.py works well

but services discovery fails with

bleak.exc.BleakError: org.bluez.Error.Failed: Software caused connection abort

if I try to connect with bluetoothctl after ‘connect CA:xx:xx:xx:xx:xx’ command I get all the information

[NEW] Device CA:xx:xx:xx:xx:xx Nordic_UART [bluetooth]# connect CA:xx:xx:xx:xx:xx Attempting to connect to CA:56:C9:07:54:CF [CHG] Device CA:xx:xx:xx:xx:xxConnected: yes Connection successful [NEW] Primary Service /org/bluez/hci0/dev_CA_xx_xx_xx_xx_xx/service000a uuid was here Generic Attribute Profile [NEW] Primary Service /org/bluez/hci0/dev_CA_xx_xx_xx_xx_xx/service000b uuid was here Vendor specific [NEW] Characteristic /org/bluez/hci0/dev_CA_xx_xx_xx_xx_xx/service000b/char000c uuid was here Vendor specific [NEW] Characteristic /org/bluez/hci0/dev_CA_xx_xx_xx_xx_xx/service000b/char000e uuid was here Vendor specific [NEW] Descriptor /org/bluez/hci0/dev_CA_xx_xx_xx_xx_xx/service000b/char000e/desc0010 uuid was here Client Characteristic Configuration [CHG] Device CA:xx:xx:xx:xx:xx UUIDs: uuid was here [CHG] Device CA:xx:xx:xx:xx:xx UUIDs: uuid was here [CHG] Device CA:xx:xx:xx:xx:xx UUIDs: uuid was here [CHG] Device CA:xx:xx:xx:xx:xx ServicesResolved: yes

I want to find a uart services uuid and send proper data by using that service. Nordic side is already implemented and bleak examples works on Ubuntu 18.4, win10 PC’s but in Debian 9.13 and Ubuntu 16.4 for arm64 same code does not works.

What I Did

I tried to change dbus verson on my ubuntu 16.4 and debian 9.13 which was 1.10.xx to 1.12.xx which is same as ubuntu 18.4 Laptop but I cannot make it done. so basically it is default 1.10.x version of dbus here. other dependencies are same on both platforms.

To clarify that, I cannot use bleak service discovery on embedded pc like orange pi 3 in my case with arm64 based cpu. I have no problem at all on laptops which runs the same examples with Ubuntu 18.4 and win10. but in arm64 arch with ubuntu 16.4 and debian 9.13 I got mentioned error.

root@orangepi3:~/Ble/bleak/examples# python3 service_explorer.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/bleak/backends/bluezdbus/client.py", line 153, in connect
    ).asFuture(self.loop)
txdbus.error.RemoteError: org.bluez.Error.Failed: Software caused connection abort

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "service_explorer.py", line 69, in <module>
    loop.run_until_complete(run(address, loop, True))
  File "/usr/local/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
    return future.result()
  File "service_explorer.py", line 30, in run
    async with BleakClient(address, loop=loop) as client:
  File "/usr/local/lib/python3.7/site-packages/bleak/backends/client.py", line 49, in __aenter__
    await self.connect()
  File "/usr/local/lib/python3.7/site-packages/bleak/backends/bluezdbus/client.py", line 164, in connect
    raise BleakError(str(e))
bleak.exc.BleakError: org.bluez.Error.Failed: Software caused connection abort
root@orangepi3:~/Ble/bleak/examples# python3 discover.py
CA:xx:xx:xx:xx:xx: Nordic_UART

Finally

Any suggestions will be appreciated. We want to connect, discover the services then send and receive data by using ble at arm64 arch platform device. But we couldn’t make it by now.

[dlech]

I think Bluetooth Low Energy was still somewhat experimental in Ubuntu 16.04 and Debian 9 and you may have to run bluetoothd with the --experimental flag to enable some features.

You can also check kernel messages with dmesg and monitor Bluetooth btmon (requires root privileges) to look for other clues.

[hbldh]

The correct solution here is to use the device keyword, both in discover, client init and/or connect methods. Closing this.

Documentation about device wil be improved in #266.