* 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
@ 2026-05-14 19:10 Jacob Mills
2026-05-14 19:33 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 2+ messages in thread
From: Jacob Mills @ 2026-05-14 19:10 UTC (permalink / raw)
To: linux-bluetooth
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: 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
2026-05-14 19:10 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
@ 2026-05-14 19:33 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 2+ messages in thread
From: Luiz Augusto von Dentz @ 2026-05-14 19:33 UTC (permalink / raw)
To: Jacob Mills; +Cc: linux-bluetooth
Hi Jacob,
On Thu, May 14, 2026 at 3:10 PM Jacob Mills <jacobmills1997@gmail.com> wrote:
>
> 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
It took longer to read all this than to just check if we perform
inquiry caching:
https://github.com/bluez/bluetooth-next/blob/workflow/net/bluetooth/hci_sync.c#L6945
https://github.com/bluez/bluetooth-next/blob/workflow/include/net/bluetooth/hci_core.h#L905
This is old code that hasn't been touched for ages, before MGMT
interface was introduced, so I have no idea how it wouldn't use the
cached values, except perhaps if there is a reset that flushes the
cache or something similar.
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-14 19:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-14 19:10 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
2026-05-14 19:33 ` Luiz Augusto von Dentz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox