1、 在使用 EN-Dongle 捕获和解析广播包之前，我们先了解一下 BLE 报文的结构，之后，再对捕获的广播包进行分析。在学习 BLE 的时候，下面两个文档是极其重要的，这是 SIG 发布的蓝牙的核心协议和核心协议增补。 核心协议 Core_v4.2。 核心协议增补 CSS v6。虽然这两个文档是蓝牙技术的根本，但是遗憾的是：通过这两个文档学习蓝牙并不是那么容易的，阅读和理解起来很费力。尤其是初学者在阅读这两个文档的时候，感觉无从下口。所以，本文在分析报文的过程中，会明确指出协议文档在什么地方定义了他们，让我们有目的的去查阅协议文档，做到知其然也知其所以然，这样，学习起来就会轻松很多。1. B
2、LE 报文结构BLE 报文结构如下，他由下图所示的各个域组成。因为有的域的长度超过了一个字节，所以在传输的过程中就涉及到多字节域中哪个字节先传输的问题，BLE 报文传输时的字节序和比特序如下： 字节序：大多数多字节域是从低字节开始传输的。 注意，并不是所有的多字节域都是从低字节开始传输的。 比特序：各个字节传输时，每个字节都是从低位开始。图 1：BLE 报文结构1.1 前导前导是一个 8 比特的交替序列。他不是 01010101 就是 10101010，取决于接入地址的第一个比特。 若接入地址的第一个比特为 0：01010101 若接入地址的第一个比特为 1：10101010接收机可以根据前导
3、的无线信号强度来配置自动增益控制。1.2 接入地址接入地址有两种类型：广播接入地址和数据接入地址。 广播接入地址： 固定为 0x8E89BED6，在广播、扫描、发起连接时使用。 数据接入地址： 随机值 ，不同的连接有不同的值。在连接建立之后的两个设备间使用。对于数据信道，数据接入地址是一个随机值，但需要满足下面几点要求：1) 数据接入地址不能超过 6 个连续的“0”或“1”。2) 数据接入地址的值不能与广播接入地址相同。3) 数据接入地址的 4 个字节的值必须互补相同。4) 数据接入地址不能有超 24 次的比特翻转(比特 0 到 1 或 1 到 0，称为 1 次比特翻转)。5) 数据接入地址的
4、最后 6 个比特需要至少两次的比特翻转。6) 符合上面条件的有效随机数据接入地址大概有 231 个。1.3 报头1.3.1 广播报文报头报头的内容取决于该报文是广播报文还是数据报文。广播报文的报头如下图所示：图 2：广播报文报头广播报文的报头包含 4bit 广播报文类型、2bit 保留位、1bit 发送地址类型和1bit 接收地址类型。1) 广播报文类型Core_v4.2 的 2583 页描述了广播报文类型，共有 7 种类型，如下图所示。图 3：广播报文类型每种广播报文类型都具有不同的数据格式及行为。 Core_v4.2 的 2584 页的2.3.1 节详细的描述了各个广播报文类型 ， 大家可
5、以阅读此章节进一步了解。2) 发送地址类型和接收地址类型发送地址类型和接收地址类型指示了设备使用公共地址(Public Address)还是随机地址(Random Address)。公共地址和随机地址的长度一样，都包含 6 个字节共 48 位。BLE 设备至少要拥有这两种地址类型中的一种，当然也可以同时拥有这两种地址类型。 公共地址(Public Address)公共地址由两部分组成，如下图。公共地址由制造商从 IEEE 申请，由 IEEE 注册机构为该制造商分配的机构唯一标识符 OUI(Organizationally Unique Identifier)。这个地址是独一无二，不能修改的。
6、Core_v4.2 P2576 的 1.3.1 节描述了公共地址 。图 4：公共地址结构 随机地址随机地址有包含两种：静态地址（Static Device Address）和私有地址（PrivateDevice Address）。 Core_v4.2 P2577 的 1.3.2.1 节描述了静态地址。图 5：静态地址格式静态地址有如下要求：a) 静态地址的最高 2 位有效位必须是 1。b) 静态地址最高 2 位有效位之外的其余部分不能全为 0。c) 静态地址最高 2 位有效位之外的其余部分不能全为 1。在私有地址的定义当中，又包含了两个子类：不可解析私有地址（Non-resolvable Pr
7、ivate Address）和可解析私有地址(Resolvable Private Address，RPA)。nRF51822 使用的是静态地址，芯片在出厂时已经设置好了 48位地址，我们可以从下面两个寄存器读出地址类型和地址。a) DEVICEADDRTYPE 寄存器。DEVICEADDRn寄存器：包含 DEVICEADDR0和 DEVICEADDR1两个寄存器。图 6：地址类型寄存器图 7：地址寄存器1.4 长度 广播报文：长度域包含 6 个比特，有效值的范围是 637。 数据报文：长度域包含 5 个比特，有效值的范围是 031。广播报文和和数据报文的长度域有所不同，主要原因是：广播报文除
8、了最多31 个字节的数据之外，还必须要包含 6 个字节的广播设备地址。6+31=37，所以需要 6 比特的长度域。再次强调：广播时必须要包含 6 个字节的广播设备地址。1.5 数据(AdvData)广播和扫面响应的数据格式如下图所示，由有效数据部分和无效数据部分组成。图 8：广播和扫描响应的数据格式1) 有效数据部分：包含 N 个 AD Structure，每个 AD Structure 由Length，AD Type 和 AD Data 组成。其中： Length：AD Type 和 AD Data 的长度。 AD Type：指示 AD Data 数据的含义。问题来了，我们怎么知道有哪些 A
9、D Type？他们又表示什么意义？可以通过下面 2 种方式查看 AD Type 和他们表示的意义。 从官网查询，但是需要是会员才可以查询。https:/www.bluetooth.org/Technical/AssignedNumbers/generic_access_profile.htm 查看 Nordic 的 SDK 中的定义，AD type 的定义在程序的“ble_gap.h”头文件中。定义如下：1 #define BLE_GAP_AD_TYPE_FLAGS 0x01 /* Flags for discoverability. */ 2 #define BLE_GAP_AD_TYPE_
10、16BIT_SERVICE_UUID_MORE_AVAILABLE 0x02 /* Partial list of 16 bit service UUIDs. */ 3 #define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE 0x03 /* Complete list of 16 bit service UUIDs. */ 4 #define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_MORE_AVAILABLE 0x04 /* Partial list of 32 bit service UUIDs. */ 5 #d
11、efine BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE 0x05 /* Complete list of 32 bit service UUIDs. */ 6 #define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE 0x06 /* Partial list of 128 bit service UUIDs. */ 7 #define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLETE 0x07 /* Complete list of 128 bit s
12、ervice UUIDs. */ 8 #define BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME 0x08 /* Short local device name. */ 9 #define BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME 0x09 /* Complete local device name. */10 #define BLE_GAP_AD_TYPE_TX_POWER_LEVEL 0x0A /* Transmit power level. */11 #define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE 0x0
13、D /* Class of device. */12 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C 0x0E /* Simple Pairing Hash C. */13 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R 0x0F /* Simple Pairing Randomizer R. */14 #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_TK_VALUE 0x10 /* Security Manager TK Value. */15 #define
14、 BLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS 0x11 /* Security Manager Out Of Band Flags. */16 #define BLE_GAP_AD_TYPE_SLAVE_CONNECTION_INTERVAL_RANGE 0x12 /* Slave Connection Interval Range. */17 #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT 0x14 /* List of 16-bit Service Solicitation UUIDs.
15、*/18 #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT 0x15 /* List of 128-bit Service Solicitation UUIDs. */19 #define BLE_GAP_AD_TYPE_SERVICE_DATA 0x16 /* Service Data - 16-bit UUID. */20 #define BLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS 0x17 /* Public Target Address. */21 #define BLE_GAP_AD_TYPE
16、_RANDOM_TARGET_ADDRESS 0x18 /* Random Target Address. */22 #define BLE_GAP_AD_TYPE_APPEARANCE 0x19 /* Appearance. */23 #define BLE_GAP_AD_TYPE_ADVERTISING_INTERVAL 0x1A /* Advertising Interval. */ 24 #define BLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_ADDRESS 0x1B /* LE Bluetooth Device Address. */25 #defin
17、e BLE_GAP_AD_TYPE_LE_ROLE 0x1C /* LE Role. */26 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C256 0x1D /* Simple Pairing Hash C-256. */27 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R256 0x1E /* Simple Pairing Randomizer R-256. */28 #define BLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID 0x20 /* Servic
18、e Data - 32-bit UUID. */29 #define BLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID 0x21 /* Service Data - 128-bit UUID. */30 #define BLE_GAP_AD_TYPE_3D_INFORMATION_DATA 0x3D /* 3D Information Data. */31 #define BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA 0xFF /* Manufacturer Specific Data. */1.6 校验 BLE 采用的是
19、 24 位 CRC 校验。CRC 对报头、长度和数据进行计算。24 位CRC 的生成多项式如下：2. 广播包解析通过上文的描述，我们对 BLE 广播包有了大致的了解，接下来我们用 EN-Dongle 捕获一个心率计的广播包，通过对实际广播包的分析来理解 BLE 报文结构和广播。广播包捕获实验的硬件连接如下。图 9：硬件连接2.1 心率计程序下载2.1.1 下载协议栈SoftDevice 必须使用 nRFgo Studio 下载，打开 nRFgo Studio，切换到“Program SoftDevice”选项卡。点击“Browse” 按钮打开 SoftDevice 的HEX 文件（位于“BLE
20、 实验蓝牙协议栈(SoftDevice)目录下的” s110）。点击“Program”下载程序。2.1.1 下载应用程序应用程序可以用 nRFgo Studio 下载，也可以在 MDK 中直接下载调试，在这里我们用 nRFgo Studio 下载。切换到“Program Application”选项卡。点击“Browse”按钮打开应用程序的 HEX 文件（位于“BLE 实验 ble_app_beacon pca10028s110arm5_build”目录下的nrf51822_xxaa_s110.hex）。点击“Program” 下载程序。2.2 捕获广播包按照 蓝牙 4.0BLE 抓包(一)中
21、的描述进行抓包，下面是我们捕获一个心率计的广播包。图 10：捕获的心率计广播包图 11：查看广播包传输的数据2.3 分析广播包为了方便分析，我们先取出这个广播包实际传输的数据，如图 9 中所示。心率计完整的广播报文如下：D6 BE 89 8E 40 21 60 BF 8A B9 CD C5 0B 09 4E 6F 72 64 69 63 5F 48 52 4D 03 19 41 03 02 01 06 07 03 0D 18 0F 18 0A 18 EF A6 F02.3.1 接入地址D6 BE 89 8E：接入地址，对广播来说是固定值。注意一下这里的字节序，接入地址传输时是低字节在前的。2.
22、3.2 PDUq 40：广播报文报头。l bit0bit3 是 0000，说明广播类型是 ADV_IND，即通用广播指示。l bit7(RxAdd)是 0， bit7(TxAdd)是 1，说明使用的是随机地址(random address)。 Core_V4.2 P2584 的 2.3.1 有详细的描述。q 21：长度，表示这个广播的长度是 33 个字节。q 9A 3F 20 FB 74 C5：设备地址，这里使用的是随机静态地址。接下来就是广播包最重要的部分了，称之为 AdvData，前面我们说过 AdvData是 N 个 AD Structure 组层成，每个 AD Structure 的格
23、式都是 Length |AD Type|AD Data 组成。0B 09 4E 6F 72 64 69 63 5F 48 52 4D 03 19 41 03 02 01 06 07 03 0D 18 0F 18 0A 18第一个字节 0B 表示第一个 AD Structure 的长度是 11 个字节，即第一个 AD Structure 是由 0B 加上紧跟着 0B 后面的 11 个字节组成，因此，第一个 AD Structure 是：0B 09 4E 6F 72 64 69 63 5F 48 52 4D表 1：第 1 个 AD Structure 的意义Length AD Type AD Da
24、ta0B 09 4E 6F 72 64 69 63 5F 48 52 4D11 字节 AD type 为“完整的本地名称”程序中定义的为”Nordic_HRM” 对应的十六进制就是 4E 6F 72 64 69 63 5F 48 52 4D第 2 个 AD Structure 是：03 19 41 03表 2：第 2 个 AD Structure 的意义LengthAD Type AD Data03 19 41 033 字节 AD type 为“外观特性”外观特性是一个 16 位的数值，由 SIG 定义，用来列举设备的外观样式，指示设备是普通手机，手环什么的。第 3 个 AD Structur
25、e 是：02 01 06表 3：第 3 个 AD Structure 的意义LengthAD Type AD Data02 01 062 字节 AD type 为“Flag”flag 说明了物理连接功能，比如有限发现模式，不支持经典蓝牙等。l bit 0: LE 有限发现模式。l bit 1: LE 普通发现模式。l bit 2: 不支持 BR/EDR。l bit 3: 对 Same Device Capable(Controller)同时支持 BLE 和 BR/EDR。l bit 4: 对 Same Device Capable(Host) 同时支持 BLE 和 BR/EDR。bit 57:
26、 预留。第 4 个 AD Structure 是：07 03 0D 18 0F 18 0A 18表 4：第 4 个 AD Structure 的意义LengthAD Type AD Data07 03 0D 18 0F 18 0A 187 字节 AD type 为“16bit Service uuid 列表”该设备支持的完整的 16bit Service uuid 列表。l 180D：Heart Rate service UUID(心率服务 UUID)l 180F：Battery service UUID(电池服务 UUID)l 180A：Device Information service
27、UUID(设备信息服务 UUID)16bit UUID：128 位的 UUID 相当长，设备间为了识别数据的类型需要发送长达 16 字节的数据。为了提高传输效率，蓝牙技术联盟(SIG)定义了一个称为“UUID 基数”的 128 位通用唯一识别码，结合一个较短的 16 位数使用。二者仍然遵循通用唯一识别码的分配规则，只不过在设备间传输常用的 UUID 时，只发送较短的 16 位版本，接收方收到后补上蓝牙 UUID 基数即可。蓝牙 UUID 基数如下：00000000 0000 1000 8000 008059B34FB如要发送的 16 位 UUID 为 0x2A01，完整的 128 的 UUID
28、 便是：00002A01 0000 1000 8000 008059B34FB低功耗蓝牙使用的那部分 UUID 被分为下列几组：l 0x1800 0x26FF：用作服务类通用唯一识别码。l 0x2700 0x27FF：用于标识计量单位。l 0x2800 0x28FF：用于区分属性类型。l 0x2900 0x29FF：用作特性描述。l 0x2A00 0x7FFF：用于区分特性类型。在程序的“ble_srv_common.h”文件中定义了 16bit service UUID，如下，当然也可以在 SIG 官网上查询：1 #define BLE_UUID_ALERT_NOTIFICATION_SER
29、VICE 0x1811 /* Alert Notification service UUID. */ 2 #define BLE_UUID_BATTERY_SERVICE 0x180F /* Battery service UUID. */ 3 #define BLE_UUID_BLOOD_PRESSURE_SERVICE 0x1810 /* Blood Pressure service UUID. */ 4 #define BLE_UUID_CURRENT_TIME_SERVICE 0x1805 /* Current Time service UUID. */ 5 #define BLE_U
30、UID_CYCLING_SPEED_AND_CADENCE 0x1816 /* Cycling Speed and Cadence service UUID. */ 6 #define BLE_UUID_DEVICE_INFORMATION_SERVICE 0x180A /* Device Information service UUID. */ 7 #define BLE_UUID_GLUCOSE_SERVICE 0x1808 /* Glucose service UUID. */ 8 #define BLE_UUID_HEALTH_THERMOMETER_SERVICE 0x1809 /*
31、 Health Thermometer service UUID. */ 9 #define BLE_UUID_HEART_RATE_SERVICE 0x180D /* Heart Rate service UUID. */10 #define BLE_UUID_HUMAN_INTERFACE_DEVICE_SERVICE 0x1812 /* Human Interface Device service UUID. */11 #define BLE_UUID_IMMEDIATE_ALERT_SERVICE 0x1802 /* Immediate Alert service UUID. */12
32、 #define BLE_UUID_LINK_LOSS_SERVICE 0x1803 /* Link Loss service UUID. */13 #define BLE_UUID_NEXT_DST_CHANGE_SERVICE 0x1807 /* Next Dst Change service UUID. */14 #define BLE_UUID_PHONE_ALERT_STATUS_SERVICE 0x180E /* Phone Alert Status service UUID. */15 #define BLE_UUID_REFERENCE_TIME_UPDATE_SERVICE
33、0x1806 /* Reference Time Update service UUID. */16 #define BLE_UUID_RUNNING_SPEED_AND_CADENCE 0x1814 /* Running Speed and Cadence service UUID. */17 #define BLE_UUID_SCAN_PARAMETERS_SERVICE 0x1813 /* Scan Parameters service UUID. */18 #define BLE_UUID_TX_POWER_SERVICE 0x1804 /* TX Power service UUID. */2.3.3 校验EF A6 F0：24 位 CRC。24 位 CRC 的生成多项式如下，对 CRC 算法感兴趣的朋友可以研究一下：
