Hi Emil,
On Thu, Jan 25, 2024 at 8:51 AM Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote:
>
> Hi. I have a quite annoying issue on my Ubuntu 22.04 computer with an
> Intel Bluetooth controller (8087:0033, Intel Wi-Fi 6E (6GHz) AX211 2x2
> Bluetooth 5.2 Wireless Card).
> Very often BLE connections to a particular device behaves incorrectly
> (ATT timeout by remote device) because the initial ATT Exchange MTU
> Request arrives to the host (BlueZ) just before the LE Enhanced
> Connection Complete event arrives, and is therefore dropped. I guess
> this is due to separate endpoints and therefore separate flows are
> used in the HCI USB protocol, but have no idea how/if this can be
> fixed?
>
> See btmon log:
>
> < HCI Command: LE Set Extended Advertising En.. (0x08|0x0039) plen 6
> #11 [hci0] 8.102056
> Extended advertising: Enabled (0x01)
> Number of sets: 1 (0x01)
> Entry 0
> Handle: 0x01
> Duration: 0 ms (0x00)
> Max ext adv events: 0
> > HCI Event: Command Complete (0x0e) plen 4 #12 [hci0] 8.104041
> LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
> Status: Success (0x00)
> @ MGMT Event: Command Complete (0x0001) plen 4
> {0x0001} [hci0] 8.104053
> Add Extended Advertising Data (0x0055) plen 1
> Status: Success (0x00)
> Instance: 1
> > ACL Data RX: Handle 3585 flags 0x02 dlen 7 #13 [hci0] 21.049023
> ATT: Exchange MTU Request (0x02) len 2
> Client RX MTU: 247
> > HCI Event: LE Meta Event (0x3e) plen 31 #14 [hci0] 21.049304
> LE Enhanced Connection Complete (0x0a)
> Status: Success (0x00)
> Handle: 3585
> Role: Peripheral (0x01)
> Peer address type: Public (0x00)
> Peer address: (removed)
> Local resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
> Peer resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
> Connection interval: 25.00 msec (0x0014)
> Connection latency: 0 (0x0000)
> Supervision timeout: 700 msec (0x0046)
> Central clock accuracy: 0x00
> @ MGMT Event: Device Connected (0x000b) plen 13
> {0x0001} [hci0] 21.049366
> LE Address: (removed)
> Flags: 0x00000000
> Data length: 0
> < HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
> #15 [hci0] 21.049405
> Handle: 3585
> > HCI Event: LE Meta Event (0x3e) plen 4 #16 [hci0] 21.050229
> LE Channel Selection Algorithm (0x14)
> Handle: 3585
> Algorithm: #2 (0x01)
> > HCI Event: LE Meta Event (0x3e) plen 6 #17 [hci0] 21.051290
> LE Advertising Set Terminated (0x12)
> Status: Success (0x00)
> Handle: 1
> Connection handle: 3585
> Number of completed extended advertising events: 0
> > HCI Event: LE Meta Event (0x3e) plen 11 #18 [hci0] 21.052293
> LE Data Length Change (0x07)
> Handle: 3585
> Max TX octets: 251
> Max TX time: 2120
> Max RX octets: 251
> Max RX time: 2120
> > HCI Event: Command Status (0x0f) plen 4 #19 [hci0] 21.053228
> LE Read Remote Used Features (0x08|0x0016) ncmd 1
> Status: Success (0x00)
This is a design flaw in the Bluetooth Core Specification, it defines
different USB endpoints for data and events but since they don't come
with any timestamp from the controller the host has no idea about
their order. That said we do provide a workaround that can be enabled
with the use of the following config option:
config BT_HCIBTUSB_POLL_SYNC
bool "Enable USB poll_sync for Bluetooth USB devices by default"
depends on BT_HCIBTUSB
default y
help
poll_sync synchronizes the USB data and event endpoints by
prioritizing the later.
Say Y here to enable USB poll_sync for Bluetooth USB devices by
default.
--
Luiz Augusto von Dentz
