子曰小玖的博客

1. 前言在linux平台下，bluez是一个很不错的软件，提供了很多基于命令行的测试工具，如hciconfig、hcitool、hcidump、bluetoothctl等。利用这些工具，我们可以方便的测试、demo各种蓝牙功能。例如，在“玩转BLE(1)_Eddystone beacon”中，我们利用hcitool命令，演示了将手机变成一个Beacon设备的神奇效果。Beacon的演示，从本质上看，是BLE Advertising（广播）功能的测试和验证。自然而然的，我们会好奇：怎么接收这些广播数据呢（其

1. 前言你相信两条命令就可以把自己的破手机变成一个Beacon节点吗？不相信的话就接着往下看吧。通过前几篇“蓝牙协议分析”相关的文章，特别是“蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍”，相信大家对BLE协议栈已经有了基本的认识。在继续后续的分析之前，我们有必要换个视角，从应用的角度，以“玩”的心态，学习并理解BLE的工作原理，并作为后续分析文章的引子和入口。这就是撰写“玩转BLE”系列文章的缘由。之所以起名为“玩转”，是因为我不会在这些文章中涉及任何的技术细节，仅仅是描述一些操作步骤，普及一些蓝

在蓝牙协议栈的物理层，有这样两个比较有用的参数：LQI和RSSI。它们都是通过接收端，判断当前无线环境的质量（链路质量），以指导后续的动作。但这两个数值的计算原理和使用场景又有很大的差别。LQI (Link Quality Indication)，是当前接收到的信号的质量的一种度量。所谓的接收到信号的质量，是接收器通过接收到的信号和理想信号之间的错误累积值估算的。例如，如果使用FSK或者GFSK调制方式，接收器可以将每个bit的频率和期望的频率比较，累积一定数量的symbols（例如64个），就得到了错误累

1. 前言书接上文，我们在“蓝牙协议分析(10)_BLE安全机制之LE Encryption”中介绍了BLE安全机制中的终极武器----数据加密。不过使用这把武器有个前提，那就是双方要共同拥有一个加密key（LTK，Long Term Key）。这个key至关重要，怎么生成、怎么由通信的双方共享，关系到加密的成败。因此蓝牙协议定义了一系列的复杂机制，用于处理和加密key有关的操作，这就是SM（Security Manager）。另外，在加密链路建立之后，通信的双方可以在该链路上共享其它的key（例如

1. 前言前面文章介绍了两种BLE的安全机制：白名单[4]和LL privacy[3]。说实话，在这危机四伏的年代，这两种“捂着脸讲话（其它人不知道是谁在讲话，因而不能插话、不能假传圣旨，但讲话的内容却听得一清二楚）”的方法，实在是小儿科。对于物联网的应用场景来说，要做到安全，就必须对传输的数据进行加密，这就是LE Encryption要完成的事情（当然，只针对面向连接的数据），具体请参考本文的介绍。2. 基本概念从字面理解，Encryption是一个名词，意思是“加密术”，因此LE Encry

1. 前言在上一篇文章[1]中，我们介绍了BLE的白名单机制，这是一种通过地址进行简单的访问控制的安全机制。同时我们也提到了，这种安全机制只防君子，不防小人，试想这样一种场景：A设备表示只信任B、C、D设备，因此就把它们的地址加入到了自己的白名单中，表示只愿意和它们沟通。与此同时，E设备对它们的沟通非常感兴趣，但A对自己不信任啊，肿么办？E眼珠子一转，想出一个坏主意：把自己的地址伪装成成B、C、D中任意一个（这个还是很容易办到的，随便扫描一下就得它们的地址了）就行了，嘿嘿嘿！那么问题来了

1. 前言在万物联网的时代，安全问题将会受到非常严峻的挑战（相应地，也会获得最大的关注度），因为我们身边的每一个IOT设备，都是一个处于封印状态的天眼，随时都有被开启的危险。想想下面的场景吧：凌晨2点，x米手环的闹钟意外启动，将你从睡梦中惊醒，然后床头的灯光忽明忽暗……你的心率、血压、睡眠质量等信息，默默地被竞争对手收集着，并通过大数据分析你的情绪、健康等，随时准备给你致命一击……我知道你家里有几盏灯、几台电器、几个人，知道你几点睡觉几时醒来，知道你一周做过几顿饭，甚至知道你有一个xx棒、

1. 前言了解蓝牙的人都知道，在经典蓝牙中，保持连接（Connection）是一个相当消耗资源（power和带宽）的过程。特别是当没有数据传输的时候，所消耗的资源完全被浪费了。因而，对很多蓝牙设备来说（特别是功耗敏感的设备），希望在无数可传的时候，能够断开连接。但是，由于跳频（hopping）以及物理通道（Physical Channel）划分的缘故，经典蓝牙连接建立的速度实在难以忍受（要好几秒）。对那些突发的数据传输来说，几秒钟的连接延迟，简直是灾难。因此，蓝牙SIG制订BLE规范的时候，充分考虑

1. 前言也许关注BLE的同学都注意到了，BLE设备有多种类型的设备地址，如Public Device Address、Random Device Address、Static Device Address、Private Device Address等等。如果不了解内情，大家肯定会被它们绕晕。不过存在即合理，这样看似奇怪的设计，实际上反映了BLE的设计思路以及所针对的应用场景。让我们通过本文一窥究竟。2. BLE设备的地址类型一个BLE设备，可以使用两种类型的地址（一个BLE设备可同时具备两种

1. 前言大家都知道，相比传统蓝牙，蓝牙低功耗（BLE）最大的突破就是加大了对广播通信（Advertising）的支持和利用。关于广播通信，通过“玩转BLE(1)_Eddystone beacon”和“玩转BLE(2)_使用bluepy扫描BLE的广播数据”两篇文章的介绍，我们已经有了一个整体的认识。本文将依此为基础，从技术的角度，分析和理解BLE协议中有关广播通信的定义和实现。注1：之前的蓝牙协议分析文章（如“蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍”），偏向于从横向、从大而全的角度，介

1. 前言蓝牙是个奇葩的家伙：它总是以后来者的身份出现，很喜欢打仗，而且还不落下风（有点像某讯的风格）。90年代末期和Wi-Fi的无线标准之争如此，当前和802.15.4系（ZigBee、RF4CE、Thread等）的IoT之争，也如此。90年代末期，蓝牙刚出道的时候，就曾叫嚣着把Wi-Fi（802.11）从地球上抹去。反过来，1999年Wi-Fi 802.11b标准发布后，也宣称会把蓝牙干掉。最终，二者划江而治，瓜分了天下，Wi-Fi占据了家庭和办公室中的电脑网络，而蓝牙成为了广受欢迎的电脑和外

1. 前言通过“蓝牙协议分析(2)_协议架构”的介绍，大家对蓝牙协议栈应该有了简单的了解，但是，肯定还有“似懂非懂、欲说还休”的感觉。有这种感觉太正常了，毕竟蓝牙协议是一个历史悠久又比较庞大的协议，没那么容易理解。因此，本文将换个视角，从协议栈设计者的角度，思考如下问题：为什么会有蓝牙协议栈（Why）？怎样实现蓝牙协议栈（How）？蓝牙协议栈的最终样子是什么（What）？另外，我们知道，当前的蓝牙协议包含BR/EDR、AMP、LE三种技术，为了降低复杂度，本文将focus在现在比

1. 前言本文是蓝牙协议分析的第二篇文章，在“蓝牙协议分析(1)_基本概念”的基础上，从整体架构的角度，了解蓝牙协议的组成，以便加深对蓝牙的理解。2. 协议层次蓝牙协议是通信协议的一种，为了把复杂问题简单化，任何通信协议都具有层次性，特点如下：从下到上分层，通过层层封装，每一层只需要关心特定的、独立的功能，易于实现和维护；在通信实体内部，下层向上层提供服务，上层是下层的用户；在通信实体之间，协议仅针对每一层，实体之间的通信，就像每一层之间的通信一样，这样有利于交流、理解、标准化。

1. 前言自1994年由爱立信推出至今，蓝牙技术已经走过了20个岁月。从最初的Bluetooth V1.0，到Bluetooth V4.0（最新的为V4.1，2013年底发布），经历了近9个版本的修订后，发展为当前的状况。说实话，如今的蓝牙4.1，简直是一个大杂烩：BR/EDR沿用旧的蓝牙规范；LE抄袭802.15.4；AMP直接使用802.11。而这一切的目的，就是以兼容性和易用性为基础，在功耗和传输速率之间左右为难。蜗蜗以为，这并不是优雅的设计。不过没关系，存在即合理。因此蜗蜗就开出了这样一