Pixel 9a: BT legacy pairing with BMW head unit fails with HCI_ERR_LMP_RESPONSE_TIMEOUT after PIN reply (works on stock Android 16)

[Bingo2023]

Issue type

Feature not working as intended

Device

Google Pixel 9a (tegu)

crDroid version

crDroid 12

Exact version / Build date

crDroid 12.11 Built date: 2. July

Bug description

Bug description

Pairing with an older BMW head unit (BR/EDR legacy pairing, no Secure Simple Pairing) fails on
crDroid. The same phone running stock Android 16 pairs successfully with the same head unit,
so this appears to be ROM-specific rather than a hardware or head unit fault.

The PIN dialog appears and the PIN is handed to the stack correctly. The failure occurs
afterwards, at link level:

• Remote sm4: 0x0 — legacy pairing, remote has no SSP (expected for this head unit generation)
• BTM_PINCodeReply: PinLen:4 Result:0 — PIN accepted and sent by the stack
• ~18 s later: OnConnectFail ... reason:TRANSACTION_RESPONSE_TIMEOUT(0x22) followed by
  Bonding failed with failure reason:HCI_ERR_LMP_RESPONSE_TIMEOUT
• Bond state goes BOND_BONDING => BOND_NONE, hciReason: 34 (0x22)

The head unit displays "wrong passkey", but that is simply how it reports any incomplete pairing
attempt. The stack never reports an authentication failure (HCI_ERR_AUTH_FAILURE / 0x05) — the
remote just stops responding after the PIN is supplied.

Two further observations that may be relevant:

• btif_dm_pin_req_evt: cod is 0, set as unclassified — Class of Device was not read
• BTM_GetPeerDeviceTypeFromFeatures: Device features does not support BR/EDR and BLE — the
  remote feature read did not return usable data

This may point to a missing interop entry or different LMP feature handling compared to stock.

Possibly related to #988 (same device, same class of head unit, but a different failure point —
there the PIN dialog did not appear at all).

Steps to reproduce

1. Clear all paired devices from the head unit's Bluetooth list; unpair the head unit on the phone
2. Head unit: Telephone → Bluetooth → pair new device, choose a 4-digit passkey
3. Phone: Settings → Connected devices → Pair new device → select the head unit
4. Enter the same passkey in the dialog on the phone
5. Pairing fails; the head unit reports a wrong passkey

Reproducible on every attempt. Works on stock Android 16 on the same phone.

Relevant log (logcat/build log)

09-02 13:22:03.643 bt_btif_dm: btif_dm_create_bond: bd_addr=xx:xx:xx:xx:1a:71, transport=0
09-02 13:22:03.643 bt_btif_dm: bond_state_changed: state=1[bonding], prev_state=0
09-02 13:22:03.645 bt_btm_sec: btm_sec_bond_by_transport: Remote sm4: 0x0  HCI Handle: 0xffff
09-02 13:22:03.646 bluetooth : btm_sec_bond_by_transport: sec mode: 4 sm4:x0
09-02 13:22:03.658 bt_btm_sec: change_pairing_state: IDLE => WAIT_PIN_REQ pairing_flags:0x5

09-02 13:22:11.055 bt_btm_sec: btm_sec_pin_code_request: Controller requests PIN code state:WAIT_PIN_REQ
09-02 13:22:11.055 bt_btm_sec: change_pairing_state: WAIT_PIN_REQ => WAIT_LOCAL_PIN pairing_flags:0x5
09-02 13:22:11.055 bt_btif_dm: btif_dm_sec_evt: ev:BTA_DM_PIN_REQ_EVT(0x2)
09-02 13:22:11.055 bt_btm_sec: BTM_GetPeerDeviceTypeFromFeatures: Device features does not support BR/EDR and BLE
09-02 13:22:11.056 bt_btif_dm: btif_dm_pin_req_evt: cod is 0, set as unclassified

09-02 13:22:17.274 BTPairingController: Pairing dialog accepted
09-02 13:22:17.281 bt_btm_sec: BTM_PINCodeReply: PairState: WAIT_LOCAL_PIN  PairFlags: 0x0d  PinLen:4  Result:0
09-02 13:22:17.282 bt_btm_sec: change_pairing_state: WAIT_LOCAL_PIN => WAIT_PIN_REQ pairing_flags:0xd

09-02 13:22:35.661 bluetooth : OnConnectFail: Connection failed classic remote:xx:xx:xx:xx:1a:71 reason:TRANSACTION_RESPONSE_TIMEOUT(0x22)
09-02 13:22:35.661 bt_btm_sec: btm_sec_connected: state:WAIT_PIN_REQ handle:0xffff status:HCI_ERR_LMP_RESPONSE_TIMEOUT RName:BMW 50235
09-02 13:22:35.661 bt_btm_sec: change_pairing_state: WAIT_PIN_REQ => IDLE pairing_flags:0xd
09-02 13:22:35.662 bt_btif_dm: btif_dm_auth_cmpl_evt: success=false, key_present=false
09-02 13:22:35.662 bt_btif_dm: btif_dm_auth_cmpl_evt: Bonding failed with failure reason:HCI_ERR_LMP_RESPONSE_TIMEOUT
09-02 13:22:35.676 bt_btm_sec: btm_sec_dev_rec_cback_event: btm_status=tBTM_STATUS::BTM_DEVICE_TIMEOUT
09-02 13:22:35.677 BluetoothBondStateMachine: bondStateChangeCallback: Status: 10 newState: 0 hciReason: 34
09-02 13:22:35.693 BluetoothBondStateMachine: Bond State Change Intent: BOND_BONDING => BOND_NONE


Full logcat attached. A btsnoop_hci capture can be provided if useful.

Screenshots or videos

Solution

No response

Additional context

Already tried without success: clearing Bluetooth storage and cache, resetting network settings,
pairing in safe mode, disabling LE Audio, initiating pairing from both sides, and clearing the
head unit's paired device list.

logcat-excerpt.txt

Acknowledgements

• I've checked device is officially supported and that no support is provided for unofficial devices (for device specific reports and not source related).
• I'm running latest version available on crdroid.net for this device and that the device is still maintainer supported (not flagged unsupported on download page)
• I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• I have written a short but informative title.
• I filled out all of the requested information in this issue properly and understand that not doing so will automatically result in closing of ticket.

[Bingo2023]

Update: btsnoop capture — host never sends PIN_Code_Request_Reply

I captured the HCI traffic (btsnoop_hci.log) for a failing attempt. This narrows the problem
down considerably and changes my earlier reading of the logcat.

The host never emits PIN_Code_Request_Reply (opcode 0x040D) to the controller.

HCI sequence of the failing attempt (timestamps UTC, non-relevant LE scan/advertising traffic
removed):

11:22:00.547  CMD REMOTE_NAME_REQUEST peer=00:0E:9F:93:1A:71
11:22:01.815  EVT REMOTE_NAME_REQUEST_COMPLETE status=SUCCESS peer=00:0E:9F:93:1A:71 name='BMW 50235'
11:22:03.644  CMD DELETE_STORED_LINK_KEY (0x0c12)
11:22:03.646  EVT COMMAND_COMPLETE -> 0x0c12 status=0x12 (INVALID_HCI_COMMAND_PARAMETERS)
11:22:03.659  CMD CREATE_CONNECTION peer=00:0E:9F:93:1A:71
11:22:03.664  EVT COMMAND_STATUS -> CREATE_CONNECTION status=SUCCESS
11:22:11.053  EVT PIN_CODE_REQUEST peer=00:0E:9F:93:1A:71
                 <-- user enters the PIN here; no 0x040D is sent
11:22:17.282  CMD WRITE_AUTHENTICATION_ENABLE
11:22:17.297  EVT COMMAND_COMPLETE -> WRITE_AUTHENTICATION_ENABLE status=SUCCESS
11:22:35.652  EVT CONNECTION_COMPLETE status=LMP_RESPONSE_TIMEOUT handle=0x000b peer=00:0E:9F:93:1A:71

Opcode 0x040D does not appear anywhere in the capture (I also checked 0x040E, 0x040B, 0x040C
and 0x0411 — none of them are present either). Snoop log filtering was disabled, so nothing is
being redacted.

Correlation with logcat

The corresponding logcat lines are misleading on their own:

13:22:11.055 btm_sec_pin_code_request: Controller requests PIN code state:WAIT_PIN_REQ
13:22:11.055 change_pairing_state: WAIT_PIN_REQ => WAIT_LOCAL_PIN pairing_flags:0x5
13:22:17.281 BTM_PINCodeReply: PairState: WAIT_LOCAL_PIN  PairFlags: 0x0d  PinLen:4  Result:0
13:22:17.282 change_pairing_state: WAIT_LOCAL_PIN => WAIT_PIN_REQ pairing_flags:0xd
13:22:35.661 btm_sec_connected: status:HCI_ERR_LMP_RESPONSE_TIMEOUT RName:BMW 50235
13:22:35.662 btif_dm_auth_cmpl_evt: Bonding failed with failure reason:HCI_ERR_LMP_RESPONSE_TIMEOUT

BTM_PINCodeReply ... Result:0 only confirms the UI handed a valid 4-digit PIN to the stack — it
does not mean the reply reached the controller, and the btsnoop shows it did not.

Note the state transition: after the PIN is supplied, pairing state goes
WAIT_LOCAL_PIN => WAIT_PIN_REQ rather than WAIT_AUTH_COMPLETE. That looks like
BTM_PINCodeReply() taking a path that defers sending the reply and waits for a second
PIN_Code_Request from the controller, which never arrives because the first one is still
outstanding. The controller then times out at the LMP level ~24 s later.

Possibly relevant conditions

• Legacy pairing, remote has no SSP: Remote sm4: 0x0, sec mode: 4
• PIN_Code_Request arrives before Connection_Complete, i.e. there is no ACL yet
  (HCI Handle: 0xffff, An ACL connection does not currently exist)
• btif_dm_pin_req_evt: cod is 0, set as unclassified — Class of Device was not read
• BTM_GetPeerDeviceTypeFromFeatures: Device features does not support BR/EDR and BLE
• Delete_Stored_Link_Key returns status 0x12 right before the connection attempt

Environment

• Pixel 9a (tegu), crDroid 12.11, build date 29 June 2026, June 2026 security patch
• Remote: 00:0E:9F:93:1A:71, name BMW 50235 (BMW head unit, legacy pairing, fixed passkey)
• The same phone with stock Android 16 pairs successfully with the same head unit

Where this likely lives

packages/modules/Bluetooth/system/stack/btm/btm_sec.cc → BTM_PINCodeReply(), specifically the
branch that decides between calling btsnd_hcic_pin_code_req_reply() and returning early after
btm_sec_change_pairing_state(BTM_PAIR_STATE_WAIT_PIN_REQ). The BTM_PAIR_FLAGS_PRE_FETCH_PIN
handling and the hci_handle == HCI_INVALID_HANDLE case look like the candidates given the
"PIN request before ACL" situation above.

This may also explain #988 (same device, same class of head unit) where the PIN dialog did not
appear at all — possibly the same code path failing one step earlier.

Full logcat and btsnoop captures attached. Happy to test patches or add instrumentation logging
if that helps.

hci-excerpt.txt

[Bingo2023]

Update 2: stock-vs-crDroid comparison, root cause and proposed patch

I captured btsnoop on the same phone running stock Android 16 for a successful pairing with
the same head unit. Preconditions are identical in both runs, and the divergence is a single
missing HCI command.

Side-by-side

Same phone (Pixel 9a / tegu), same remote (00:0E:9F:93:1A:71, "BMW 50235"), legacy pairing,
4-digit PIN.

Stock Android 16 — SUCCESS

14:00:11.200  CMD DELETE_STORED_LINK_KEY (0x0c12)
14:00:11.204  EVT COMMAND_COMPLETE -> 0x0c12 status=0x12 (INVALID_HCI_COMMAND_PARAMETERS)
14:00:11.204  CMD CREATE_CONNECTION peer=00:0E:9F:93:1A:71
14:00:11.207  EVT COMMAND_STATUS -> CREATE_CONNECTION status=SUCCESS
14:00:18.534  EVT PIN_CODE_REQUEST peer=00:0E:9F:93:1A:71        <-- before CONNECTION_COMPLETE
                 [user enters PIN, 6.4 s]
14:00:24.967  CMD PIN_CODE_REQUEST_REPLY peer=00:0E:9F:93:1A:71 pin_len=4    <-- SENT
14:00:24.984  EVT COMMAND_COMPLETE -> PIN_CODE_REQUEST_REPLY status=SUCCESS
14:00:25.216  EVT LINK_KEY_NOTIFICATION peer=00:0E:9F:93:1A:71
14:00:25.302  EVT CONNECTION_COMPLETE status=SUCCESS handle=0x000b
14:00:25.696  CMD AUTHENTICATION_REQUESTED handle=0x000b
14:00:25.700  EVT LINK_KEY_REQUEST peer=00:0E:9F:93:1A:71
14:00:25.700  CMD LINK_KEY_REQUEST_REPLY peer=00:0E:9F:93:1A:71
14:00:25.717  EVT AUTHENTICATION_COMPLETE status=SUCCESS handle=0x000b
14:00:25.717  CMD SET_CONNECTION_ENCRYPTION handle=0x000b

crDroid 12.11 — FAILURE

11:22:03.644  CMD DELETE_STORED_LINK_KEY (0x0c12)
11:22:03.646  EVT COMMAND_COMPLETE -> 0x0c12 status=0x12 (INVALID_HCI_COMMAND_PARAMETERS)
11:22:03.659  CMD CREATE_CONNECTION peer=00:0E:9F:93:1A:71
11:22:03.664  EVT COMMAND_STATUS -> CREATE_CONNECTION status=SUCCESS
11:22:11.053  EVT PIN_CODE_REQUEST peer=00:0E:9F:93:1A:71        <-- before CONNECTION_COMPLETE
                 [user enters PIN, 6.2 s]
11:22:17.282  CMD WRITE_AUTHENTICATION_ENABLE                    <-- no PIN reply
11:22:17.297  EVT COMMAND_COMPLETE -> WRITE_AUTHENTICATION_ENABLE status=SUCCESS
                 [controller waits 18 s for a reply that never comes]
11:22:35.652  EVT CONNECTION_COMPLETE status=LMP_RESPONSE_TIMEOUT handle=0x000b

PIN_Code_Request_Reply (0x040D) does not appear anywhere in the crDroid capture.

This rules out the alternatives: in both runs the PIN request arrives before
Connection_Complete, user entry latency is effectively the same (6.4 s vs 6.2 s), the preceding
command sequence is identical down to the 0x0c12 error, and the head unit behaves the same way.
Where stock sends PIN_Code_Request_Reply, crDroid sends Write_Authentication_Enable.

Root cause

packages/modules/Bluetooth/system/stack/btm/btm_sec.cc, BTM_PINCodeReply() (line 371 in
crdroidandroid/android_packages_modules_Bluetooth branch 16.0 — the logcat line numbers
btm_sec.cc:374, :483, :4369, :4823 match this file, so this is the code running on the
device).

At line 424:

  if ((btm_sec_cb.pairing_flags & BTM_PAIR_FLAGS_WE_STARTED_DD) &&
      (p_dev_rec->hci_handle == HCI_INVALID_HANDLE) && (!btm_sec_cb.security_mode_changed)) {
    /* This is start of the dedicated bonding if local device is 2.0 */
    btm_sec_cb.pin_code_len = pin_len;
    memcpy(btm_sec_cb.pin_code, p_pin, pin_len);

    btm_sec_cb.security_mode_changed = true;
    btsnd_hcic_write_auth_enable(true);
    ...
    } else if (btm_sec_dd_create_conn(p_dev_rec) != tBTM_STATUS::BTM_CMD_STARTED) {
      ...
    }
    return;          // returns without sending PIN_Code_Request_Reply
  }

  btm_sec_cb.change_pairing_state(BTM_PAIR_STATE_WAIT_AUTH_COMPLETE);
  acl_set_disconnect_reason(HCI_SUCCESS);
  btsnd_hcic_pin_code_req_reply(bd_addr, pin_len, p_pin);

This branch implements the pre-fetch flow: ask the user for the PIN before a link exists, stash it,
and let btm_sec_pin_code_request() send it when the controller eventually asks (its
btm_sec_cb.pin_code_len != 0 branch, line ~4424).

The condition uses hci_handle == HCI_INVALID_HANDLE as a proxy for "the controller cannot have
requested the PIN yet". That proxy does not hold here: this head unit issues PIN_Code_Request
during connection setup, before Connection_Complete, which is legal. All three conditions are
therefore true even though a PIN request is already outstanding, and the stack stashes the PIN,
calls btm_sec_dd_create_conn() (which sets state back to BTM_PAIR_STATE_WAIT_PIN_REQ, line
2003) and returns. It then waits for a second PIN_Code_Request that cannot arrive, because the
controller is still waiting for the reply to the first one. Deadlock until the LMP response
timeout.

Two details confirm the path taken: the Write_Authentication_Enable at 11:22:17 is the
btsnd_hcic_write_auth_enable(true) call at line 431, and neither log::warn inside the branch
appears in the logcat, so the third else if (btm_sec_dd_create_conn) was the one executed.

Proposed patch

BTM_PAIR_FLAGS_PIN_REQD (0x08) is exactly the "controller has an outstanding PIN request" flag:
set in btm_sec_pin_code_request() (line ~4467) immediately before the UI callback, and
pairing_flags is zeroed when pairing returns to IDLE (line 4836). It was set here —
pairing_flags was 0x0d at entry to BTM_PINCodeReply.

--- a/system/stack/btm/btm_sec.cc
+++ b/system/stack/btm/btm_sec.cc
@@ -424,6 +424,7 @@ void BTM_PINCodeReply(const RawAddress& bd_addr, tBTM_STATUS res, uint8_t pin_le
   if ((btm_sec_cb.pairing_flags & BTM_PAIR_FLAGS_WE_STARTED_DD) &&
+      !(btm_sec_cb.pairing_flags & BTM_PAIR_FLAGS_PIN_REQD) &&
       (p_dev_rec->hci_handle == HCI_INVALID_HANDLE) && (!btm_sec_cb.security_mode_changed)) {
     /* This is start of the dedicated bonding if local device is 2.0 */
     btm_sec_cb.pin_code_len = pin_len;

Control then falls through to the normal path and sends PIN_Code_Request_Reply immediately,
which is what stock does in the identical situation.

One caveat: btsnd_hcic_write_auth_enable(true) is no longer called on this path. For a bond we
initiated with an outstanding PIN request, authentication is already in progress, and stock does
not send that command here either. If that turns out to matter, a more conservative variant is to
keep the branch and answer the outstanding request inside it, after
acl_set_disconnect_reason(HCI_ERR_UNDEFINED):

    if (btm_sec_cb.pairing_flags & BTM_PAIR_FLAGS_PIN_REQD) {
      log::info("PIN request already outstanding, replying immediately");
      btm_sec_cb.pin_code_len = 0;
      btm_sec_cb.change_pairing_state(BTM_PAIR_STATE_WAIT_AUTH_COMPLETE);
      acl_set_disconnect_reason(HCI_SUCCESS);
      btsnd_hcic_pin_code_req_reply(bd_addr, pin_len, p_pin);
      return;
    }

I have not built or tested either variant yet.

Attachments

All three files are trimmed to the relevant window so they open directly in Wireshark without
hunting through the full ring buffer.

• btsnoop-stock-OK.txt — successful pairing on stock Android 16 (671 packets,
  14:00:05–14:00:34 UTC). Contains PIN_Code_Request_Reply (0x040D) once.
• btsnoop-crdroid-FAIL.txt — failing pairing on crDroid 12.11 (267 packets,
  11:21:50–11:22:44 UTC). Contains PIN_Code_Request_Reply zero times.
• `logcat-crdroid-FAIL.txt

btsnoop-crdroid-FAIL.txt
btsnoop-stock-OK.txt
logcat-crdroid-FAIL.txt

` — matching logcat from the failing attempt, filtered to Bluetooth
tags (13:21:55–13:22:45 local, i.e. UTC+2).

Full untrimmed captures available on request.

[Bingo2023]

Update 3: proposed patch attached

Based on the stock-vs-crDroid comparison above, here is a candidate fix as a git format-patch
file: 0001-Bluetooth-reply-to-outstanding-PIN-code-request.patch.

It applies to packages/modules/Bluetooth and was generated against
crdroidandroid/android_packages_modules_Bluetooth branch 16.0 — the revision whose line numbers
match the ones in the device logcat (btm_sec.cc:374, :483, :4369, :4823), so it should apply
cleanly to the tree the affected builds come from.

What it changes

One condition in BTM_PINCodeReply(), plus a comment explaining why the existing guard is not
sufficient:

+  /* The pre-fetch path below stashes the PIN and waits for the controller to
+   * request it. Only take it when no PIN code request is outstanding: the
+   * controller may issue HCI_PIN_Code_Request during connection setup, before
+   * HCI_Connection_Complete, in which case hci_handle is still invalid but the
+   * peer is already waiting for the reply and no second request will follow. */
   if ((btm_sec_cb.pairing_flags & BTM_PAIR_FLAGS_WE_STARTED_DD) &&
+      !(btm_sec_cb.pairing_flags & BTM_PAIR_FLAGS_PIN_REQD) &&
       (p_dev_rec->hci_handle == HCI_INVALID_HANDLE) && (!btm_sec_cb.security_mode_changed)) {

BTM_PAIR_FLAGS_PIN_REQD is set in btm_sec_pin_code_request() immediately before the UI callback
and cleared when pairing returns to idle, so it tracks exactly "a controller PIN code request is
outstanding". When it is set, the pre-fetch branch is skipped and control falls through to
btsnd_hcic_pin_code_req_reply() — which is what stock Android 16 does in the identical situation.

Note the branch also calls btsnd_hcic_write_auth_enable(true), which is no longer reached on this
path. Stock does not send Write_Authentication_Enable at this point either, which is at least mild
evidence that dropping it here is correct rather than merely harmless. If it turns out to matter,
the alternative is to keep the branch and answer the outstanding request inside it — I sketched that
variant in the previous comment.

Suggested order: crDroid first, AOSP afterwards

The affected code is identical in AOSP, LineageOS and crDroid, so the fix ultimately belongs
upstream in platform/packages/modules/Bluetooth on android-review.googlesource.com. Everything
downstream would then pick it up on the next merge.

That said, I would suggest landing it in crDroid first.

If someone provides me a version I can test it against the same HW.

So: try it in crDroid, confirm it against the failure captures already attached here, then submit
the same commit upstream with the test results in hand.

0001-Bluetooth-reply-to-outstanding-PIN-code-request.patch