300字范文 > 传统蓝牙RFCOMM协议（Bluetooth rfcomm）流程介绍

传统蓝牙RFCOMM协议（Bluetooth rfcomm）流程介绍

时间：2020-08-12 02:21:44

零. 概述

本文章主要讲下蓝牙协议栈RFCOMM协议部分流控介绍

一. 声明

本专栏文章我们会以连载的方式持续更新，本专栏计划更新内容如下：

第一篇:蓝牙综合介绍，主要介绍蓝牙的一些概念，产生背景，发展轨迹，市面蓝牙介绍，以及蓝牙开发板介绍。

第二篇: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学院链接（进入选择你想要学习的课程）：/lecturer/5352?spm=1002.2001.3001.4144

蓝牙交流扣扣群：970324688

Github代码：/sj15712795029/bluetooth_stack

入手开发板：/item.htm?spm=a1z10.1-c-s.w4004-22329603896.18.5aeb41f973iStr&id=622836061708

蓝牙学习目录：/XiaoXiaoPengBo/article/details/107727900

--------------------------------------------------------------------------------------------------------------------------

二.RFCOMM流程介绍

我们来介绍下一个例子，从RFCOMM signaling通道的连接到其他server channel的连接，数据交互，以及断开的流程来整个分析下，分别会包含flow以及raw data介绍，主要是达到回顾下上面说的内容，对知识点做一个巩固

整个交互流程如下：

主要步骤整理如下：

1）RFCOMM对方（之所以成为对方，是因为那个箭头）来来连接signaling通道，我们回应

2）交互PN UIH封包

3）对方来连接server channel 9

4）发送UIH给对方credit card

5）交互MSC UIH封包

6）交互UIH帧

7）我们主动断开server channel13

8）我们主动断开server channel13

9）我们主动断开server channel9

由于对方来连接signaling channel，也就是rfcomm channel0，所以对方是initiator,我方是responser.这是大前提要记住！

另外，我们再来贴下整个rfcomm的封包结构

其中address格式为：

control格式为：

Length的格式如下：

多路控制通道的格式为：

步骤1）RFCOMM对方来来连接signaling通道，我们回应

①对方来连接我们，rfcomm raw data为03 3F 01 1C（hex数据）

03 = 0000 0011b 那么EA=1，C/R=1，也就是command,DLCI为0，也就是signaling channel

3F = 0011 1111b ,也就是SABM，P/F为1

01 = 0000 0001b,EA=1，也就是只有1个byte，也就是L1~L7标示后续封包的长度，也就是0

1C ,FCS

为了验证下，我们来跟btsnoop对比下

②我们回应对方的signaling channel的连接，rfcomm raw data为03 73 01 D7（hex数据）

03 = 0000 0011b,那么EA=1，C/R=1，也就是command,DLCI为0，也就是signaling channel

73 = 0111 0011,UA帧，p/f为1

01 = 0000 0001b,EA=1，也就是只有1个byte，也就是L1~L7标示后续封包的长度，也就是0

1c也就是fcs

为了验证下，我们来跟btsnoop对比下

步骤2）交互PN UIH封包

①对方发PN UIH，rfcomm raw data为03 EF 15 83 11 12 F0 00 00 FA 03 00 00 70（hex data）

03 = 0000 0011b,那么EA=1，C/R=1，也就是command,DLCI为0，也就是signaling channel

EF = 0111 1111b，UIH帧,P/F为1

15 = 0001 0101 ，EA=1，所以只有1个byte代表长度，0001 010b代表长度，也就是10byte

83 = 1000 0011,是多路控制的type,可以看到EA=1,C/R=1，type是PN

11 = 0001 0001b ,EA=1,len = 0001 000,也就是8byte

剩下的就是PN具体的格式，先列一下格式再分析raw data

12 = 0001 0010b，也就是DLCI为01 0010b,DLCI为0x12,server channel为0x12>>1，也就是9

F0 = 1111 0000b，也就是UIH帧，CL为0

00 = 0000 0000b，priority为0，也就是最高优先级

00 = 0000 0000b，T为0

FA 03, N也就是0x3FA,也就是最大的frame size为1018byte（上层协议会用到此部分）

00 ，NA为0

00，K为0

70->FCS

我们来看下btsnoop是否跟我们分析的一样

可以看到完全一致

②我们发PN UIH

参照①所讲，都是PN分包，不做具体分析

步骤3）对方来连接server channel 9，我们回应

①对方来连接server channel9,rfcomm raw data为4B 3F 01 32（hex data）

4B = 0100 1011b，那么EA=1，C/R=1，也就是command,DLCI为0100 10，也就是0x12,由于我们前面讲了DLCI是D+server channel，initiator连接responder算法应该是DCLI=0+ server chanel<<1，所以部分就是signaling channel应该为9，D=0

3F = 0011 1111b,P/F为1，是SABM帧

01 = 0000 0001b,EA=1，也就是只有1个byte，也就是L1~L7标示后续封包的长度，也就是0

32也就是fcs

我们来看下btsnoop

②我们回应对方的连接，rfcomm raw data为4B 73 01 F9（hex data）

4B = 0100 1011b，那么EA=1，C/R=1，也就是command,DLCI为0100 10，也就是0x12,server channel为9

73 = 0111 0011b,P/F=1,UA帧

01 = 0000 0001b,EA=1，也就是只有1个byte，也就是L1~L7标示后续封包的长度，也就是0

F9也就是fcs

我们来看下btsnoop