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

![](images/手机本来应该连主耳并且配对主耳的，但是手机却连了附耳，并且尝试配对附耳_8462fc9f.jpg)

\

<span style="color: rgb(0,128,0);">hi hao:</span>\
\
<span style="color: rgb(0,128,0);">The provider is TWS earbuds and has two components.</span>\
\
**<span style="color: rgb(255,0,0);">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.</span>**\
**<span style="color: rgb(255,0,0);">Our headset also follows this procedure. Please check why the pairing process wasn't initiated immediately after the phone sent the KBP request.</span>**\
\
<span style="color: rgb(0,128,0);">primary address：DD 24 DD 97 DD 00</span>\
<span style="color: rgb(0,128,0);">secondary address： AA 24 AA 97 AA 00</span>\
\
\
\
**<span style="color: rgb(0,128,0);">//primary log: send kbp response</span>**\
<span style="color: rgb(0,128,0);">        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</span>\
\
**<span style="color: rgb(0,128,0);">//primary not receive pairing request, and disconnect ACL link  </span>**\
<span style="color: rgb(32,33,36);">Line 121857:  0001804  12-15#16:32:29.865  238  0069100.729  \[APP\] app_gfps_timer_timeout_cb: timer_id 2, timer_chann 0</span>\
<span style="color: rgb(32,33,36);">        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</span>\
\
**<span style="color: rgb(0,128,0);">//it seems seeker connected to the secondary bud?</span>**\
\
<span style="color: rgb(32,33,36);">can you help see the reason?</span>

\

<span style="color: rgb(32,33,36);">hi hao:\
**<span style="color: rgb(0,128,0);">XX:XX:XX:XX:AA:00 is secondary buds,</span>**\
**<span style="color: rgb(0,128,0);">I think the phone shouldn't connected to the secondary buds,</span>**\
**<span style="color: rgb(0,128,0);">because after the primary buds(address: DD 24 DD 97 DD 00) send kbps response to phone,</span>**\
**<span style="color: rgb(0,128,0);">it seems the phone directly connects to the secondary buds(address: AA 24 AA 97 AA 00).</span>**\
\
//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</span>

\

Hi Danni,

**<span style="color: rgb(0,128,0);">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.</span>**

    // 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

**<span style="color: rgb(0,128,0);">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.</span>**\
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.

\