Bluetooth: HCI Create Connection issues default page-scan parameters (R2, clock_offset=0) instead of values from inquiry cache, causes Page Timeout on BR/EDR audio device

[Jacob Mills <jacobmills1997@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9490 bytes --]

Hi,

Filing this for a 100%-reproducible BR/EDR pairing failure on a recent 
Fedora kernel against a 2015-era audio speaker, with btmon evidence 
pointing at the kernel's HCI Create Connection path ignoring 
inquiry-cache page parameters. The same physical hardware pairs the same 
speaker successfully on Windows.


SUMMARY
-------

When pairing a BR/EDR-only audio device that advertises Page Scan 
Repetition Mode R1 with a non-zero clock offset, the kernel issues HCI 
Create Connection with default values (R2, clock_offset=0). The page 
never reaches the remote device and Connect Complete returns with status 
Page Timeout (0x04) after the default 5.12s page timeout. Pairing fails 
every time. The inquiry that immediately preceded the pair attempt was 
observed by the kernel (HCI Event #3 below) and contained the correct 
page parameters, so the data was available to the host stack -- it just 
was not used in the subsequent Create Connection.


AFFECTED SYSTEM
---------------

Distribution     Fedora 44
Kernel           7.0.6-200.fc44.x86_64
linux-firmware   20260410-1.fc44
BlueZ            5.86-4.fc44 (bluetoothd and bluetoothctl)
Controller       MediaTek MT7922 (BlueZ manufacturer id 0x001d / 29)
                  USB ID 0489:e10d (Foxconn / Hon Hai), bcdDevice 0.01
                  Combo card (BT + Wi-Fi on shared antennas; Wi-Fi was
                  on 5 GHz at time of failure; also reproduces with
                  Wi-Fi disabled)
Controller MAC   D8:B3:2F:44:DC:DE
Remote device    Edifier Luna Eclipse HD (e25HD) powered speaker
                  (BR/EDR-only, A2DP Sink + AVRCP, manuf-id "Fihonest")
Remote MAC       40:EF:4C:E0:B6:7B

Three kernels are installed locally; a regression test on
6.19.10-300.fc44 has not yet been run. Happy to do that and follow up.


REPRODUCIBILITY
---------------

100% reproducible on this kernel/firmware/hardware combination across:

   * bluetooth.service restart
   * modprobe -r btusb && modprobe btusb (full firmware reload, confirmed
     by matching "usbcore: deregistering/registered new interface driver
     btusb" pair in dmesg)
   * bluetoothctl power off/on (HCI Reset)
   * USB autosuspend disabled
     (echo on > /sys/bus/usb/devices/1-6/power/control)
   * Wi-Fi radio disabled (rules out MT7922 BT/WiFi antenna coex)
   * Fresh 60-second speaker power cycle
   * Fresh bond state on the laptop (no on-disk bond record)

The Linux side discovers the speaker reliably via `scan bredr` at strong 
signal (-55 to -58 dBm). Only the page-following-pair fails.


REPRODUCER
----------

In a single bluetoothctl session, with the speaker freshly power-cycled 
and in BT input mode (solid blue LED), no other host bonded to the speaker:

     [bluetoothctl]# scan bredr
     ... [NEW] Device 40:EF:4C:E0:B6:7B EDIFIER Luna Eclipse HD
     ... [CHG] Device 40:EF:4C:E0:B6:7B RSSI: 0xffffffc8 (-56)
     [bluetoothctl]# scan off
     [bluetoothctl]# pair 40:EF:4C:E0:B6:7B
     Attempting to pair with 40:EF:4C:E0:B6:7B
     Failed to pair: org.bluez.Error.ConnectionAttemptFailed

The same outcome occurs with `connect` (post-bond) -- both surface as 
the same HCI Page Timeout underneath.


THE BUG, FROM BTMON
-------------------

The relevant excerpt (full snoop file attached):

   > HCI Event: Extended Inquiry Result (0x2f) plen 255  #3   35.314602
           Num responses: 1
           Address: 40:EF:4C:E0:B6:7B
           Page scan repetition mode: R1 (0x01)   <-- speaker advertises R1
           Class: 0x240428 (Audio/Video, HiFi Audio Device)
           Clock offset: 0x3f03                   <-- non-zero, valid
           RSSI: -58 dBm (0xc6)
           Name (complete): EDIFIER Luna Eclipse HD
           Service UUIDs: A2DP Sink/Source, AVRCP Target/Controller

   [ ~12s of `scan off`, MGMT Add Device, MGMT Pair Device ]

   < HCI Command: Create Connection (0x01|0x0005) plen 13  #11  47.576809
           Address: 40:EF:4C:E0:B6:7B
           Packet type: 0xcc18
           Page scan repetition mode: R2 (0x02)   <-- kernel uses R2,
                                                      ignoring cache R1
           Page scan mode: Mandatory (0x00)
           Clock offset: 0x0000                   <-- kernel uses 0,
                                                      ignoring cache 0x3f03
           Role switch: Allow peripheral (0x01)

   > HCI Event: Command Status (0x0f) plen 4 #12  47.577608
           Create Connection (0x01|0x0005) ncmd 1
           Status: Success (0x00)

   > HCI Event: Connect Complete (0x03) plen 11  #13  52.698868
           Status: Page Timeout (0x04)
           Address: 40:EF:4C:E0:B6:7B
           Link type: ACL (0x01)
                                                  <-- 5.122s after
                                                      Create Connection
                                                  <-- = default Page Timeout
                                                      (0x2000 slots)

The kernel issued Create Connection 12 seconds after it observed the EIR 
for this address. The inquiry cache entry should still have been valid 
(default eviction is 60s). Either the cache is not being read on this 
code path, the inquiry result is not populating the cache, or the cached 
PageScanRepetitionMode / clock_offset fields are not being plumbed into 
hci_acl_create_connection() (or equivalent).

For a device using R1 (1.28s page-scan-window cycle) the host-side hint 
should reflect that so the controller can size its page train timing
appropriately; pairing with default R2 + null clock offset against an R1 
device with a non-zero clock offset means the page train is misaligned 
and the page misses entirely within the 5.12s window. On Windows, with 
the same physical controller, pairing succeeds -- so Windows clearly 
does plumb the inquiry-result page parameters into its page command.


SURFACE-LEVEL ERRORS THIS PRODUCES
----------------------------------

Depending on call site, BlueZ-userspace remaps the underlying HCI Page
Timeout (status 0x04) to different D-Bus errors, which can mislead
triage:

   bluetoothctl pair       -> org.bluez.Error.ConnectionAttemptFailed
   bluetoothctl connect    -> org.bluez.Error.Failed
                               br-connection-page-timeout
   bluetoothd (audio path) -> avdtp_connect_cb() connect to
                               40:EF:4C:E0:B6:7B: Host is down (112)

All three are the same HCI Page Timeout under the hood.


WHAT WAS RULED OUT
------------------

   Speaker hardware           OK -- pairs with other devices, pairs on
                                   Windows on the same physical host
   MT7922 controller hardware OK -- works on Windows; BR/EDR scan finds
                                   the speaker at -55 to -58 dBm
   Stale kernel / firmware    No -- both current (linux-firmware
                                   20260410, kernel 7.0.6)
   Bond conflict / stale key  No -- empty /var/lib/bluetooth/.../<dev>
   Other host hogging link    No -- confirmed no other paired/connected
                                   device
   USB autosuspend on btusb   No -- power/control: on,
                                   runtime_status: active
   Wi-Fi/BT antenna coex      No -- fails identically with `nmcli radio
                                   wifi off`
   Stale BlueZ device cache   No -- persists after `bluetoothctl remove`,
                                   fresh discovery, full daemon restart
   Stale kernel HCI state     No -- persists after modprobe -r/+ btusb
   Discovery transport (LE)   Not it -- explicitly using `scan bredr`,
                                   speaker appears reliably


RELATED CONTROLLER QUIRK IN DMESG (probably unrelated)
------------------------------------------------------

   Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is 
advertised, but not supported.

This is a known MT7922 firmware quirk for ESCO setup and would not 
affect BR/EDR ACL paging. Listing only in case it is relevant.


ATTACHMENTS
-----------

   bt.snoop -- full btmon capture covering the failing pair attempt
               (sudo btmon -w /tmp/bt.snoop, captured during
               `bluetoothctl scan bredr ; pair 40:EF:4C:E0:B6:7B`).


OPEN QUESTION FOR MAINTAINERS
-----------------------------

Is hci_create_connection() (or whichever code path the kernel's 
mgmt_pair_device ends up calling) expected to look up the inquiry cache 
for the target BD_ADDR and pull PageScanRepetitionMode / clock_offset 
from there? Or is the userspace MGMT Pair Device (0x0019) opcode 
expected to carry these parameters?

If the latter, this could equally be a BlueZ userspace bug not 
forwarding inquiry data into the mgmt call. The trace above shows the 
inquiry data reaching the kernel; whether it survives into the 
create-connection path is the open question.

Have a great day,
Jacob Mills

[-- Attachment #2: bt.snoop --]
[-- Type: application/octet-stream, Size: 1818 bytes --]