|
查看: 125|回复: 3

[BLE SDK] TC321X Master角色LE Secure Connections配对失败,secure_conn始终为0

[复制链接]

1

主题

1

回帖

21

积分

英勇黄铜

积分
21
发表于 2026-8-20 20:30:08 | 显示全部楼层 |阅读模式 来自 法国
Information
说明:   建议参照本版块置顶帖内容输入必要信息
芯片型号: TC321X
SDK及版本: tc_ble_single_sdk V3.4.3.0
背景
角色:Central/Master
基础代码:官方demo vendor/ble_feature_test/feature_privacy_master,移植到TC321X

使用的SMP配置
blc_smp_setSecurityLevel(LE_Security_Mode_1_Level_2);
blc_smp_enableSecureConnections(1);
blc_smp_setSecurityParameters(Non_Bondable_Mode, 0, 0, 0, IO_CAPABILITY_NO_INPUT_NO_OUTPUT);
blc_smp_setEcdhDebugMode(non_debug_mode);
blc_smp_central_init();
blm_host_smp_setSecurityTrigger(MASTER_TRIGGER_SMP_FIRST_PAIRING);

现象
配对每次都失败。GAP_EVT_SMP_PAIRING_BEGIN 报告 secure_conn=0(Legacy),尽管已明确启用SC。之后协议栈发送的是 Pairing Confirm(SMP code 0x03,属于Legacy流程),而不是SC流程中应有的 Public Key(0x0C)。对端(用Zephyr/nRF设备测试)因协议序列错误而拒绝连接。

收集到的证据(在 blm_host.c 中加入自定义instrumentation,在协议栈处理之前直接dump原始字节)
- 发送的 Pairing Request:auth_req 中确实包含SC bit(对端日志和我们自己的log都确认了这一点)
- 收到的 Pairing Response:03 00 08 10 00 00 → auth_req=0x08 → 对端也提出了SC
- 也就是说,双方都正确提出了SC,交换的字节在两边都是正确的——但协议栈还是决定走Legacy流程

重要对比点
在同一颗芯片/同一个库上,几乎相同的SC配置,在Peripheral角色下完全正常工作(blc_smp_peripheral_init()),包括官方demo feature_smp_security。问题看起来是Master角色特有的。

问题
在这个SDK里,Master角色下的SC配对是一个经过验证/测试过的路径吗?是否有一个未在文档中说明的、Master角色特有的步骤或调用是必须的?


56

主题

335

回帖

1303

积分

管理员

积分
1303
发表于 2026-8-21 09:34:29 | 显示全部楼层 来自 上海
https://doc.telink-semi.cn/doc/z ... n/?h=le+works#smp_2
如文档所述,master的SMP功能目前支持传统配对方式下的最高级别是LE security mode1 level2(传统配对Just Works方式)。
tc_ble_single_sdk master角色不支持SC,如需,请使用tc_ble_sdk

1

主题

1

回帖

21

积分

英勇黄铜

积分
21
 楼主| 发表于 2026-8-21 22:03:31 | 显示全部楼层 来自 法国
本帖最后由 GS7712 于 2026-8-21 23:02 编辑

感谢您的回复。


56

主题

335

回帖

1303

积分

管理员

积分
1303
发表于 2026-8-22 13:54:45 | 显示全部楼层 来自 上海

本版积分规则

关注公众号
Telink forum

相关侵权、举报、投诉及建议等,请发 E-mail:forum@telink-semi.com

Powered by Discuz! X5.0 © 2001-2026 Discuz! Team.|沪ICP备17008231号-1 |沪公网安备31011502403548号

在本版发帖返回顶部