Chinaunix首页 | 论坛 | 博客
  • 博客访问: 250194
  • 博文数量: 81
  • 博客积分: 325
  • 博客等级: 一等列兵
  • 技术积分: 595
  • 用 户 组: 普通用户
  • 注册时间: 2012-03-17 21:00
文章分类
文章存档

2016年(2)

2013年(33)

2012年(47)

我的朋友

分类: 嵌入式

2016-06-02 14:39:22

原文地址:BLE广播数据的抓包解析 作者:ifndef

前言:

报文由数据字节组成同时是按比特传输的,这就免不了牵涉到字节序的问题。

对于各个字节的传输,总是从最低位开始传输。如0x80是按00000001发送的,0x01是按10000000发送的。

同时大多数字节域又是从低字节开始发送的。如0x010203发送序列为110000000100000010000000

 

之所以说大多数,是因为并不是所有的数据都会从低字节发送从后面的抓取的广播报文中也能看不来。

另外由于抓包软件可能并不一定能完全知道哪些数据时从低字节开始发的,抓取的广播数据可能有一些需要按字节倒着读。

 

下面进入正题:

在链路层 BLE的广播报文分为如下几个部分。

 

|前导|接入地址|报头|长度|广播数据|校验|

一般抓包工具抓取到广播数据后显示出来的都会分段显示,所以你很容易看出各个段的数据,本文重要是 解析 广播数据段中的内容。

 

 

前导(1字节):不知道的可以理解为同步头,主要是用来配置接收机的自动增益控制。

接入地址(4字节):对于广播报文来说是固定的0x8e89bed6 (同时接入地址也决定前导的序列,在这里并不是重点,不做过多介绍)

报头(1字节)依次为广播报文类型(4bit),保留位(2bit),发送数据地址类型(1bit),接收地址类型(1bit)

长度(1字节): 指示广播数据的长度(广播地址AdvA+数据AdvData)

广播数据:       我们需要解析的数据段,后面会详细说明。

校验(3字节):  CRC校验

 

下面 Packet Sniffer抓到数据



从中可以明显的看出各个段的内容:

红色字段接入地址就是广播的固定接入地址0x8e89bed6(抓包软件未转换字节序)

报头字段中:

    广播类型是通用广播(Type0)

    地址类型都是publicTxAddRxAdd都为0)。

长度字段指示adv+AdvData长度

广播设备地址是我自己设定的

ble_gap_addr_t add={.addr_type=BLE_GAP_ADDR_TYPE_PUBLIC,

                    .addr={0x01,0x02,0x03,0x04,0x05,0x06}};

因为地址是48-bit address, LSB format.

所以真实地址为0x060504030201.

AdvDara中一大堆数据就是我们需要解析的。

下面是详细信息,其中有抓包软件加的帧头数据。







发现图片太小 就复制了一下内容
+----------------------------------------------------------+----------------- - - -
|     Packet sniffer frame header                            |
+--+-------------+-----------------------------+--------+
|info| Packet nbr| Time stamp                  | Length| Packet data
+--+-------------+-----------------------------+--------+----------------- - - -
| 01 | 04 00 00 00  | EB 01 B9 02 00 00 00 00   | 2D 00 | 2C D6 BE 89 8E 00 21 01 02 03 04 05 06 0B 09 4E 6F 72 64 69 63 5F 48 52 4D 03 19 34 12 02 01 06 07 03 0D 18 0F 18 0A 18 39 FE 57 2A A5

 

Packet data开始

 

2Cpacket  data总字节数

D6 BE 89 8E 为接入地址(字节序问题)

00为报头字段(通用广播类型,public地址)

21为长度字段的值,指示adv+AdvData的总字节数

01 02 03 04 05 06 为广播设备地址

 

之后便为重点需要解析的 AdvData 部分。首先还是需要知道这一部分的数据格式。

蓝牙说明书4.1中说明 数据格式为


|length|AD type|AD data|

 







Advdata 都是由这种格式的数据段组成。

Length即为一小段数据的长度

AD type指示 AD Data数据的含义。

AD type的定义如下,








下面继续分析 后面的数据

0B告诉我们这一小段的数据长度为11字节

09 4E 6F 72 64 69 63 5F 48 52 4D都属于这以部分

查上面的表 09指明AD type为完整的本地名称。 我定义的为”Nordic_HRM”十六进制就是4E 6F 72 64 69 63 5F 48 52 4D



接着后面 03代表接着的一小段数据位三个字节 那么后面的19 34 12都属于这一小段

19表示外观”  34 12代表外观。 (外观特性是SIG定义的一组值,用来表示设备是普通手机,手环什么的)

再后面是0201 06属于这段

01代表 FLAG flag说明了物理连接功能,比如有限发现模式,不支持经典蓝牙等

·         bit 0: LE 有限发现模式

·         bit 1: LE 普通发现模式

·         bit 2: 不支持 BR/EDR

·         bit 3: Same Device Capable(Controller) 同时支持 BLE BR/EDR

·         bit 4: Same Device Capable(Host) 同时支持 BLE BR/EDR

·         bit 5..7: 预留

06数据说明了 设备的连接功能为 普通发现模式并且不知道经典蓝牙



继续是  07 表明03 0D 18 0F 18 0A 18属于这一段

03查上面的表知道 后面的数据表示完整16bit uuid列表

    ble_uuid_t adv_uuids[] =

    {

        {0x180D,         BLE_UUID_TYPE_BLE},

        {0x180F,         BLE_UUID_TYPE_BLE},

        {0x180A,         BLE_UUID_TYPE_BLE}

    };

就是我设置的广播UUID

最后39 FE 57 表示CRC校验。

2A A5 应该是 抓包软件做的帧校验吧。

阅读(1538) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~