[Bug 221783] New: Bluetooth: new-device pairing consistently fails on Intel AX211 due to ~20s delay between connect and Authentication Requested (WiFi/BT coexistence?)

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221783

            Bug ID: 221783
           Summary: Bluetooth: new-device pairing consistently fails on
                    Intel AX211 due to ~20s delay between connect and
                    Authentication Requested (WiFi/BT coexistence?)
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: galagann@gmail.com
        Regression: No

Component: Bluetooth
Kernel version: 7.1.4-1-default (openSUSE Tumbleweed, reproduced also on
7.1.3-1-default before a kernel update)
Subsystem: Bluetooth 2.22 / bluetoothd (bluez) 5.82, MGMT ver 1.23

Hardware:
- Samsung Galaxy Book4 Pro
- Bluetooth/WiFi combo controller: Intel Corp. AX211 Bluetooth, USB ID
8087:0033
- Firmware: intel/ibt-0180-0041.sfi, DDC intel/ibt-0180-0041.ddc, Firmware
Version 42-20.25, Firmware timestamp 2025.20 buildtype 1 build 3882, SHA1
0x937bca4a

Summary
-------
Pairing with a NEW Bluetooth device (tested with a Sony SRS-XB2 speaker,
classic BR/EDR, Secure Simple Pairing / Just Works) reliably fails. The device
is discovered fine, the ACL connection is established fine, but the host takes
roughly 20 seconds after connecting before it finally issues HCI Authentication
Requested. Peripherals with a short pairing-mode window (this speaker included)
time out and tear down the link at almost exactly the moment the host finally
starts authentication, so pairing never completes. Devices that are already
paired reconnect normally and are not affected — this only breaks the FIRST
pairing of a new device.

The root cause appears to be the host, not the peripheral: two of the routine
post-connect HCI queries that bluetoothd/kernel perform before authentication
(Read Remote Supported Features, and especially Read Remote Extended Features)
take multiple seconds to complete instead of the expected few milliseconds.
This looks consistent with WiFi/Bluetooth coexistence contention on the AX211
combo radio (WiFi was active during all failing attempts).

Confirmed workaround: disabling WiFi entirely before starting the pairing
attempt makes pairing succeed immediately. Re-enabling WiFi afterwards does not
affect the already-paired device.

Steps to reproduce
------------------
1. Have WiFi connected/active on a machine with an Intel AX211 (or likely any
AX210/AX211/similar combo card).
2. Put a classic BR/EDR Bluetooth speaker with Secure Simple Pairing (Just
Works, no MITM) into pairing mode.
3. `bluetoothctl scan on`, wait for the device to appear, then `bluetoothctl
pair <MAC>`.
4. Observe: connection succeeds, but pairing fails a few seconds/tens of
seconds later.
5. Repeat with WiFi fully disabled: pairing succeeds.

Ruled out during diagnosis (i.e. NOT the cause here)
-----------------------------------------------------
- rfkill soft/hard block: adapter was never blocked.
- Stale driver state after suspend/resume: reproduced identically on a
completely fresh boot.
- Stale firmware/module state: `modprobe -r btusb && modprobe btusb` did not
change the behavior.
- Kernel/bluez version: reproduced on both kernel 7.1.3-1-default and
7.1.4-1-default (same bluez 5.82).
- Stale pairing cache: `bluetoothctl remove <MAC>` before each attempt did not
change the behavior.

Captured HCI trace (btmon) — representative failing attempt (WiFi on)
-----------------------------------------------------------------------
Timestamps are relative seconds within the btmon capture.

  < HCI Command: Create Connection (0x01|0x0005)                    #41 
[t=11.656]
        Address: FC:A8:9A:20:16:33 (speaker)
        Clock offset: 0x0000            <-- note: inquiry had reported Clock
offset 0x5734 for
                                             this address a few seconds
earlier, but 0x0000 (unknown)
                                             was used for the actual Create
Connection. Possibly
                                             relevant to the slow
paging/negotiation below.
  > HCI Event: Command Status: Success                              #42 
[t=11.658]

  > HCI Event: Connect Complete: Status Success, Handle 256          #44 
[t=17.589]
        (~5.9s to connect: normal page/connection time)

  < HCI Command: Read Remote Supported Features                     #45 
[t=17.589]
  > HCI Event: Command Status: Success                               #46 
[t=17.590]
  > HCI Event: Read Remote Supported Features Complete: Success      #48 
[t=21.444]
        (~3.9s for a command that normally completes in well under 100ms)

  < HCI Command: Read Remote Extended Features (page 1)              #49 
[t=21.444]
  > HCI Event: Command Status: Success                                #50 
[t=21.445]
  > HCI Event: Read Remote Extended Features Complete: Success        #51 
[t=31.676]
        (~10.2s for a single extended-features page read — this is the biggest
anomaly)

  < HCI Command: Remote Name Request                                 #52 
[t=31.676]
  > HCI Event: Command Status: Success                                #53 
[t=31.677]
  > HCI Event: Remote Name Req Complete:
        Status: Remote User Terminated Connection (0x13)              #54 
[t=32.313]
        (name request never completes: the peripheral already disconnected by
this point)

  @ MGMT Event: Device Connected (Locally Initiated)                 
[t=32.313]
  < HCI Command: Authentication Requested                            #55 
[t=32.313]
  > HCI Event: Disconnect Complete:
        Reason: Remote User Terminated Connection (0x13), Handle 256  #56 
[t=32.314]
        (peripheral disconnects in the same instant Authentication Requested is
finally sent)

  @ MGMT Event: Pair Device Command Complete: Status Disconnected (0x0e)

Total elapsed time from Create Connection to Authentication Requested: ~20.7
seconds.
Total elapsed time from ACL Connect Complete to Authentication Requested: ~14.7
seconds.
For comparison, on a healthy BR/EDR pairing this whole sequence normally
completes in well under a second.

With WiFi fully disabled, the same sequence (same speaker, same laptop)
completes normally and pairing succeeds on the first attempt, immediately after
Connect Complete.

Expected behavior
-----------------
Read Remote Supported/Extended Features and Remote Name Request should complete
within tens/low hundreds of milliseconds after a successful ACL connection, as
they do with WiFi disabled, regardless of WiFi activity on the combo radio.

Additional info available on request
-------------------------------------
- Full btmon captures (several full attempts, before/after kernel update,
before/after WiFi disabled).
- lsusb / lsmod / dmesg excerpts for the AX211 firmware load sequence (clean,
no errors, firmware loads and DDC parameters apply successfully every time).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.