Bluetooth (蓝牙) 是一项无线技术， 用于建立带宽为 2.4GHZ，波长为 10 米的私有网络。 网络一般是由便携式设备，比加手机 (cellular phone)， 掌上电脑 (handhelds) 和膝上电脑 (laptops)) 以 ad-hoc 形式组成。不象其它流行的无线技术――Wi-Fi，Bluetooth 提供了更高级的服务层面，像类 FTP 的文件服务、文件推送 (file pushing)、语音传送、串行线模拟等等。

在 FreeBSD 里，蓝牙栈 (Bluetooth stack) 通过使用 Netgraph 框架 (请看 netgraph(4)) 来的实现。 大量的"Bluetooth USB dongle"由 ng_ubt(4) 驱动程序支持。 基于 Broadcom BCM2033 芯片组的 Bluetooth 设备可以通过 ubtbcmfw(4) 和 ng_ubt(4) 驱动程序支持。 3Com Bluetooth PC 卡 3CRWB60-A 由 ng_bt3c(4) 驱动程序支持。 基于 Serial 和 UART 的蓝牙设备由 sio(4)、ng_h4(4) 和 hcseriald(8)。本节介绍 USB Bluetooth dongle 的使用。

默认的 Bluetooth 设备驱动程序已存在于内核模块里。 接入设备前，您需要将驱动程序加载入内核：

如果系统启动时 Bluetooth 设备已经存在于系统里， 那么从 /boot/loader.conf 里加载这个模块：

插入USB dongle。控制台(console)(或syslog中)会出现类似如下的信息：

脚本 /etc/rc.d/bluetooth 是用来启动和停止 Bluetooth stack (蓝牙栈)的。 最好在拔出设备前停止 stack(stack)，当然也不是非做不可。 启动 stack (栈) 时，会得到如下的输出：

主控制器接口 (HCI) 提供了通向基带控制器和连接管理器的命令接口及访问硬件状态字和控制寄存器的通道。 这个接口提供了访问蓝牙基带 (Bluetooth baseband) 功能的统一方式。 主机上的 HCI 层与蓝牙硬件上的 HCI 固件交换数据和命令。 主控制器的传输层 (如物理总线) 驱动程序提供两个 HCI 层交换信息的能力。

为每个蓝牙 (Bluetooth) 设备创建一个 hci 类型的 Netgraph 结点。 HCI 结点一般连接蓝牙设备的驱动结点 (下行流) 和 L2CAP 结点 (上行流)。 所有的HCI操作必须在 HCI 结点上进行而不是设备驱动结点。HCI 结点的默认名是 “devicehci”。更多细节请参考 ng_hci(4) 的联机手册。

最常见的任务是发现在 RF proximity 中的蓝牙 (Bluetooth) 设备。这个就叫做 质询(inquiry)。质询及 HCI 相关的操作可以由 hccontrol(8) 工具来完成。 以下的例子展示如何找出范围内的蓝牙设备。 在几秒钟内您应该得到一张设备列表。 注意远程主机只有被置于 discoverable(可发现) 模式才能答应质询。

BD_ADDR 是蓝牙设备的特定地址， 类似于网卡的 MAC 地址。需要用此地址与某个设备进一步地通信。 可以为 BD_ADDR 分配由人可读的名字 (human readable name)。 文件 /etc/bluetooth/hosts 包含已知蓝牙主机的信息。 下面的例子展示如何获得分配给远程设备的可读名。

如果在远程蓝牙上运行质询，您会发现您的计算机是 “your.host.name (ubt0)”。 分配给本地设备的名字可随时改变。

蓝牙系统提供点对点连接 (只有两个蓝牙设备参与) 和点对多点连接。在点对多点连接中，连接由多个蓝牙设备共享。 以下的例子展示如何取得本地设备的活动基带 (baseband) 连接列表。

connection handle(连接柄) 在需要终止基带连接时有用。注意：一般不需要手动完成。 栈 (stack) 会自动终止不活动的基带连接。

参考 hccontrol help 获取完整的 HCI 命令列表。大部分 HCI 命令不需要超级用户权限。

逻辑连接控制和适配协议 (L2CAP) 为上层协议提供面向连接和无连接的数据服务， 并提供多协议功能和分割重组操作。L2CAP 充许上层协议和应用软件传输和接收最大长度为 64K 的 L2CAP 数据包。

L2CAP 基于 通道(channel) 的概念。 通道 (Channel) 是位于基带 (baseband) 连接之上的逻辑连接。 每个通道以多对一的方式绑定一个单一协议 (single protocol)。 多个通道可以绑定同一个协议，但一个通道不可以绑定多个协议。 每个在通道里接收到的 L2CAP 数据包被传到相应的上层协议。 多个通道可共享同一个基带连接。

为每个蓝牙 (Bluetooth) 设备创建一个 l2cap 类型的 Netgraph 结点。 L2CAP 结点一般连接 HCI 结点(下行流)和蓝牙设备的驱动结点(上行流)。 L2CAP 结点的默认名是 “devicel2cap”。 更多细节请参考 ng_l2cap(4) 的联机手册。

一个有用的命令是 l2ping(8)， 它可以用来 ping 其它设备。 一些蓝牙实现可能不会返回所有发送给它们的数据， 所以下例中的 0 bytes 是正常的。

l2control(8) 工具用于在 L2CAP 上进行多种操作。 以下这个例子展示如何取得本地设备的逻辑连接 (通道) 和基带连接的列表：

另一个诊断工具是 btsockstat(1)。 它完成与 netstat(1) 类似的操作， 只是用了蓝牙网络相关的数据结构。 以下这个例子显示与 l2control(8) 相同的逻辑连接。

RFCOMM 协议提供基于 L2CAP 协议的串行端口模拟。 该协议基于 ETSI TS 07.10 标准。RFCOMM 是一个简单的传输协议， 附加了摸拟 9 针 RS-232(EIATIA-232-E) 串行端口的定义。 RFCOMM 协议最多支持 60 个并发连接 (RFCOMM通道)。

为了实现 RFCOMM， 运行于不同设备上的应用程序建立起一条关于它们之间通信段的通信路径。 RFCOMM实际上适用于使用串行端口的应用软件。 通信段是一个设备到另一个设备的蓝牙连接 (直接连接)。

RFCOMM 关心的只是直接连接设备之间的连接， 或在网络里一个设备与 modem 之间的连接。RFCOMM 能支持其它的配置， 比如在一端通过蓝牙无线技术通讯而在另一端使用有线接口。

在FreeBSD，RFCOMM 协议在蓝牙套接字层 (Bluetooth sockets layer) 实现。

默认情况下，蓝牙通信是不需要验证的， 任何设备可与其它任何设备对话。一个蓝牙设备 (比如手机) 可以选择通过验证以提供某种特殊服务 (比如拨号服务)。 蓝牙验证一般使用 PIN码(PIN codes)。 一个 PIN 码是最长为 16 个字符的 ASCII 字符串。 用户需要在两个设备中输入相同的PIN码。用户输入了 PIN 码后， 两个设备会生成一个 连接密匙(link key)。 接着连接密钥可以存储在设备或存储器中。 连接时两个设备会使用先前生成的连接密钥。 以上介绍的过程被称为 结对(pairing)。 注意如果任何一方丢失了连接密钥，必须重新进行结对。

守护进程 hcsecd(8) 负责处理所有蓝牙验证请求。 默认的配置文件是 /etc/bluetooth/hcsecd.conf。 下面的例子显示一个手机的 PIN 码被预设为“1234”：

PIN 码没有限制(除了长度)。有些设备 (例如蓝牙耳机) 会有一个预置的 PIN 码。-d 开关强制 hcsecd(8) 守护进程处于前台，因此很容易看清发生了什么。 设置远端设备准备接收结对 (pairing)，然后启动蓝牙连接到远端设备。 远端设备应该回应接收了结对并请求PIN码。输入与 hcsecd.conf 中一样的 PIN 码。 现在您的个人计算机已经与远程设备结对了。 另外您也可以在远程设备上初始结点。

可以通过在 /etc/rc.conf 文件中增加下面的行， 以便让 hcsecd 在系统启动时自动运行：

以下是简单的 hcsecd 服务输出样本：

服务发现协议 (SDP) 提供给客户端软件一种方法， 它能发现由服务器软件提供的服务及属性。 服务的属性包括所提供服务的类型或类别， 使用该服务所需要的机制或协议。

SDP 包括 SDP 服务器和 SDP 客户端之间的通信。 服务器维护一张服务记录列表，它介绍服务器上服务的特性。 每个服务记录包含关于单个服务的信息。通过发出 SDP 请求， 客户端会得到服务记录列表的信息。如果客户端 (或者客户端上的应用软件) 决定使用一个服务，为了使用这个服务它必须与服务提供都建立一个独立的连接。 SDP 提供了发现服务及其属性的机制，但它并不提供使用这些服务的机制。

一般地，SDP客户端按照服务的某种期望特征来搜索服务。 但是，即使没有任何关于由 SDP 服务端提供的服务的预设信息， 有时也能令人满意地发现它的服务记录里所描述的是哪种服务类型。 这种发现所提供服务的过程称为 浏览(browsing)。

蓝牙 SDP 服务端 sdpd(8) 和命令行客户端 sdpcontrol(8) 都包括在了标准的 FreeBSD 安装里。 下面的例子展示如何进行 SDP 浏览查询。

...等等。注意每个服务有一个属性 (比如 RFCOMM 通道)列表。 根据服务您可能需要为一些属性做个注释。 有些“蓝牙实现 (Bluetooth implementation)”不支持服务浏览， 可能会返回一个空列表。这种情况，可以搜索指定的服务。 下面的例子展示如何搜索 OBEX Object Push (OPUSH) 服务：

要在 FreeBSD 里为蓝牙客户端提供服务，可以使用 sdpd(8) 服务。 您可以通过在 /etc/rc.conf 中加入下面的行：

然后用下面的命令来启动 sdpd 服务：

需要为远端提供蓝牙服务的本地的服务程序会使用本地 SDP 进程注册服务。像这样的程序就有 rfcomm_pppd(8)。 一旦启动它，就会使用本地 SDP 进程注册蓝牙 LAN 服务。

使用本地 SDP 进程注册的服务列表，可以通过本地控制通道发出 SDP 浏览查询获得：

拨号网络 (DUN) 配置通常与 modem 和手机一起使用。 如下是这一配置所涉及的内容：

使用 PPP(LAN) 层面的网络接入常使用在如下情形：

在 FreeBSD 中，两个层面使用 ppp(8) 和 rfcomm_pppd(8) (一种封装器，可以将 RFCOMM 蓝牙连接转换为 PPP 可操作的东西) 来实现。 在使用任何层面之前，一个新的 PPP 标识必须在 /etc/ppp/ppp.conf 中建立。 想要实例请参考 rfcomm_pppd(8)。

在下面的例子中，rfcomm_pppd(8) 用来在 NUN RFCOMM 通道上打开一个到 BD_ADDR 为 00:80:37:29:19:a4 的设备的 RFCOMM 连接。具体的 RFCOMM 通道号要通过 SDP 从远端设备获得。也可以手动指定通 RFCOMM，这种情况下 rfcomm_pppd(8) 将不能执行 SDP 查询。使用 sdpcontrol(8) 来查找远端设备上的 RFCOMM 通道。

为了提供 PPP(LAN) 网络接入服务，必须运行 sdpd(8) 服务。一个新的 LAN 客户端条目必须在 /etc/ppp/ppp.conf 文件中建立。 想要实例请参考 rfcomm_pppd(8)。 最后，在有效地通道号上开始 RFCOMM PPP 服务。 RFCOMM PPP 服务会使用本地 SDP 进程自动注册蓝牙 LAN 服务。下面的例子展示如何启动 RFCOMM PPP 服务。

OBEX协议被广泛地用于移动设备之间简单的文件传输。 它的主要用处是在红外线通信领域， 被用于笔记本或手持设备之间的一般文件传输。

OBEX 服务器和客户端由第三方软件包 obexapp实现，它可以从 comms/obexapp port 安装。

OBEX 客户端用于向 OBEX 服务器推入或接出对象。 一个对像可以是(举个例子)商业卡片或约会。 OBEX 客户能通过 SDP 从远程设备取得 RFCOMM 通道号。这可以通过指定服务名代替 RFCOMM 通道号来完成。支持的服务名是有：IrMC、FTRN 和 OPUSH。 也可以用数字来指定 RFCOMM 通道号。下面是一个 OBEX 会话的例子，一个设备信息对像从手机中被拉出， 一个新的对像被推入手机的目录。

为了提供 OBEX 推入服务，sdpd(8) 必须处于运行状态。必须创建一个根目录用于存放所有进入的对象。 根文件夹的默认路径是 /var/spool/obex。 最后，在有效的 RFCOMM 通道号上开始 OBEX 服务。OBEX 服务会使用 SDP 进程自动注册 OBEX 对象推送 (OBEX Object Push) 服务。 下面的例子展示如何启动 OBEX 服务。

串口(SP)层面允许蓝牙设备完成 RS232 (或类似) 串口线的仿真。 这个层面所涉及到情形是， 通过虚拟串口使用蓝牙代替线缆来处理以前的程序。

工具 rfcomm_sppd(1) 来实现串口层。 “Pseudo tty” 用来作为虚拟的串口。 下面的例子展示如何连接远程设备的串口服务。 注意您不必指定 RFCOMM 通道――rfcomm_sppd(1) 能够通过 SDP 从远端设备那里获得。 如果您想代替它的话，可以在命令行里指定 RFCOMM 通道来实现：

一旦连接上，“pseudo tty”就可以充当串口了：