gfps/手机本来应该连主耳并且配对主耳的，但是手机却连了附耳，并且尝试配对附耳.md

手机本来应该连主耳并且配对主耳的，但是手机却连了附耳，并且尝试配对附耳

\

hi hao:

The provider is TWS earbuds and has two components.

The specifications state that if a pairing request is not received within 10 seconds after receiving the KBP request, we can manually disconnect the connection.
Our headset also follows this procedure. Please check why the pairing process wasn't initiated immediately after the phone sent the KBP request.

primary address：DD 24 DD 97 DD 00
secondary address： AA 24 AA 97 AA 00



//primary log: send kbp response
        Line 104464:  0004415  12-15#16:32:19.890  008  0059128.956  [APP] !**gfps_send_kbp_response_le: raw response 02 40 02 DD 24 DD 97 DD 00 AA 24 AA 97 AA 00 E3, encrypt response FA E9 BA 53 23 56 FA 0A 55 E1 2E A6 F1 84 14 5A

//primary not receive pairing request, and disconnect ACL link  
Line 121857:  0001804  12-15#16:32:29.865  238  0069100.729  [APP] app_gfps_timer_timeout_cb: timer_id 2, timer_chann 0
        Line 121959:  0001906  12-15#16:32:29.881  085  0069117.146  [APP] app_gfps_le_disconnect_cb: conn_id 0, local_disc_cause 17, disc_cause 0x116

//it seems seeker connected to the secondary bud?

can you help see the reason?

\

hi hao:
XX:XX:XX:XX:AA:00 is secondary buds,
I think the phone shouldn't connected to the secondary buds,
because after the primary buds(address: DD 24 DD 97 DD 00) send kbps response to phone,
it seems the phone directly connects to the secondary buds(address: AA 24 AA 97 AA 00).

//primary buds log: 16:32:19 send kbp response to phone
        Line 104464:  0004415  12-15#16:32:19.890  008  0059128.956  [APP] !**gfps_send_kbp_response_le: raw response 02 40 02 DD 24 DD 97 DD 00 AA 24 AA 97 AA 00 E3, encrypt response FA E9 BA 53 23 56 FA 0A 55 E1 2E A6 F1 84 14 5A

//primary buds not receive create bond info, and disconnect ACL link  
Line 121857:  0001804  12-15#16:32:29.865  238  0069100.729  [APP] app_gfps_timer_timeout_cb: timer_id 2, timer_chann 0
        Line 121959:  0001906  12-15#16:32:29.881  085  0069117.146  [APP] app_gfps_le_disconnect_cb: conn_id 0, local_disc_cause 17, disc_cause 0x116

\

Hi Danni,

After checking bluetooth manager log, looks like still in the bonding process with xx:xx:xx:xx:AA:00. Then, it start next round pairing.

// After 
shim::legacy::btm  2025-12-15 16:32:19.164 CBACK  Bond state changed       : xx:xx:xx:xx:aa:00 bt_status:fail bond_state:0 reason:HCI_SUCCESS
shim::legacy::btm  2025-12-15 16:32:19.199 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_IDLE => SMP_STATE_WAIT_APP_RSP
shim::legacy::btm  2025-12-15 16:32:19.200 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_WAIT_APP_RSP => SMP_STATE_PAIR_REQ_RSP
shim::legacy::btm  2025-12-15 16:32:19.266 API    Get connection state     : xx:xx:xx:xx:aa:00 connected:T classic_encrypted:F le_encrypted:F
shim::legacy::btm  2025-12-15 16:32:19.290 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_PAIR_REQ_RSP => SMP_STATE_PUBLIC_KEY_EXCH
shim::legacy::btm  2025-12-15 16:32:19.805 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_PUBLIC_KEY_EXCH => SMP_STATE_SEC_CONN_PHS1_START
shim::legacy::btm  2025-12-15 16:32:19.811 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_SEC_CONN_PHS1_START => SMP_STATE_WAIT_COMMITMENT

// Start subsequent pairing
shim::legacy::btm  2025-12-15 16:32:20.044 ACL    Allow connection from    : xx:xx:xx:xx:fd:93[random] Le
shim::legacy::btm  2025-12-15 16:32:20.075 ACL    Connection successful    : xx:xx:xx:xx:fd:93[random] Le
shim::legacy::btm  2025-12-15 16:32:20.149 API    Get connection state     : xx:xx:xx:xx:fd:93 connected:T classic_encrypted:F le_encrypted:F

// The interaction with XX:XX:XX:XX:AA:00 persists unexpectedly.
shim::legacy::btm  2025-12-15 16:32:20.326 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_WAIT_COMMITMENT => SMP_STATE_WAIT_NONCE
shim::legacy::btm  2025-12-15 16:32:20.405 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_WAIT_NONCE => SMP_STATE_SEC_CONN_PHS2_START
shim::legacy::btm  2025-12-15 16:32:20.406 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_SEC_CONN_PHS2_START => SMP_STATE_WAIT_NONCE
shim::legacy::btm  2025-12-15 16:32:20.406 SMP    Security state changed   : xx:xx:xx:xx:aa:00[public] SMP_STATE_WAIT_NONCE => SMP_STATE_WAIT_APP_RSP
shim::legacy::btm  2025-12-15 16:32:20.407 CBACK  Bond state changed       : xx:xx:xx:xx:aa:00 bt_status:success bond_state:1 reason:HCI_SUCCESS
shim::legacy::btm  2025-12-15 16:32:20.407 CBACK  SSP ble request          : xx:xx:xx:xx:aa:00 name:'' BT_SSP_VARIANT_CONSENT

Regarding why the Pixel phone re-creates a bond immediately after the Validator unpairs, I believe this is related to a BT known issue that should be fixed in the latest image.
However, I'm unsure about the failure rate.
Is this bug easily reproducible on your side? And, more importantly, is it blocking your testing?
If it is, I will need to find a workaround to prevent it.

\