BLE连接过程分析及异常断开0x3e错误原因分析

我们知道BLE通信过程是建立在连接基础之上的，按角色不同可以分为蓝牙主设备、蓝牙从设备，也叫中央设备和外围设备。以下简称为主机和从机。一次蓝牙通信，通常由主机发起，从机响应。我在调试蓝牙主机程序的过程中，发现经常会出现“秒断”的现象，即主机连接上从机，然后立马又断开了，断开原因是0x3e。经过查找资料和抓包分析，终于搞清楚了发生这个现象的原因。

        先看下BLE核心规范《 Core_v4.2》中对0x3e的断开原因是怎么说明的，在文档的385页可以找到相关描述：

        从字面意思看，是非常笼统的，意思发起了一个连接，但这个连接建立失败了。要想弄清楚这个问题的原因，必须要对蓝牙的连接过程有所了解。下面就结合BLE核心规范《 Core_v4.2》来看一下蓝牙的连接过程。在这个文档的第144页，可以找到和连接过程相关的描述：

        上图中，设备A是蓝牙主机，B是蓝牙从机。BLE的连接过程，大致分为6个步骤：

1）主机进入连接态，侦听待连接设备的广播包。如果在指定时间内没侦听到，会导致连接超时，这个时间由开发者指定。

2）主机成功接收到从机的广播包。

3）主机发送一个连接请求包。

4）主机发出连接请求包后，不管从机有没有收到，都会立即转入连接状态，同时报给用户层一个“已连接上”的消息，也就是图中的4A。如果从机能收到这个连接请求包，则从机也立即转入连接状态，并报给用户层一个“已连接上”的消息。如果从机未能收到连接请求包，则不会发4B的消息。

5）主机随即发送一个同步包。

6）从机收到同步包后，回给主机一个同步包，然后不停循环5和6两个步骤，连接才是真正建立了。如果5和6任何一个包丢失，都会导致连接建立失败，报0x3e的断开原因。

        知道了BLE连接的详细过程，再结合抓包工具抓取连接过程的数据包分析，可以很容易发现，通常是丢失第5步或者第6步的数据包，导致连接建立失败。而这两个包丢失，通常发生在周围存在很多蓝牙设备，导致信道十分拥挤的情况下。通过在空旷无多余蓝牙设备的地方实验发现，出现这个现象的概率大大降低，由此验证了这个推论。当周围蓝牙设备不可避免地过多时，应用层可以通过多次重连来规避这个问题。
————————————————
版权声明：本文为CSDN博主「f大熊」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fun_tion/article/details/83722034