Created attachment 307860 [details] btmon trace using pair method via Dbus API Attempting to Pair with a BLE device fails on the first Pairing attempt, but succeeds on the second Pairing attempt when utilizing Bluez Dbus API. When utilizing bluetoothctl directly, this issue does not occur. Note that this issue does not arise when using Intel AC 9462, but only arises utilizing Intel AX211. From the syslogs, it seems new_long_term_key_callback() is never hit during the first Pair attempt when utilizing dbus API, but is hit when using bluetoothctl on the first Pair attempt. I'm unsure where to go from here, but open to suggestions on how to debug this issue further. From the btmon log attached, it seems that LE Start Encryption occurs in # 40 (2.293188), followed by success in # 42 (2.294177). However, after the supervision timeout of 30s, a disconnect is sent # 86 (32.619238). In the second pair attempt, LE Start Encryption occurs in # 142 (37.979552), followed by an Encryption Change event in # 143 (38.157560). Following that, a new long term key event is notified, and pairing succeeds. Seems as though the Encryption Change event (0x08) only occurs on the second attempt.
Created attachment 307861 [details] Btmon trace using bluetoothctl Attached is a btmon log file when using bluetoothctl to pair. It looks as though the LE Start Encryption on # 48 (8.710910) is followed by the Encryption Change event on # 49 (8.888913). Following that, the new long term key event occurs and pairing succeeds.
Created attachment 307862 [details] Syslog when using Bluez Dbus API Syslog using Bluez DBus API - shows that new_long_term_key_callback() is not hit during the first Pair attempt.
Created attachment 307863 [details] Syslog when using Bluetoothctl Syslog attached when using Bluetoothctl. Shows that new_long_term_key_callback() is hit on first Pair attempt.
uname -r 6.13.7-arch1-1 linux-firmware version 20250311 (arch linux version 20250311.b69d4b74-3) Bluetooth: hci0: Found device firmware: intel/ibt-0040-0041.sfi Bluetooth: hci0: Firmware Version: 200-48.24 Note that this bug has been reported to Bluez https://github.com/bluez/bluez/issues/1125.
Created attachment 307872 [details] Failed Pair Attempt Air Sniffer snoop Air sniffer failed pair attempt attached (recommend filter btle.length != 0 in wireshark to filter out empty PDUs). From what I can see, Master (computer with AX211) does not send LL_ENC_REQ after Slave receives Pairing DHKey Check when pairing fails (failed pair attempt No. 182 and onward).
Created attachment 307873 [details] Successful Pair Attempt Air Sniffer log Air sniffer successful pair attempt (second Pair() attempt via Dbus API). When pairing succeeds, Master sends LL_ENC_REQ after Slave receives Pairing DHKey Check (see successful pair attempt No. 67 and No. 70).
(Apologies for the multiple comments, I should have added this at the start).
After further testing, issue does occur utilizing bluetoothctl as well. On the first Pair attempt, org.bluez.Error.AuthenticationCanceled occurs. On the second attempt, pairing is successful. This issue can be duplicated by removing the /var/lib/bluetooth/<adapter address>/<remote device address>/ folder and restarting the bluetooth.service (systemctl restart bluetooth). Seems that without the cached attributes/info, this issue arises. However, if the BLE peripheral attributes/info is stored in /var/lib/bluetooth/<adapter address>/<remote device address>/ folder, the issue does not occur.