傳統藍牙RFCOMM協議（Bluetooth rfcomm）流程介紹

原創專注于無線通信的蓬勃 2020-08-27 08:25

進階BLE開發：DA1459x 外設、功耗與工程實戰
告別射頻開關短板！MEMS 高速測試資料

零. 概述

本文章主要講下藍牙協議棧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學院鏈接（進入選擇你想要學習的課程）：

藍牙交流扣扣群：970324688

Github代碼：

入手開發板：

藍牙學習目錄：

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

二.?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