Linux下Bluez的编程实现

（转自：https://www.sodocs.net/doc/6f793697.html,/index.html）

Linux下Bluez的编程实现1、蓝牙的各个协议栈的简介 (2)

1.1、蓝牙技术 (2)

1.1、蓝牙协议栈 (2)

1.2、蓝牙技术的特点 (4)

1.2.1、蓝牙协议栈体系结构 (4)

1.2.2、蓝牙协议栈低层模块 (4)

1.2.3、软件模块 (5)

1.3、蓝牙的一些Profile (6)

2、Bluez和D-Bus (7)

2.1、Bluez和D-Bus体系结构 (7)

2.2、D-Bus介绍 (9)

2.3、Bluez的安全接口 (13)

2.4、Bluez适配器接口 (15)

2.5、Bluez配对 (16)

2.6、Bluez绑定 (17)

3、Bluez编程实现 (18)

3.1、蓝牙开发关键技术剖析 (18)

3.1.1、连接机制分析 (18)

3.1.2、自动连接 (18)

3.1.3、时钟设计 (19)

3.1.4、配对列表管理 (20)

3.1.5、蓝牙文件传输模式 (20)

3.2、hci层介绍 (20)

3.2.1、hci层介绍 (20)

3.2.2、hci层编程 (21)

3.3、L2CAP层编程 (25)

3.3.1、L2CAP协议简介 (25)

3.3.2、L2CAP编程方法 (26)

3.4、SDP协议简介 (27)

4、Openobex (28)

4.1、Openobex简介 (28)

4.2、Openobex与bluez编程实现 (29)

5、Obexftp (32)

5.1、obexftp简介 (32)

5.2、基于Obexftp的应用程序开发 (32)

6、参考资料 (32)

1.1、蓝牙技术

蓝牙（Bluetooth）技术是由Ericsson、IBM、Intel、Nokia和Toshiba 公司于1998年5月共同提出开发的，并联合成立了蓝牙特殊利益小组(SIG)，负责开发无线协议规范并设定交互操作的需求。其本质是设备间的无线链接，意在于代替有线电缆。

1.1、蓝牙协议栈

协议栈是指一组协议的集合，举个例子，把大象装到冰箱里，总共要3步。每步就是一个协议，3步组成一个协议栈。把应用层数据包发出去，也要好几步，TCP/UDP头，IP头，ether头，每步也是一个协议。另外每层都有一些特殊的协议。所有这些统称协议栈。蓝牙协议栈就是SIG定义的一组协议的规范，目标是允许遵循规范的蓝牙应用能够进行相互间操作，如图1.1蓝牙协议栈

图1.1 蓝牙协议栈

在蓝牙协议体系中，底层、中间层、应用层按序排列构成了蓝牙协议栈，如左图所示。底层(硬件层)和中间协议层

(软件层)之间的接口使用主机控制

器接口(HCI)。HCI是软硬件之间必不可

少的接口，其功能是解释并传递两层之

间的消息和数据。软件通过HCI调用底

层LMP/BB和RF等硬件。HCI以下的功能

由蓝牙设备实施；HCI以上的功能由软件

运行，在主机上实现。HCI对于上、下两

层数据的传输都是透明的。

在蓝牙协议栈中，最主要的是蓝牙核心协议，包括基带协议(BP)、链路管理协议(LMP)、链接控制和适配协议(L2CAP)、服务发现协议(SDP)等。蓝牙设备基本上都需要核心协议，其他协议则按蓝牙设备的需要而选定。

1.2、蓝牙技术的特点

1.2.1、蓝牙协议栈体系结构

整个蓝牙协议体系结构可分为底层硬件模块、中间协议层和高端应用层三大部分。链路管理层(LMP)、基带层(BBP)和蓝牙无线电信道构成蓝牙的底层模块。BBP层负责跳频和蓝牙数据及信息帧的传输。

LMP层：负责连接的建立和拆除以及链路的安全和控制，它们为上层软件模块提供了不同的访问人口，但是两个模块接口之间的消息和数据传递必须通过蓝牙主机控制器接口的解释才能进行。也就是说，中间协议层包括逻辑链路控制与适配协议(L2CAP)、服务发现协议(SDP)、串口仿真协议(RFCOMM)和电话控制协议规范(TCS)。

L2CAP：完成数据拆装、服务质量控制、协议复用和组提取等功能，是其他上层协议实现的基础，因此也是蓝牙协议栈的核心部分。

SDP:为上层应用程序提供一种机制来发现网络中可用的服务及其特性。在蓝牙协议栈的最上部是高端应用层，它对应于各种应用模型的剖面，是剖面的一部分。目前定义了13种剖面。

1.2.2、蓝牙协议栈低层模块

蓝牙的低层模块是蓝牙技术的核心，是任何蓝牙设备都必须包括的部分。

蓝牙工作在2.4GHZ的ISM频段。采用了蓝牙结束的设备讲能够提供高达72 0kbit/s 的数据交换速率。

蓝牙支持电路交换和分组交换两种技术，分别定义了两种链路类型，即面向连接的同步链路(SCO)和面向无连接的异步链路(ACL)。

为了在很低的功率状态下也能使蓝牙设备处于连接状态，蓝牙规定了三种节能状态，即停等(Park)状态、保持(Hold)状态和呼吸(Sniff)状态。这几种工作模式按照节能效率以升序排依次是：Sniff模式、Hold模式、Park模式。

蓝牙采用三种纠错方案：1/3前向纠错(FEC)、2/3前向纠错和自动重发(AR Q)。前向纠错的目的是减少重发的可能性，但同时也增加了额外开销。然而在一个合理的无错误率环境中，多余的投标会减少输出，故分组定义的本身也保持灵活的方式，因此，在软件中可定义是否采用FEC。一般而言，在信道的噪声干扰比较大时蓝牙系统会使用前向纠错方案，以保证通信质量：对于SCO链路，使用1/3前向纠错；对于ACL链路，使用2/3前向纠错。在无编号的自动请求重发方案中，一个时隙传送的数据必须在下一个时隙得到收到的确认。只有数据在收端通过了报头错误检测和循环冗余校验(CRC)后认为无错时，才向发端发回确认消息，否则返回一个错误消息。

蓝牙系统的移动性和开放性使得安全问题变得及其重要。虽然蓝牙系统所采用的调频技术就已经提供了一定的安全保障，但是蓝牙系统仍然需要链路层和应

用层的安全管理。在链路层中，蓝牙系统提供了认证、加密和密钥管理等功能。每个用户都有一个个人标识码(PIN),它会被译成128bit的链路密钥 (Link Key)来进行单双向认证。一旦认证完毕，链路就会以不同长度的密码(Encryphon Ke y)来加密(此密码以shit为单位增减，最大的长度为128bit)链路层安全机制提供了大量的认证方案和一个灵活的加密方案(即允许协商密码的长度)。当来自不同国家的设备互相通信时，这种机制是极其重要的，因为某些国家会指定最大密码长度。蓝牙系统会选取微微网中各个设备的最小的最大允许密码长度。例如，美国允许128bit的密码长度，而西班牙仅允许48bit，这样当两国的设备互通时，将选择48bit来加密。蓝牙系统也支持高层协议栈的不同应用体内的特殊的安全机制。例如两台计算机在进行商业卡信息交流时，一台计算机就只能访问另一台计算机的该项业务，而无权访问其他业务。蓝牙安全机制依赖PIN在设备间建立信任关系，一旦这种关系建立起来了，这些PIN就可以存储在设备中以便将来更快捷地连接。

1.2.3、软件模块

L2CAP是数据链路层的一部分，位于基带协议之上。L2CAP向上层提供面向连接的和无连接的数据服务，它的功能包括：协议的复用能力、分组的分割和重新组装(Segmentation And Reaassembly)以及提取(Group Abstraction)。L2CA P允许高层协议和应用发送和接受高达64K Byte的数据分组。

SDP为应用提供了一个发现可用协议和决定这些可用协议的特性的方法。蓝牙环境下的服务发现与传统的网络环境下的服务发现有很大的不同，在蓝牙环境下，移动的RF环境变化很大，因此业务的参数也是不断变换的。SDP将强调蓝牙环境的独特的特性。蓝牙使用基于客户/服务器机制定义了根据蓝牙服务类型和属性发现服务的方法，还提供了服务浏览的方法。

RFCOMM是射频通信协议，它可以仿真串行电缆接口协议，符合ETSI0710串口仿真协议。通过RFCOMM，蓝牙可以在无线环境下实现对高层协议，如PPP、T CP/IP、WAP等的支持。另外，RFCOMM可以支持AT命令集，从而可以实现移动电话机和传真机及调制解调器之间的无线连接。

蓝牙对语音的支持是它与WLAN相区别的一个重要的标志。蓝牙电话控制规范是一个基于ITU-T建议Q.931的采用面向比特的洗衣，它定义了用于蓝牙设备间建立语音和数据呼叫的呼叫控制信令以及用于处理蓝牙TCS设备的移动性管理过程。

1.3、蓝牙的一些Profile

蓝牙里面profile的定义，profile既是配置文件，配置文件定义了可能的应用，蓝牙配置文件表达了一般行为，蓝牙设备可以通过这些行为与其它设备进行通信。蓝牙技术定义了广泛的配置文件，描述了许多不同类型的使用案例。按照蓝牙规格中提供的指导，开发商可以创建应用程序以与其它符合蓝牙规格的设备协同工作。到目前为止，蓝牙一共有22个profile，在https://www.sodocs.net/doc/6f793697.html,上有详细的文档说明。

已经实现了的协议栈：

Widcomm: 第一个windows上的协议栈，由Widcomm公司开发，也就是现在的Br oadcom .

Microsoft Windows stack: Windows XP SP2中包括了这个内建的协议栈，开发者也可以调用其API开发第三方软件。

Toshiba stack: 它也是基于Windows的，不支持第三方开发，但它把协议栈授权给一些laptop商）。它支持的Profile有： SPP, DUN, FAX, LAP, OPP, FT P, HID, HCRP, PAN, BIP, HSP, HFP , A2DP, AVRCP, GAVDP）

BlueSoleil: 著名的IVT公司的产品，这个应该是个中国公司。该产品可以用于桌面和嵌入式，他也支持第三方开发，DUN, FAX, HFP, HSP, LAP, OBEX, OPP, PAN SPP, AV, BIP, FTP, GAP, HID, SDAP, and SYNC。

Bluez: Linux官方协议栈，该协议栈的上层用Socket封装，便于开发者使用，通过DBUS与其它应用程序通信。

Affix: NOKIA公司的协议栈，在Symbian系统上运行。

BlueDragon：东软公司产品，支持的Profile：SDP、Serial-DevB、AVCTP、AVR CP-Controller、AVRCP-Target、Headset-AG、Headset-HS、OPP-Client、OPP-Server、CT-GW、CT-Term、Intercom、FT-Server、FT-Client、GAP、SDAP、Se rial-DevA、AVDTP、GAVDP、A2DP-Source、A2DP-Sink。

BlueMagic：美国Open Interface 公司for portable embedded divce的协议栈，iphone(apple)，nav-u(sony)等很多电子产品都用该商业的协议栈，BlueM agic 3.0是第一个通过bluetooth 协议栈1.1认证的协议栈，那么我现在就在用它，那么该栈用起来简单，API清晰明了。实现了的profile有:HCI,L2CAP,R FCOMM,A/V,Remote,Control,A/V,Streaming,BIP,BPP,DUN,FAX,FTP,GAP,Hands-Free,and,Headset,HCRP,HID,OBEX,OPP,PAN,BNEP,PBAP,SAP,SPP,Synchronizat ion,SyncML,Telephony,XML.

BCHS-Bluecore Host Software: 蓝牙芯片CSR的协议栈，同时他也提供了一些上层应用的Profile的库。

Windows CE：微软给Windows CE开发的协议栈，但是windows ce本身也支持其它的协议栈。

BlueLet：IVT公司for embedded product的清量级协议栈。

Linux下Bluez的编程实现(2)

2.1、Bluez和D-Bus体系结构

The BlueZ D-Bus interfaces aim to provide seamless Bluetooth techn ology integration into the desktop. A central Bluetooth daemon "hcid" (planned to be renamed to bluetoothd) is responsible for take care of all tasks that can’t or shouldn’t be handled inside the Linux kern el. These jobs include PIN code and link key management for the authe ntication and encryption, caching of device names and services and al so central control of the Bluetooth hardware. The interface exported allows to abstract the internals of GNOME, KDE, Maemo, OpenMoko, ... a pplications from any technical details of the Bluetooth specification. Even other application will get access to the Bluetooth technology w ithout any hassle.

Bluez和D-bus接口，提供了蓝牙技术和桌面系统的完美集成。蓝牙的中心守护进程hcid的职责就是处理那些不能被linux内核处理的任务，包括处理为鉴权和加密过程中需要的PIN码和密钥、缓存设备的名称和服务类型，同时也是蓝牙硬件的控制中心。

The BlueZ D-Bus services are exported through the system message bus. Every D-Bus enabled desktop has a system message bus instance runnin g. This bus is used to broadcast system events, such as new hardware

devices, network connection status, and so forth. The session message bus is not suitable for this architecture since the Bluetooth hardwa re/connections are shared by all desktop sessions.

Bluez和D-bus服务通过系统消息总线提供。每个D - Bus使桌面有一个系统消息总线实例运行。这个bus是用来广播系统时间，如新的硬件设备、网络连接状态等等。会话消息总线对这种体系结构是不适合的，因为蓝牙硬件/连接被所有桌面会话共享。

The BlueZ D-Bus Architecture goal are:

?Abstract Bluetooth HCI commands/events。

?Provide an easy interface to setup Bluetooth adapt

er and manage the services

Bluez和D-bus体系结构的目标：

●抽象hci层命令和事件。

●提供简单的接口来启动蓝牙适配器和管理蓝牙服务。

The hcid is the main entity of the architecture. It impl ements methods to setup the Bluetooth adapters, retrieve re

mote device properties, control the pairing procedure and co

ntrol the services registration/searches. The following figu

re shows a high level relationship between the entities.

Hcid是该体系结构的主体。它实现启动蓝牙适配器的方法、获取远端设备属性、控制配对过程和控制服务的注册和搜索。下图显示了

一个高层次的实体之间的关系。

2.2、D-Bus介绍

什么是D-Bus？

D-BUS 是一种进程间通信的方式，从架构上来说，分为三层：

①一个库，libdbus，允许2个进程间交换信息。

②一个消息总线守护进程，它使用libdbus库。其他进程都可以与它连接。它可以将消息从一个进程发给另外任意数量的其他进程。现在有一些基于特定应用框架的dbus库函数封装，例如libdbus-glib 和libdbus-qt，也有与一些语言绑定的形式，例如Python等。这些封装的API旨在令D-BUS编程更加简单，l ibdbus倾向于提供更低层次的调用。很多libdbus API只在绑定的组件中可用。

③libdbus仅支持一对一的连接，就像原始 socket通讯方式一样。但它传递的不是以字节为单位的数据流，而是具有一定意义的消息包。消息的消息头部表示消息种类，消息体用来装载数据。 Libdbus也可以允许实现特定的传输通道，从而来完成比如像认证之类的应用细节（libdbus also abstracts the exact

transport used (sockets vs. whatever else), and handles details such as authentication.）。

消息总线守护进程将D-bus上连接的所有程序构成一个轮形hub。Libdbus 为中心，它和应用程序建立一对一的连接。每个应用程序通过通道发送消息到消息总线，然后总线进程将消息转发到其他连接到hub的应用程序。可以把消息总线理解为一个路由器。Dbus服务在一个操作系统中存在多个进程。第一个进程是一个全局进程，就如sendmail 或Apache 的系统守护进程一样。这个进程具有高度的安全限制，一般用于系统进程间的通讯。其他的dbus进程都是用户进程，针对于每个登录的用户建立。这些实例允许用户会话中的应用程序相互通信。Dbus全局进程和用户进程是相互独立的，他们并没有内在的依赖关系。

D-Bus应用

有很多种IPC或者网络通信系统，如：CORBA，DCE，DCOM，DCOP，XML-RPC，SO AP，MBUS，ICE等。Dbus的目的主要是下面两点：

1、在同一个桌面会话中，进行桌面应用程序之间的通讯。

2、桌面程序和内核或者守护进程之间通信。

D-Bus概念

对象路径（Native Objects and Object Paths）：D-Bus的底层接口，和libd bus相关，它提供一种叫对象路径(object path)，用于让高层接口绑定到各个对象中去，允许远端应用程序指向他们。Object path就像一个文件路径。

方法和信号（Methods and Signals）：每个对象都有一些成员，有两种成员：方法(methods)和信号(signals)，在对象中，方法可以被调用。信号会被广播，感兴趣的对象可以处理这个信号，同时信号中也可以带有相关的数据。

接口（Interfaces）：每个对象都有一个或者多个接口，一个接口就是多个方法和信号的集合。这个概念和Glib, Qt或者Java中的是一致的。接口定义了对象

实例的类型。dbus使用简单的命名空间字符串来表示接口，如org.freedeskto p.Introspectable。可以说dbus接口相当于C++中的纯虚类。

代理（Proxies）：使用代理对象就是让调用者感觉在直接使用远程对象一样。d -bus的底层接口完成了一些比较低级和繁琐的调用过程，比如必须先调用创建方法形成消息包，然后发送，然后等待接受和处理返回的消息。所以，高层的接口就可以使用代理对象提供的接口屏蔽这些细节。所以，当调用代理对象的方法时，代理内部会转换成dbus的方法调用，等待消息返回，对返回结果解包，返回给相应的方法。可以看看下面的例子，使用dbus底层接口编写的代码：

Message message = new Message(”/remote/object/path”, “MethodName”, arg1, arg2);

Connection connection = getBusConnection();

connection.send(message);

Message reply = connection.waitForReply(message);

if (reply.isError()) {

} else {

Object returnValue = reply.getReturnValue();

}

使用代理对象编写的代码：

Proxy proxy = new Proxy(getBusConnection(), “/remote/object/path”); Object returnValue = proxy.MethodName(arg1, arg2);

客户端代码减少很多。

总线名称（Bus Names）：当一个应用程序连接上bus daemon时，daemon会分配一个唯一的名字给它。以冒号（:）开始，这些名字在daemon的生命周期中是不会改变的，可以认为这些名字就是一个 IP地址。当这个名字映射到应用程序的连接上时，应用程序可以说拥有这个名字。同时应用可以声明额外的容易理解

的名字，比如可以取一个名字 com.mycompany.TextEditor，可以认为这些名字就是一个域名。其他应用程序可以往这个名字发送消息，执行各种方法。

名字还有第二个重要的用途，可以用于跟踪应用程序的生命周期。当应用退出（或者崩溃）时，与bus的连接将被OS内核关掉，bus将会发送通知，告诉剩余的应用程序，该程序已经丢失了它的名字。名字还可以检测应用是否已经启动，这可以用来实现单实例启动程序。

地址（Addresses）：使用d-bus的应用程序既可以是server也可以是client，server监听到来的连接，client连接到server，一旦连接建立，消息就可以流转。如果使用dbus daemon，所有的应用程序都是client，daemon监听所有的连接，应用程序初始化连接到daemon。dbus地址指明server将要监听的地方，client将要连接的地方，例如，地址：unix:path=/tmp/abcdef表明 server将在/tmp/abcdef路径下监听unix域的socket，client也将连接到这个socket。一个地址也可以指明是TCP /IP的socket，或者是其他的。

当使用bus daemon时，libdbus会从环境变量中（DBUS_SESSION_BUS_ADDRESS）自动认识“会话daemon”的地址。如果是系统 daemon，它会检查指定的socke t路径获得地址，也可以使用环境变量（DBUS_SESSION_BUS_ADDRESS）进行设定。当dbus中不使用daemon时，需要定义哪一个应用是server，哪一个应用是cl ient，同时要指明server的地址，这不是很通常的做法。

D-bus工作原理

Calling a Method – Behind the Scenes

在dbus中调用一个方法包含了两条消息，进程A向进程B发送方法调用消息，进程B向进程A发送应答消息。所有的消息都由daemon进行分派，每个调用的消息都有一个不同的序列号，返回消息包含这个序列号，以方便调用者匹配调用消息与应答消息。调用消息包含一些参数，应答消息可能包含错误标识，或者包含方法的返回数据。

方法调用的一般流程：

1.使用不同语言绑定的dbus高层接口，都提供了一些代理对象，调用其他进程里面的远端对象就像是在本地进程中的调用一样。应用调用代理上的方法，代理将构造一个方法调用消息给远端的进程。

2.在DBUS的底层接口中，应用需要自己构造方法调用消息（method call mess age），而不能使用代理。

3.方法调用消息里面的内容有：目的进程的bus name，方法的名字，方法的参数，目的进程的对象路径，以及可选的接口名称。

4.方法调用消息是发送到bus daemon中的。

5.bus daemon查找目标的bus name，如果找到，就把这个方法发送到该进程中，否则，daemon会产生错误消息，作为应答消息给发送进程。

6.目标进程解开消息，在dbus底层接口中，会立即调用方法，然后发送方法的应答消息给daemon。在dbus高层接口中，会先检测对象路径，接口，方法名称，然后把它转换成对应的对象（如GObject，QT中的QObject等）的方法，然后再将应答结果转换成应答消息发给daemon。

7.bus daemon接受到应答消息，将把应答消息直接发给发出调用消息的进程。

8.应答消息中可以包容很多返回值，也可以标识一个错误发生，当使用绑定时，应答消息将转换为代理对象的返回值，或者进入异常。

bus daemon不对消息重新排序，如果发送了两条消息到同一个进程，他们将按照发送顺序接受到。接受进程并需要按照顺序发出应答消息，例如在多线程中处理这些消息，应答消息的发出是没有顺序的。消息都有一个序列号可以与应答消息进行配对。

Emitting a Signal – Behind the Scenes

在dbus中一个信号包含一条信号消息，一个进程发给多个进程。也就是说，信号是单向的广播。信号可以包含一些参数，但是作为广播，它是没有返回值的。

信号触发者是不了解信号接受者的，接受者向daemon注册感兴趣的信号，注册规则是”match rules”，记录触发者名字和信号名字。daemon只向注册了这个信号的进程发送信号。

信号的一般流程如下：

1.当使用dbus底层接口时，信号需要应用自己创建和发送到daemon，使用dbu s高层接口时，可以使用相关对象进行发送，如Glib里面提供的信号触发机制。

2.信号包含的内容有：信号的接口名称，信号名称，发送进程的bus name，以及其他参数。

3.任何进程都可以依据”match rules”注册相关的信号，daemon有一张注册的列表。

4.daemon检测信号，决定哪些进程对这个信号感兴趣，然后把信号发送给这些进程

5.每个进程收到信号后，如果是使用了dbus高层接口，可以选择触发代理对象上的信号。如果是dbus底层接口，需要检查发送者名称和信号名称，然后决定怎么做。

2.3、Bluez的安全接口

pin_helper concept has been removed starting with bluez-utils 3.X. and has been replaced with a feature called passkey agents. An appli cation that wants to handle passkey requests must use the "hcid" secu rity interface to register a passkey agent. Currently, two types of p asskey agents are supported: default and device specific. A "specific " passkey agent handles all passkey requests for a given remote devic e while a default handles all requests for which a specific agent was not found. "specific" passkey agents are useful to address pre-defin ed passkey values or environments where the user interaction is not a llowed/difficult.

When the CreateBonding method is called the "hcid" daemon will verif y if there is a link key stored in the file system. If it is availabl

e an error is returned, and i

f not, a D-Bus message is sent to the re gistered passkey agent askin

g for a passkey.

Each Passkey Agent is represented by a D-Bus object path. The "hc id" distinguishes the agents based on their unique bus names and thei r object paths.

Pin_help的理念在bluez-util 3.x时已经被移除，并被密钥代理所代替。任何想处理密钥请求的应用程序必须使用hcid安全接口来注册密钥代理。现在支持两种类型的密钥代理：默认和设备特定。一个"特定"的密钥代理处理所有远端的密钥请求，一个默认的密钥代理，处理特定的代理所没有发现的所有密钥请求。"特定"的密钥代理对处理那些和用户交互困难或者不允许用户交互的设备的预定义的密钥值或环境非常有用。

当CreateBonding方法被调用时，hcid守护进程将确认当前的文件系统中是否保存了链接密钥，若可以找到，就返回一个错误。若找不到，D-Bus消息将被发出来为密钥请求的设备，注册一个密钥代理。每个密钥代理被D-Bus对象路径所体现，hcid依据唯一的总线名称和对象路径来区分代理。

Architecture

?Step 1: Represents the passkey agent registration

?Step 2: Represents a client calling CreateBonding

?Step 3: Represents the hcid asking for a passkey v

alu

体系结构

●第一步：表示密钥代理注册

●第二步：表示客户调用CreateBonding

第三步：代表hcid请求密钥值。

Message Flow

In the following figure, the "CreateBonding" method call is hidden. The "PIN Request" HCI event is generated when there is not a link ava ilable in the file system. In this case "Link Key Request Negative Re ply" command is sent triggering the "Pin Request" event.

在下面得图表中，CreateBonding方法的调用被隐藏。当没有一个可用链接时，"PIN Request"HCI层事件被产生，在这种情况下，"Link Key Request Neg ative Reply"命令被发送来回应"Pin Request" 事件。

?Step 1: Represents the D-Bus message sent to regis

ter the default/device specific passkey agent.

?Step 2: Represents the HCI "PIN Request" event sen

t by the Bluetooth Host Controller.

?Step 3: Represents the D-Bus message sent to the d efault/device speficic passkey agent requesting a pas skey.

?Step 4: Represents the "Auth Complete" event where the status contains "LMP Response Timeout"(The remot e didn't type the passkey).

?Step 5: Represents the "hcid" issuing a "Cancel" t o a previous Request call.

?Step 6: Represents the D-Bus message sent to relea se the passkey agent: basically sent when the hcid ex its.

●第一步：D-Bus发送消息来注册默认的或者特定的密钥代理。

●第二步：蓝牙主机控制器发送HCI 层"PIN Request"事件。

●第三步：D-Bus发送消息到默认的或者特定的密钥代理，请求密钥。

●第四步："Auth Complete"完成事件，如果这种状态包含" LMP Response Timeout"。

●第五步：hcid发出“Cancel”命令给D-Bus。

●第六步：当hcid退出时，D - Bus的信息发送到释放密钥代理