[参考译文] CC2642R：绑定后无法连接到配置为外设的器件

我实际上看不到 Wireshark 日志上载正确、是否有附加文件的技巧？  

已创建一个驱动器链接以解决此问题：  

先绑定后连接失败：

https://sendum1-my.sharepoint.com/:u:/g/personal/ben_tuline_sendum_com/EY8hgVpT2U5ApgeNBGHLujsBDd2NFduyau3mrsdFNDJm0w?e=jfUzbq

安娜到安娜：

https://sendum1-my.sharepoint.com/:u:/g/personal/ben_tuline_sendum_com/EV9I1zqE_flLv0NCb1GvATgBQZcF5h53Fuy2ySLcq3vFKg?e=LagVha 

您好 Ben、

感谢您发帖。

我已通知 BLE 团队进行进一步评论。

谢谢、
Toby

您好 Ben、

有关信息、我无法对监听器日志进行解码、因为它需要我们无法访问的插件。

为了缩小问题的范围、我建议检查更改 CC2642R 使用的地址模式是否有帮助。 为此、您可以在 CCS 工程中使用 SysConfig 修改器件使用的地址模式。 在这里、我建议使用"公共地址"进行首次测试。

让我们及时了解最新信息、

此致、

您好、Cl é ment、

我们已经尝试了所有 ADDRMODE 设置、在 RPA 上看到了与公共 ID 相同的问题。 默认情况下、我们使用公共地址、  

如果有用、这里是 CC2642R 忽略的单个数据包的扩展版本。  

如果信息不足、您会建议您使用什么数据包监听器  

您好！

感谢您提供的详细信息。 您是否想提供有关 connect_IND 数据包的详细信息(这似乎是第一个没有被器件应答的数据包)？
如果可能、我希望看到有效的 CONNECT_IND 数据包与失败的数据包之间的差异。

例如、您可以将 www.ti.com/.../用作监听器。

另一种探索方法是 CC2642R 是否启用了某些地址过滤(允许或拒绝列表-在白名单和黑名单之前调用)。 在这种情况下、它可以解释器件为何不应答连接请求。

此致、

以下是一些 CONNECT_IND 消息、以防其有用

出现故障之前的 CONNECT_IND。  

粘结时发生的 CONNECT_IND：

未尝试绑定的正常连接上发生的 CONNECT_IND：

我将尝试设置该监听器、但希望这现在可以正常工作。 我还将查看是否实现了地址过滤。 我不会假设、因为只要我们尚未绑定、连接到 CC2642R 就可以正常工作。  

您好！

感谢您提供的元素。

我提到过、始终使用 CC2642R 的公有地址来建立连接(请参阅 RxAdd)。 如果外设(CC2642R)启用了隐私保护、则情况不正确。 这显然是由另一个供应商 https://github.com/zephyrproject-rtos/zephyr/pull/6417修复的问题
由于我无法访问您的设备所使用的固件的详细信息、我是否可以要求您验证此修复程序是否已应用于您的软件？

此致、

我不认为已经应用了该修复、固件使用的是旧版本的 Nordic Soft Device。 但是、如果我们认为情况可能是这样、我可以再次检查。  

我检查了隐私设置、看起来像 我们设置了 ADDRMODE_PUBLIC、我的理解是、为了实现隐私、我们需要将地址模式设置为 ADDRMODE_RP_ATH_PUBLIC_ID、以便根据 https://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr.html?highlight=gap#null 启用隐私。 因此、我猜可能还有其他事情发生。  

您好！

在进一步调试之前、请确保使用适用于所有相关器件的最新软件版本。 像你一样、我相信其他事情正在发生、我希望确保我们不会尝试修复已经修复的问题。

此致、

您好、Clement、是的、我们一直在使用最新6.40 SDK 中的简单外设示例来重现此问题。 但是、我们的定制应用程序是在一段时间前在2.40 SDK 上启动的。  

此外、我们更倾向于尝试在此时获取信息、而不是修复。 我们可能有多种方法来实现这一目标、从而使我们的产品能够运行。 我们真正希望大家了解 SDK 是否应响应我们显示的消息、这些 Wireshark 日志中将忽略这些消息。  

您好 Ben、  

我知道。  
目前、我无法确定器件是否应该或不应该在这里回答。 正如我所提到的，有一些对我来说似乎不正确的因素，我建议首先处理这些因素。  

如果您有兴趣考虑其他方法、或者提供新数据点以了解问题的方法、我建议尝试使用不同的中央设备进行绑定。 例如、您可以尝试使用智能手机或 TI 器件(CC2640R2或 CC2642R)作为中央设备。 然后、目标是收集蓝牙跟踪并与最初收集的跟踪进行比较。  

我希望这将有所帮助、  

此致、  

您好 Clement、  

我们尝试了一款智能手机作为一个中央设备、它运行良好。 它在粘接后能够连接。 但是、它没有发送 CC2642R 忽略的消息。  

我不太清楚如何强制不同的中心发送那些被忽略作为比较点的相同消息。 最好能获得一些测试建议。 我希望 Wireshark 日志足以确定 CC2642R 是否出现错误行为。  

此外、仅供参考、其他人可能会从我们的末尾很快接管此问题  

您好！

感谢大家的观看。

如果可以、我怀疑电话或任何其他中央设备可能会跳过 CONN_IND 数据包的发射。 如果未清除、则忽略的数据包为 CONN_IND、之后忽略的所有数据包(ATT 请求)仅是第一个数据包被忽略的结果。

此致、