weefnn/gfps
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

gfps: 添加认证测试和FAQ 20260505
All checks were successful
Sync To /home/ubuntu/gfps / sync (push) Successful in 2s
Details

Browse Source 
Change-Id: I71e676b997159a141ca07d16f82a73b45f4b2410
This commit is contained in:
danni_dong
2026-05-05 19:24:08 +08:00
parent 2ed168dcf8
commit bdbb2527e6
1943 changed files with 10585 additions and 434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

78
手机本来应该连主耳并且配对主耳的，但是手机却连了附耳，并且尝试配对附耳.md Normal file
View File

@@ -0,0 +1,78 @@
# 手机本来应该连主耳并且配对主耳的，但是手机却连了附耳，并且尝试配对附耳
![](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.
\