本文章主要讲下蓝牙串口协议SPP(Serial Port Profile)连接/接受数据/发送数据/断开连接的流程介绍,可能之前的写的底层文章你看的云里雾里,此小节就是开发从应用Profile层面来把整个地方串起来,让你们对协议栈有一个更深刻的认识。
本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下:
第一篇:蓝牙综合介绍 ,主要介绍蓝牙的一些概念,产生背景,发展轨迹,市面蓝牙介绍,以及蓝牙开发板介绍。
第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP,基于USB的H2等
第三篇:传统蓝牙controller介绍,主要介绍传统蓝牙芯片的介绍,包括射频层(RF),基带层(baseband),链路管理层(LMP)等
第四篇:传统蓝牙host介绍,主要介绍传统蓝牙的协议栈,比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。
第五篇:低功耗蓝牙controller介绍,主要介绍低功耗蓝牙芯片,包括物理层(PHY),链路层(LL)
第六篇:低功耗蓝牙host介绍,低功耗蓝牙协议栈的介绍,包括HCI,L2CAP,ATT,GATT,SM等
第七篇:蓝牙芯片介绍,主要介绍一些蓝牙芯片的初始化流程,基于HCI vendor command的扩展
第八篇:附录,主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。
另外,开发板如下所示,对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈,相信我,学完这一套视频你将拥有修改任何协议栈的能力(比如Linux下的bluez,Android下的bluedroid)。
-------------------------------------------------------------------------------------------------------------------------
CSDN学院链接(进入选择你想要学习的课程):
蓝牙交流扣扣群:970324688
Github代码:
入手开发板:
蓝牙学习目录:
--------------------------------------------------------------------------------------------------------------------------
在上面章节我们铺垫了很多底层协议,可能你们看的可能会云里雾里,此章节就是开发从应用Profile层面来把整个地方串起来,让你们对协议栈有一个更深刻的认识。此小节我们每个协议只是会讲解到一次raw data分析,其他的封包你们要反复参照之前讲解的协议来分析,如果一旦搞清楚,会对蓝牙协议栈交互有一个深刻的认识
本小节主要通过一个SPP的应用例程来测试开发板跟手机SPP交互的流程,其中流程包括:
分析工具:Ellisys(打开方式参照工具的使用)
分析封包:spp连接_发送_接受_断开.log(在资料中STM32_UBUNTU_BLUETOOTH\2-蓝牙资料\蓝牙协议分析)
设计到的工具:Android “蓝牙串口” apk(在资料中STM32_UBUNTU_BLUETOOTH\3-软件工具\bt_spp_apk)
本分析为了简化流程,所以采用Base on pincode配对方式,如果想看SSP的配对方式,可以参照HCI章节的SSP配对
整个流程如下(初始化部分不讲解,可以参照HCI章节的初始化流程,直接从手机连接开发板步骤说起):
整个步骤比较复杂,我来一个个流程给你们拆解下,总结流程如下(备注:每个设备的交互流程稍有差别,但是总体框架一样,另外每个步骤含有几个子步骤,我们在后面介绍完整个流程再展开说明):
步骤1)手机发送连接请求,开发板接受连接,然后收到连接完成事件
步骤2)开发板主动问询手机支持的feature,手机回复开发板
步骤3)开发板处理一些HCI command(Page scan reprtition Moide change/Max slot change/Link supervision timeout change)
步骤4)手机发起L2CAP information request,开发板回复(Extened Feature/Fixed channel support)
步骤5)手机主动连接SDP,然后L2CAP configure交互MTU参数
步骤6)手机主动问询开发板SPP的SDP信息,开发板回复,问询完后手机断开SDP的连接
步骤7)手机主动连接RFCOMM,然后L2CAP configure交互MTU参数。
步骤8)手机主动连接RFCOMM signal通道,并且交互PN参数
步骤9)手机发起配对请求,配对完成后芯片上报给协议栈Link Key
步骤10)手机连接开发板SPP的RFCOMM server channel
步骤11)开发板跟手机交互RFCOMM Modem status参数
步骤12)开发板主动跟手机交互PnP SDP参数(此部分是DID协议部分,暂时略过)
步骤13)手机主动发送SPP字符串(上层决定)
步骤14)开发板主动发送SPP字符串(上层决定)
步骤15)手机主动开发与开发板的连接
下面我们就来一一分析下整个流程,
备注:关于HCI command/event,l2cap,rfcomm,sdp封包格式我会做简短的介绍,详细的可以分别看下我之前的文章
整个步骤1分为以下几个小步骤组成
用另外一种flow表示如下:
① 手机发起蓝牙连接,芯片收到后,发送给协议栈,相当于Remote chip -> Local Chip(Controller) -> Local BT stack(host)这个过程,在后面我们就直接说手机发起连接,协议栈收到来简化描述首先我们来看下这个event的格式。
我们来分析下raw data
04 0A 0A 7F 24 DF 0C 9C 0C 02 5A 01 (hex)
04 -> HCI_Connection_Request event id
0A -> para的长度,我们也可以看到参数部分蓝牙地址6个byte,cod 3个byte,link type 1byte
0A 7F 24 DF 0C 9C -> 蓝牙地址(手机的)
0C 02 5A -> cod (关于cod的分析参照我另外的一篇文章)
01 -> link type,也就是acl
我们来看下btsnoop工具帮我们分析的结果,可以看到跟我们一样
② 协议栈发送给芯片接受连接,Local芯片收到后,然后发送手机,相当于Local BT stack(host)->Local chip(Controller)->Remote chip这个过程,后续我们直接说协议栈发送给手机来简化描述。
我们先看下这个HCI command的格式:
我们来看下raw data
09 04 07 0A 7F 24 DF 0C 9C 01
09 04 -> HCI opcode ,也就是HCI_Accept_Connection_Request,我们之前也有写过怎么把OGF,OCF组装成opcode,我在这里再贴下那这个命令是OGF=1,OCF=9,
Opcode[0] = OCF & 0xff = 0x09
Opcode[1] = (OCF >> 8) | (OGF << 2) = 0x04,组装起来就是0x09,0x04
07 -> para len,也就是蓝牙地址 link type的长度
0A 7F 24 DF 0C 9C -> 蓝牙地址(手机的)
01 -> 保持slave角色,如果是Master,那么Local stack要发送Role switch的command
我们来看下btsnoop工具分析的结果:
③ 芯片发送给手机command status来表示收到的command,这个没什么好讲解的,直接就是我们发送的command的status,其他文章已经说过多次,我们不再重复
④ 芯片发送给手机connection complete
我们来看下这个event的格式以及参数
我们来分析下raw data:
03 0B 00 4C 00 0A 7F 24 DF 0C 9C 01 00
03 -> HCI event id
0b -> 后续参数长度
00 -> status success,在HCI core文档error code中有集中说明每个value代表什么意思
4C 00 -> 连接句柄,注意,此部分重要,后续所以acl封包都会用到这个参数
0A 7F 24 DF 0C 9C -> 蓝牙地址(手机的)
01 -> link type ,1代表acl
00 -> disable加密
我们来看下btsnoop的视图分析:
后续的HCI command/event封包我们不再一一对raw data做分析,可以举一反三,自己根据core文档分析下。
整个步骤2分为以下几个小步骤组成
① 协议栈获取对方支持的Feature
可以看到,此部分的HCI command的参数就是上面链接完成的连接句柄
② 协议栈收到芯片发送的command status
③ 手机发送给协议栈封包,告知协议栈手机支持的Feature
Page scan等名词参照附录
Slots可以先不用关注
Link Supervison Timeout,大白话就是link lost的时间,在说这个timeout的时候,先来说下supervison time,比如两台设备连接,突然一台断电,可以看到另外一台并不是直接断开连接,而是过一段时间才会显示断开连接,而这个时间就是supervision time,这个supervison timeout后芯片就告知协议栈断线了·,其中检测原理我在附录中讲解
整个步骤4分为以下几个小步骤组成
① 手机问询L2CAP information with Extened Feature Support
我们来看下L2CAP information requese的格式(我们是用的basic mode)
其中Information payload就是下面的
那我们整个分析下raw data,包括L2CAP/HCI
4C 20 0A 00 06 00 01 00 0A 02 02 00 02 00
4C 20 -> HCl ACL header,格式如下
Packet Boundary Flag First automatically-flushable packet(0b10)
Broadcast Flag Point-to-point (0b00)
然后Handle就是connection complete的0x004C,然后整个值就是4C 20
0A 00 -> ACL数据的长度,也就是10byte
从这里开始就是L2CAP的数据
06 00 -> l2cap payload的长度,也就是6个byte
01 00 -> channel id(CID)为1,也就是signal channel(L2CAP命令通道)
0A -> L2CAP information requese code
02 -> id,requese跟response一样
02 00 -> 后续的长度
后续是InfoType
02 00 -> Extended feature supported
下面我们来看下整个封包的btsnoop
L2CAP的抛砖引玉到这里,后续的几个小步骤L2CAP封包自己举一反三下
② 给手机回复L2CAP information with Extened Feature Support的response
③ 手机问询L2CAP information with Fixed channel Support
④ 给手机回复L2CAP information with Fixed channel Support的response
① 手机主动来连接SDP
我们通过raw data来分析下整个连接PSM协议流程(HCI,L2CAP)
4C 20 0C 00 08 00 01 00 02 04 04 00 01 00 52 00
4C 20 ->
Packet Boundary Flag First automatically-flushable packet(0b10)
Broadcast Flag Point-to-point (0b00)
然后Handle就是connection complete的0x004C,然后整个值就是4C 20
0C 00 -> acl packet length
08 00 -> l2cap basic packet length
01 00 -> L2CAP signal通道
下面的数据就是参照此部分格式
02 -> l2cap connection request的code
04 -> id,response必须跟这个一致
04 00 -> 后续的length
01 00 -> PSM,SDP是0x0001,后续还会有RFCOMM的PSM,所以我一起截图了
52 00 -> source ID为0x0052,记住后面这个值,我们会用到
我们来看下整个封包的btsnoop分析。
② 针对手机连接SDP回复response
此分析流程参照其他L2CAP的分析,但是以上我们要记住一点,就是Destination cid是0x0040
③ 手机主动来配置MTU,我们回复
④ 我们主动去配置MTU,手机回复
分为以下几个小步骤:
① 手机发起SPP的相关SDP信息的问询
我们先来看下raw data的分析(包含SDP/L2CAP/HCI)
4C 20 18 00 14 00 40 00 06 00 00 00 0F 35 03 19 11 01 03 F0 35 05 0A 00 00 FF FF 00
4C 20 ->
Packet Boundary Flag First automatically-flushable packet(0b10)
Broadcast Flag Point-to-point (0b00)
然后Handle就是connection complete的0x004C,然后整个值就是4C 20
18 00 -> acl packet length
14 00 -> L2CAP basic mode的length
40 00 -> Destination id,也就是上面L2CAP连线分配的
后面就是SDP的数据了,SDP的数据格式是:
06 -> SDP_SERVICE_SEARCH_ATTR_REQ
00 00 -> TID
00 0F -> Length
35 03 19 11 01 -> ServiceSearchPattern,此部分是一个数据元,关于数据元的详解介绍参照我SDP相关章节的介绍
此部分就是表示UUID 0x1101,也就是SPP
03 F0 -> max count 1008
35 05 0A 00 00 FF FF -> AttributeIDList:是个数据元,range是0x0000~0xffff
00 -> ContinuationState,是0
我们来看下btsnoop
② 手机回复
此部分我们就不一一分析,可以按照前面的分析流程来做分析,btsnoop如下
另外,为什么是这个样子呢,因为我们code中注册的是这个样子,code如图:
注意啦:我们注册的RFCOMM server channel(scn)是8,这个值要记住,后面手机过来连接rfcomm channel的时候就是通过这个值
③ 手机断开SDP连接,我们回复response
此步骤L2CAP配置MTU我们在上面已经说明,所以不再重复说明,我们只来看下连接RFCOMM通道的步骤
① 手机过来连接RFCOMM
② 我们回复response
分为以下几个小步骤:
① 手机过来连接RFCOMM signal通道
我们先来分析下raw data(RFCOMM/L2CAP/HCI):
4C 20 08 00 04 00 40 00 03 3F 01 1C
4C 20 ->
Packet Boundary Flag First automatically-flushable packet(0b10)
Broadcast Flag Point-to-point (0b00)
然后Handle就是connection complete的0x004C,然后整个值就是4C 20
08 00 -> acl packet length
04 00 -> l2cap basic mode length 4 byte
40 00 -> Destination id,就是上面l2cap rfcomm连线分配的
下面就是RFCOMM数据了,格式如下:
03 -> 这个是Address field,格式如下:
0x03 = 00000011b,也就是EA=1,C/R=1,也就是command,server channel是0,也就是signal channel
3F -> Control field,格式如下:
0x3f = 00111111b,也就是 SABM帧,P/F=1
01 -> length,格式如下:
0x01 = 00000001b,也就是EA=1,7个byte表示后续的长度,也就是0,后续无长度
1C -> FCS
我们来看下btsnoop
② 我们回复
③ 手机过来配置PN参数,并且携带credit
④ 我们回复PN参数,并且携带credit
分为以下几个小步骤:
① 芯片给协议栈发HCI pin code requese的event
② 协议栈回复pincode,芯片上报command complete event
③ 芯片上报给协议栈link key
① 手机过来连接SPP server channel通道
注意此部分手机过来连接的server channel就是我们SDP回复给手机的RFCOMM channel 8
② 我们回复
此部分我们只列举一个Modem status response
手机发送的字符串为:
其中RFCOMM的payload就是SPP发送的数据
我们来分析下raw data:
4C 20 32 00 2E 00 40 00 43 FF 53 03 68 65 6C 6C 6F 2C 49 20 61 6D 20 77 69 72 65 6C 65 73 73 20 6C 69 6E 6B 20 69 6E 20 61 6E 64 72 6F 69 64 20 70 68 6F 6E 65 38
4C 20 ->
Packet Boundary Flag First automatically-flushable packet(0b10)
Broadcast Flag Point-to-point (0b00)
然后Handle就是connection complete的0x004C,然后整个值就是4C 20
32 00 -> acl packet length,50byte
2E 00 -> l2cap basic mode length = 46byte
40 00 -> Destination id,也就是0x0040
43 -> RFCOMM address
FF -> RFCOMM control,此部分为UIH帧
53 -> RFCOMM length
03 -> give credit
68 65 6C 6C 6F 2C 49 20 61 6D 20 77 69 72 65 6C 65 73 73 20 6C 69 6E 6B 20 69 6E 20 61 6E 64 72 6F 69 64 20 70 68 6F 6E 65
-> 此部分就是我们发送的字符串
38 -> FCS
我们发送的字符串为
希望通过这篇文章能让你们熟悉蓝牙芯片跟蓝牙协议栈整个流程的交互方式!