LV02-01-天猫精灵IOT-07-SmartConfig-01-SmartConfig简介

发表于 分类于 ， ， 本文字数： 8.2k 阅读时长 ≈ 30 分钟

本文主要是天猫精灵IOT Smart config—— SmartConfig介绍的相关笔记，若笔记中有错误或者不合适的地方，欢迎批评指正😃。

点击查看使用工具及版本
Windows版本 windows11
Ubuntu版本 Ubuntu22.04的64位版本
VMware® Workstation 16 Pro 16.2.3 build-19376536
终端软件 MobaXterm(Professional Edition v23.0 Build 5042 (license))
点击查看本文参考资料
分类 网址 说明
官方网站 阿里云 阿里云官网主页
阿里生活物联平台 生活物联网平台(飞燕平台)主页
AliGenie 天猫精灵开放平台AliGenie主页
阿里物联网平台 阿里物联网平台主页
Bluetooth 技术网站 蓝牙协议规范什么的可以来这里找
Telink Telink | Chips for a Smarter IoT (telink-semi.com)
Telink中文官网
开发手册 AliOS Things开发指南 AliOS Things开发指南，这里是最新版本，可以直接从官网找到
AliOS Things开发指南 AliOS Things应用开发指南，这里应该是3.3版本的完整开发文档
AliOS Things开发指南(3.0) AliOS Things应用开发指南，这里应该是3.0版本的完整开发文档
生活物联网平台开发文档 生活物联网平台（飞燕平台）开发文档
《设备端开发指南》
Wi-Fi IoT品类定义与功能开发 天猫精灵IoT开放平台——Wi-Fi IoT品类定义与功能开发
硬件平台 mk3080 WiFi开发板 WiFi开发板使用指南-阿里云开发者社区
esp8266开发板 一个教程：ESP8266-NodeMCU开发板详解-太极创客 (taichi-maker.com)
TLSR8258 Datasheet Datasheet for Telink BLE + IEEE802.15.4 MultiStandard Wireless SoC TLSR8258
参考资料 AliOS Things 3.0 应用开发指南 这个只是一篇参考文章，里面是一些环境搭建相关的，可以参考
IP知识百科 - 华为 (huawei.com) IP的一些相关知识点
点击查看相关文件下载
分类 网址 说明
蓝牙规范相关文档 Core Specification 5.2 核心规格 5.2，该规范定义了创建可互操作的Bluetooth 设备所需的技术。
《Core_v5.2.pdf》
Mesh Model(v1.1) 本Bluetooth 规范定义了模型（以及它们所需的状态和消息），这些模型用于在mesh 网络中的节点上执行基本功能，超出了Bluetooth Mesh 配置文件 规范中定义的基础模型。
本规范包括定义跨设备类型标准功能的通用模型，以及支持关键mesh 场景的模型，如照明控制、传感器、时间和场景。
《MshMDL_v1.1.pdf》
Mesh Profile(v1.0.1) 该Bluetooth 规范定义了基本要求，以实现可互操作的mesh 网络解决方案，用于Bluetooth 低能量无线技术。
《MshPRFv1.0.1.pdf》
Mesh Device Properties 本规范包含Bluetooth Mesh 配置文件 和Bluetooth Mesh 模型规范所要求的设备属性的定义。
但是跟之前的有些区别，我主要看的之前的版本：《MMeshDeviceProperties_v1.2.pdf》
GATT Specification Supplement GATT Specification Supplement | Bluetooth® Technology Website。
好像可以在线看：《GATT Specification Supplement》
Assigned Numbers GATT的一些类型定义可以在这里找。
AliOS Things alios-things/AliOS-Things Gitee上的AliOSThings SDK源码仓库
alibaba/AliOS-Things GitHub上的AliOSThings SDK源码仓库
天猫精灵蓝牙Mesh协议栈 alibaba-archive/genie-bt-mesh-stack GitHub上的天猫精灵蓝牙Mesh协议栈源码仓库。
之前是在alibaba/genie-bt-mesh-stack这个仓库。
写笔记的时候最新提交为faf523618a6a2560090fc423222b9db80984bb7a
蓝牙Mesh设备开发指南 阿里云生活服务平台开发手册——蓝牙设备开发一节中的内容

一、另一种配网方式

在不同的厂商那里，有着不同的名称，比如乐鑫与高通都称为smart config，而在微信里称为Airkiss，实际上都是一个意思。

1. Smart Config使用场景

它这是一种让我们可以在没有和其他设备(支持Smart Config技术)建立任何性质的通讯链路的情况下， 配置智能设备接入wifi网络。

假设有这样一个场景：

我们购买了一个带有wifi的摄像头, 不过这个摄像头没有usb, 没有以太网, 没有蓝牙, 没有nfc, gsm就更不可能了, 只有wifi, 那么问题来了：我们如何配置这个摄像头接入家里的WiFi？乍一想, 没有数据链路, 如何进行数据交换?

Smart Config就是用在这种场景下的, 如果这个摄像头的wifi支持SmartConfig技术, 那么我们只需这样几个步骤

（1）摄像头插上电源，启动。

（2）安装制造商提供的手机app(应用无需任何特殊权限, 只需要手机当前是接入wifi的)。

（3）在摄像头附近打开app, 输入家里的WiFi的SSID和密码, 点击确认, 稍等片刻, 不出意外的话, 摄像头会接入家里的WiFi啦。

这项技术由德州仪器提出, 并且应用在自己的CC3000系列芯片上。不过, 从原理上来说，支持混杂模式的wifi芯片都可以应用该技术。

2. 阿里生活物联网平台的SmartConfig

我们之前都是使用天猫精灵来通过语音完成对设备的配网，其实阿里物联网平台的SDK其实还提供了另一种配网方式，也就是Smart Config。他就是通过收扫描设备配网二维码，进入设备配网流程。我们之前在进行产品创建的时候，有一个产品说明书的面板（产品管理 - 生活物联网平台 (aliyun.com)）：

image-20231217223814022

这里有一个配网二维码，我们使用天猫精灵app扫描后，根据提示完成设备的配网。但是这里需要注意的是，似乎这里的配网只支持2.4G，所以当我们的WiFi热点是5G的话，就无法配网，可能是这个原因吧，反正我试了一下，失败了，设备都没扫描到，但是这种方法应该是可行的才对，后面知道原因了再补充吧。

二、Smart Config基本原理与流程

1. 基本原理

（1）设备进入 Wi-Fi 混杂模式（promiscuous mode）以监听捕获周围的 Wi-Fi 报文。由于设备暂未联网，且 Wi-Fi 网络的数据帧已通过加密，设备无法获取 payload 的内容，但可以获取报文的某些特征数据，例如每个报文的长度。同时对于某些数据帧，例如 UDP 的广播包或多播包，其报文的帧头结构比较固定，较容易识别。

（2）此时在手机 App 或者小程序端，即可通过发送 UDP 的广播包或多播包，并利用报文的特征，例如长度变化进行编码。

（3）将目标 Wi-Fi 路由器的 SSID/PSW 字符以约定的编码方式发送出去，设备端在捕获到 UDP 报文后，按约定的方式进行解码，即可得到目标 Wi-Fi 路由器的相关信息并进行联网。

在实现的过程中，就是将WiFi模块处于AP+STA模式，然后手机APP将SSID与密码编码发送到UDP的报文中，通过广播包或者组播包进行发送。WiFi模块接收到UDP的报文后进行解码，得到正确的SSID与密码，然后进行设备联网，从而达到我们联网的目的。

image-20231219214910069

2. 一个简单的配网流程

image-20231217224509151

大概的流程如上图所示，有几个地方需要我们思考一下：

（1）智能设备不知道路由器在哪里，所以智能设备需要处于一个监听模式，接收所有的报文。

（2）智能设备不知道手机发送的数据包在哪一个信道上，所以需要不停的扫描所有的信道（2.4G，这里的智能设备只支持2.4G）

（3）在配网的时候，由于路由器是有加密策略，是有密码的，所以手机发送给智能设备的数据都是加密数据：

image-20231219075049217

上图就是用抓包软件抓取的数据报文内容，可以看到，除了802.11 MAC Header 能看到外，其他都是加密字段，我们能了解到的只有源MAC地址和目的MAC地址和BSSID信息其他有限几个字段，如何把信息告诉待配网设备呢？ 智能设备是怎么收到密文并解析的？这些我们都后面再学习了解。

（4）由于配网设备未连接无线路由器，手机无法知道待配网设备的的MAC地址，如何才能让待配网设备接收到信息呢？ 由于设备没有连接到无线路由器，这时候手机要发送配网信息是不知道设备的地址的，所以使用的地址是广播地址，这样只要在附近的无线WiFi设备处于监听模式都可以接收到这个报文。

2. 在腾讯云看到的配网流程

SmartConfig 方式配网，每个厂商的编码方式和报文选择上有自己的协议，对于 ESP8266，采用的协议是乐鑫 ESP-TOUCH协议。基于该协议，设备端在连接 Wi-Fi 路由器成功后，将会告知手机端自己的 IP 地址。此时手机端可以通过数据通道，例如 TCP/UDP 通讯将后台提供的配网 Token 发送给设备，并由设备转发至物联网后台，依据 Token 进行设备绑定。

目前腾讯连连小程序已支持采用 ESP-TOUCH 协议进行 SmartConfig 配网，并提供相应的 小程序 SDK。 SmartConfig 方式配网及设备绑定的示例流程图如下：

img

三、数据格式

1. 传输的WiFi数据帧

我们的手机将含有无线路由器SSID和密码的数据包发给智能设备，他们之间的数据包格式是怎样的？也是通过WiFi数据帧的格式发送得到：

image-20231217225418263

这里的length字段就表示了数据帧的总长度。这个帧的格式（这里就截取一部分）和前面学习的WiFi帧的格式有一点不太一样，是因为这部分是符合802.3以太网数据帧的格式，前面学习WiFi帧的时候，哪个是802.11。注意这里的DATA是加密的数据，那配网设备怎么解析？

2. 配网数据格式？

配网应用程序采用广播 IEEE802.3 数据帧方式，通过 Length 字段传输配网信息。 Data 字段是加密的，无法携带配网相关的信息，所以我们可以在Length字段寻求突破，我们可以将它作为一个数据字段使用，我们就可以吧WiFi的SSID和密码作为数据存放到这两个字节中，两个字节显然不够存，那怎么办？我们可以多发几次，把数据发完为止，那这个时候就会有另一个问题就是顺序问题，万一收到的数据顺序错乱了，我们组合的数据不就有问题了吗？ 那怎么解决这个问题？

Length 字段有三种数据格式，分别代表起始帧、数据帧和分组帧。

image-20231217230217933

【我们的猜测】：

  • Length=0x4E0，表示这是起始帧，表示开始配网。

  • Length=Index1|Value，数据帧的[10:7]这4位是index1，表示索引，或者叫序号，以此来确认数据的顺序，但是它只有4位，最多只能提供16个索引（0-15）；[6:0]这7位表示值，可以表示0-127，那要是超过127怎么办？后面会再提到怎么处理。

  • Length=0x3E0|Index2，前面说到，Index1只能表示0-15，一共也才16个不重复的索引，但是我们的SSID和密码加起来总的长度可能会很长，这16个索引可能并不够把SSID和密码存完，所以这里有一个分组帧，分组帧的[3:0]这4位表示组索引，他最多可以表示16组。这样最多就可以表示256个索引啦，这样足够传输完我们的SSID和密码了。

【阿里实际的定义】：

  • 起始帧，一个IEEE802.3格式的数据帧(下同)。 Length字段值固定 为 0x4E0。起始帧也是分组帧，分组号为 0。

  • 数据帧， Length = Index1 | Value。数据帧索引的取值范围为 Index1 = [0x100, 0x180, 0x200, 0x280, 0x300,0x380, 0x400, 0x480]。有效数据 Payload 的取值范围 Value = [0, 127]。但是当有效数据里携带的内容是 SSID 或者 Wi-Fi 密码时，其取值范围 Value = [0, 94]。

  • 分组帧：Length = 0x3E0 | Index2。分组号的取值范围 Index2 = [1,15]。

3. Payload格式

image-20231217232629918

这里的这个格式，其实根据个人理解，应该是一个数据解析的规则，看前面的WiFi帧的Length选项的数据帧，Index1有八个取值Index1 = [0x100, 0x180, 0x200, 0x280, 0x300,0x380, 0x400, 0x480]，这八个索引分别对应上边的数据格式：

image-20231219214520085

我们从数据包中的Length字段，根据上述规则，得到每一个有效数据的值，有效数据规则的每个字段进行解析，就可以得到最终的SSID和密码啦。这需要注意的是，上面的Index1 = [0x100, 0x180, 0x200, 0x280, 0x300,0x380, 0x400, 0x480]，这是循环发送的。实际过程中，Index1的值与Payload格式中的字段并非一一对应，上图只是这样画，后面我们会抓包进行分析，一步步得到WiFi路由器的SSID和密码。

4. 8位到6位数据转换

image-20231217232828527

5. 发包策略

image-20231218234319245

6. 安全策略

上面大概了解了发包的过程，那么会有一个问题，就是设备可以通过这种方式获取SSID和密钥，我们要是能获取到数据包，那我们也能破解密码，如何防止这个问题？那就是对Passwd字段进行加密：

加密只针对 passwd 字段，其他字段不加密。加密算法使用 AES-128-CFB。 AES-128 的密钥按照一机一密和一型一密的规则生成， SHAKEY的前16位作为Key，后16位作为iv。 AES-128- CFB 支持对字节流的加密，即加密字节流的长度可以是任意长度，无需 16 字 节对齐。

密钥生成机制：

天猫精灵云定义的 IoT 设备包含以下三个要素，即三元组:Product Id ， MAC Address，和 Product Secret。其中 Product Id 标识一个产品品类，而 MAC Address 和Product Secret 标识一类产品中的 某个设备。 Product Id(Key) 和 MAC Address 可以基于链路或通道传输，但是 Product Secret 严禁基于链路或通道传输。 该三元组信息会在设备生产时烧录到设备中。

四、Smart Config配网总结

上面了解了整个过程数据格式，下面我们总结一下：

1. 报文长度传递信息

如何使用报文长度传递信息呢？smartconfig使用UDP报文传递信息，UDP的特点是可以发送广播数据，长度从0到最大的MAC报文长度减去前面的报文首部。这个长度可以传递我们需要的信息。SmartConfig有多种实现

image-20231219075450948

上图显示的是连续发送三个长度为1248长度的数据报文表示smartconfig的开始，后面接数据帧。数据帧里面可以传递无线路由器的SSID和密码。由于smartconfig使用的是UDP报文传递，在发送的时候是没有顺序的，这时候就需要对发送的数据有索引字段。

image-20231219075600618

样报文的长度等于 packet len = 索引 | 数据 ，索引和数据的位数可以自己来设计。

2. 传递的效率

由于信息仅能靠长度来传递，而且报文的长度是受限的，则每个报文的信息量是很有限的，传递一个长度是1248长度的数据帧，传递的信息也仅仅是两个字节的数据0X04E0 (0x04e0 = 1248), 传递信息的效率是相当低的，1248是UDP报文的长度，加上前面的UDP包头IP包头，MAC包头等可能要超过1300个字节，那传输的效率就是2/1300=0.0015，情况更糟的是，2个字节传递的信息是0- 0xFFFF，就是0-65535，MAC层的报文长度最大是1500个字节，也就是说即便使用最大的报文长度传递信息连两个字节也传递不了，再去掉索引数据，一般一个报文只能传递一个字节数据。这样传递的效率就更低了。所以smartconfig广播UDP配网的效率普遍较慢，在密码和SSID比较长的情况下，还有配网失败的情况发生。

3.单播、 广播与多播

  • 单播

单播是说，对特定的主机进行数据传送。如给一个主机发送IP数据包。数据链路层会给出网卡的MAC地址(除了FF-FF-FF-FF-FF-FF这个地址之外的MAC地址）

（1）具有路由功能的主机可以将单播数据定向转发。

（2）目的主机的网络接口则可以过滤掉和自己MAC地址不一致的数据。

  • 广播是主机针对某一个网络上的所有主机发送数据包。

这个网络可能是网络，可能是子网，还可能是所有的子网。如果是网络，例如A类网址的广播就是 netid.255.255.255，如果是子网，则是netid.netid.subnetid.255；如果是所有的子网（B类IP）则是则是 netid.netid.255.255。广播所用的MAC地址FF-FF-FF-FF-FF-FF。网络内所有的主机都会收到这个广播数据，网卡只要把 MAC地址为FF-FF-FF-FF-FF-FF的数据交给内核就可以了。一般说来ARP，或者路由协议RIP应该是以广播的形式播发的。

如下图，A广播的数据，BCDE都能收到。

image-20231220185636232
  • 多播

多播又叫组播，可以说广播是多播的特例，多播就是给一组特定的主机（多播组）发送数据，这样，数据的播发范围会小一些(实际上播发的范围一点也没有变小)，多播的MAC地址是最高字节的低位为一，例 如01-00-00-00-00-00。多播组的地址是D类IP(D类IP多用于组播(多播))，规定是224.0.0.0-239.255.255.255。然多播比较特殊，但是究其原理，多播的数据还是要通过数据链路层进行MAC地址绑定然后进行发送。所以一个以太网卡在绑定了一个多播IP地址之后，必定还要绑定一个多播的MAC地址，才能使得其可以像单播那样工作。这个多播的IP和多播MAC地址有一个对应的算法，这个对应不是一一对应的，主机还是要对多播数据进行过滤。

广播和多播的性质一样，路由器会把数据放到局域网里面，然后网卡对数据进行过滤，只拿到自己需要的数据，比如自己感兴趣的多播数据。当一个主机运行了一个处理某一个多播IP的进程的时候，这个进程会给网卡绑定一个虚拟的多播mac地址，并做出来一个多播 ip。这样，网卡就会让带有这个多播mac地址的数据进来，从而实现通信，而那些没有监听这些数据的主机就会把这些数据过滤掉。

如下图，A组播的数据只发给组，所以CDE可以收到，B就收不到了：

image-20231220185819880

4. 多播配网

为了克服广播配网的缺陷，出现了多播配网的应用。多播和广播一样，都是一种可以被附近配网设备接收到的报文，但由于多播地址有多个，可以使用多播的地址来传递信息。

我们手机想某个组发送多播数据，若是在整个网络中，设备全都没有处于多播组中的，这些数据包就会被全部丢弃。只有处于多播组中的数据，才会被设备所接收，这样就会给我们的配网带来便利，因为这样我们就不会对多播组外的设备产生影响了。

  • IP多播地址：范围从 224.0.0.0 到 239.255.255.255

  • MAC多播地址：01-00-5E-00-00-00 到 01-00-5E-7F-FF-FF

image-20231220190540045

IP多播地址和mac多播地址是有对应关系的，mac地址是48位，ip地址是32位，上图可以看出，IP地址的低23位和mac地址做或运算，会得到mac的多播地址，通过这种方式可以将ip地址映射到mac地址上，这样做有什么好处？这样的话我们后面的这3个字节（24位）来传递我们的信息。这样报文就可以做的很短，传输的效率也会大大提高，所以多播配网的成功率也会高很多。

对于smartconfig配网而言，一般情况下IP地址是加密的字段，我们无法看到，所以只能使用多播MAC地址来传递信息。上面的地址我们可以看出多播地址有个较大的范围，地址有三个字节是变化的，我们可以使用这三个变化的地址空间来传递信息。同样由于每次只能传递三个字节，我们需要一个顺序字段，一般会占用一个字节，这样还有两个字节来传递信息，如下图是使用多播MAC地址的示意图：

image-20231219080009260

同样的，多播报文也有顺序问题，所以上面会有一个index索引字段用来表示顺序。

多播配网的数据部分不需要传递信息，所以传递的数据长度大大降低，传递效率很高，多播配网的效率和速度都远远高于广播长度字段配网效率。多播配网的 数据格式是怎样的？多播配网的payload的有效数据格式如下：

image-20231220075356413

其中flag字段占1个字节，这8位信息如下：

image-20231220201550564

bit[0]：是否有密码。

bit[1]：是否有SSID。

……