connect 命令有回复，但没有connect up或者disconnect的ind过来

[YaTr_3516311]

Hi,

我在测试蓝牙connect的稳定性的时候，发现status = wiced_bt_gatt_le_connect( addr, addr_type,BLE_CONN_MODE_HIGH_DUTY, WICED_TRUE );发了以后，status是回复的success的，但是GATT_CONNECTION_STATUS_EVT消息没有过来。

如下是我的测试情况：

1. master A(scan)， slaverB(advertising), A搜到B后，就会去connect，然后B汇报数据发送给A,发送完后B disconnect这个连接。然后依次循环

2. 我发现一开始是正常的，但是跑了一段时间后，A去connect B,但是B和A的connection up的消息没有过来，也没有过来任何其他的消息（一开始我是怀疑B有问题，然后用手机去连接了一下，发现可以正常连接）

我是通过wiced6.2编译的程序，如下是我的问题

1. 如果发送wiced_bt_gatt_le_connect的命令，一定会有GATT_CONNECTION_STATUS_EVT的消息过来吗？

2. 我发现了一个现象，正常情况下发送connect的命令后，会过来hci_control_management_callback 0x13的消息（即BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT），然后就会有connect up/connect down过来。但是如果发生connect命令没有connect up/connect down过来的问题的时候，发送connect的命令，不会有BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT的消息过来。不知道是什么原因

[Charles_Lai]

Hi，先请问一下您使用的是什么型号的板子?

[YaTr_3516311]

cybt343026-01.这个问题挺严重的，希望能尽快解决。

并且，如果发了connect命令，加了10s的保护（timeout的时候调用wiced_bt_gatt_cancel_connect进行测试），然后再去connect的话，还是不能connect成功

[YaTr_3516311]

请问有啥进展吗

[YaTr_3516311]

这个问题能优先看一下吗

[Charles_Lai · Accepted solution]

Hi,

先请问一下，您说的“status是回复的success的”是指哪里的结果呢？是不是指WICED_BT_GATT_SUCCESS？

您问题的范畴内，应该只有wiced_bt_gatt_status_t这个数据类型（GATT Status Codes）里面有WICED_BT_GATT_SUCCESS的枚举值的。

因为wiced_bt_gatt_le_connect()函数return的不是wiced_bt_gatt_status_t。在您问题的范畴内，应该只有你的wiced_bt_gatt_cback_t回调函数才会返回这个数据类型。然而您的回调函数应该是您自己编写的，所以暂不能确定为何会返回WICED_BT_GATT_SUCCESS。

1)

wiced_bt_gatt_le_connect命令执行后，根据协议的要求，协议栈会产生一个GATT操作执行的回执事件，并通过你的wiced_bt_gatt_cback_t回调函数进行捕获。所以GATT_CONNECTION_STATUS_EVT的消息是应该要被协议栈产生并被捕获的。

如果没有，可能存在某些深层原因或者人为因素。

2)

BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT事件是在Connection建立中需要处理的事件。

在多次链路建立和拆除后，有时候它会存在异常。即某一方的协议栈会认为连接还没拆除或者已经建立。这时候继续在各层面发送connect都应该会出现问题，比如BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT没有被拉起等。

蓝牙的链路连接是比较容易出现问题的，因为它采用的设计思路就是弱维护的，并总倾向于认为连接正常（因为它是被设计在嘈杂和需要频繁睡眠和保持低功耗的环境中工作的），所以频繁的建立和拆除连接会出现问题，而且不好排查（因为原因通常隐秘和不能完全复现等），实际原因可能是某些标志位或数据残留造成的。

你遇到的采用别的设备再次连接该问题设备会发现又能建立连接这个现象，是存在的。这是因为控制器在接受一个完全不同的设备的连接请求时，它会知道自己之前的连接肯定丢失了（不然新的连接是不能够被传进来的，因为一般情况下连接只有一个），所以它便会重置一些之前遗留的cache并重新初始化，所以连接就能正常建立了。而您一直采用先前的设备在反复拆除连接并重新连接时，是不会触发这些的，因为这时候对方设备会倾向认为你还在上一次的连接中，并认为你只是在上次连接中恢复过来，并不是真的要发起新的连接。

问题的调查结果大概就是这样。总体上没有什么排查手段和解决办法，并且这个问题很多时候也跟芯片无关，它就是蓝牙通信本身会（允许）存在的。只能寄托于更好的系统层设计，采用更面向蓝牙协议推荐场景的设计，或在每次拆除链接后都重置协议栈等方法，来杜绝这类问题。

<<<<<<<<<<<<<>>>>>>>>>>>>>

Sincere regards from​ C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>