Windows Version
Microsoft Windows 11 Business Version 10.0.26200 Build 26200
WSL Version
2.7.8
Are you using WSL 1 or WSL 2?
Kernel Version
6.18.33.1-1
Distro Version
Ubuntu 24.04
Other Software
BlueZ 5.72
Although my application is written in Python 3.12.3 using the Bleak library, the issue is not specific to Bleak.
The same behavior can be reproduced using the standard BlueZ tools alone:
Pair the device using bluetoothctl.
Disconnect.
Attempt to reconnect using bluetoothctl connect <device_address>.
The reconnect fails with:
org.bluez.Error.Failed: le-connection-abort-by-local
Repro Steps
Intel Bluetooth controller (HCI 5.4)
BLE peripheral: nRF52840 running Zephyr (any bonded BLE peripheral should exhibit the same behavior if affected)
Start with no existing bond on either the Linux host or the BLE peripheral.
Scan for the peripheral using bluetoothctl.
Pair and trust the device:
pair <device_address>
trust <device_address>
connect <device_address>
Verify that pairing and the initial connection succeed.
Disconnect from the peripheral.
Attempt to reconnect to the already bonded peripheral using either:
bluetoothctl connect <device_address>, or
a Bleak application using BleakClient.connect().
Observe that the reconnect fails.
Expected Behavior
The bonded peripheral reconnects successfully.
Actual Behavior
The reconnect fails with:
org.bluez.Error.Failed: le-connection-abort-by-local
btmon reports:
MGMT Event: Connect Failed
Status: Disconnected (0x0e)
dmesg reports:
Bluetooth: hci0: Invalid exception type 03
Bluetooth: hci0: Invalid exception type 04
The peripheral never receives a BLE connection callback, indicating that the connection is aborted before a link is established.
Regression
The exact same hardware, firmware, BlueZ version, and Python application work correctly after downgrading WSL to version 2.7.3.0 with wsl kernel version 6.6.114.1-microsoft-standard-WSL2. No changes were made to:
BLE peripheral firmware
BlueZ version
Python version
Bleak version
Bluetooth adapter
The only change was the WSL version.
Diagnostic Logs
No response
Windows Version
Microsoft Windows 11 Business Version 10.0.26200 Build 26200
WSL Version
2.7.8
Are you using WSL 1 or WSL 2?
Kernel Version
6.18.33.1-1
Distro Version
Ubuntu 24.04
Other Software
BlueZ 5.72
Although my application is written in Python 3.12.3 using the Bleak library, the issue is not specific to Bleak.
The same behavior can be reproduced using the standard BlueZ tools alone:
Pair the device using bluetoothctl.
Disconnect.
Attempt to reconnect using bluetoothctl connect <device_address>.
The reconnect fails with:
org.bluez.Error.Failed: le-connection-abort-by-local
Repro Steps
Intel Bluetooth controller (HCI 5.4)
BLE peripheral: nRF52840 running Zephyr (any bonded BLE peripheral should exhibit the same behavior if affected)
Start with no existing bond on either the Linux host or the BLE peripheral.
Scan for the peripheral using bluetoothctl.
Pair and trust the device:
pair <device_address>
trust <device_address>
connect <device_address>
Verify that pairing and the initial connection succeed.
Disconnect from the peripheral.
Attempt to reconnect to the already bonded peripheral using either:
bluetoothctl connect <device_address>, or
a Bleak application using BleakClient.connect().
Observe that the reconnect fails.
Expected Behavior
The bonded peripheral reconnects successfully.
Actual Behavior
The reconnect fails with:
org.bluez.Error.Failed: le-connection-abort-by-local
btmon reports:
MGMT Event: Connect Failed
Status: Disconnected (0x0e)
dmesg reports:
Bluetooth: hci0: Invalid exception type 03
Bluetooth: hci0: Invalid exception type 04
The peripheral never receives a BLE connection callback, indicating that the connection is aborted before a link is established.
Regression
The exact same hardware, firmware, BlueZ version, and Python application work correctly after downgrading WSL to version 2.7.3.0 with wsl kernel version 6.6.114.1-microsoft-standard-WSL2. No changes were made to:
BLE peripheral firmware
BlueZ version
Python version
Bleak version
Bluetooth adapter
The only change was the WSL version.
Diagnostic Logs
No response