Wifi SmartConfig 一键配置

SmartConfig又名快连

B在没有任何链接的情况下，A是如何告知B设备S的信息，这便是SmartConfig

准备一个支持Smartconfig技术的设备 1.启动这个设备 2.安装制造商提供的手机app 3.在设备附近打开App，输入需要接入的WIFI信息，确认，不出意外的话就会链接上这个设备

上述厂商，是我能查到的应用到市场上面的几个厂商，如有补充请下面评论区，给哥么提醒一下。 哥么看到上面这么多的厂商，怎么搞？怎么开发？

首先需求公司要做一个灯泡、插座、一件配置的一款App，

源代码 两种配置模式： 1.Ap模式：

AP 是 (Wireless) AccessPoint 的缩写，即 (无线) 访问接入点。简单来讲就像是无线路由器一样，设备打开后进入 AP 模式，在手机的网络列表里面，可以搜索到类似 TPLINK_XXX 的名字（SSID）

2.SmartConfig模式 采用UDP广播模式（UDP接收IP地址是255.255.255.255）

esp8266进入混杂、SmartConfig esp8266先scan下AP ，得到AP的相关信息,如工作的channel,然后配置wifi芯片工作在刚才scan到的channel上去接收UDP包，如果没有接收到，继续配置ESP8266工作在另外的channel上，如此循环，直到收到UDP包为止

为什么要提前进行SCAN 下WIFI AP？

为了提高配置效率。假设当前网络中只有两个AP,一个AP工作在CHANEL1，另外个 ap工作在channel13,我们现在需要配置智能硬件连接到AP2 ,就是channel13上，如果不提前scan就需要从1--13扫描浪费时间 就是需要从channel1-chane2---...channnel13一直扫描了，如果扫描了AP，芯片马上从AP CHANNNEL1 到channel13加快获取到UDP包；

通过Yeelink提供的数据接口，用户可以把自己的传感器通过互联网接入Yeelink物联网云平台，从而实现随时随地获取传感器数据，为一些智能家居设备接入互联网提供了物联网云平台支持。

这个在谷歌找到的关于ti的Smartconfig的工作原理 CC3000 Smart Config - transmitting SSID and keyphrase How does TI CC3000 wifi smart config work? 这两篇写的很详细,下面开始是一篇文章的翻译，水准别看了就看个大概吧。

让我们从头开始,哥么有一个问题——哥么想要发送两条信息,一个名称和密码，A在一个连接WIFI状态下，B在一个无网状态下，但是B在监听周围所拥有无线网络流量，但是这些流量不能解密。

无法解密wifi通信的人仍然可以看到很多信息，例如，他们可以看到发送的每个数据包的源和接收者MAC地址。

哥么可以看到数据包的数据部分的长度。加密影响发送的数据包的大小，但以一致的方式，例如，如果一个数据包在给定的数据包中发送了n字节的数据，那么加密的数据包将包含(n + x)字节，其中x在所有数据包中是恒定的。

因此，我们的问题的解决方案是对发送的数据包的大小进行编码(实际内容是不相关的)。

安全网络上的一方只向网络上的另一方发送特定长度的UDP数据包。另一方对收到信息包不感兴趣并不重要。

外部方不能直接知道包中包含UDP数据，但是包仍然包含基本类型信息，允许将许多数据包排除在考虑之外，例如任何不属于802.11子类型“QoS数据”的包都可以被排除。

由于外部方事先不知道要查看哪一个wifi通道或哪个源和接收地址对必须注意一个，除了基础数据，即编码的SSID等，还需要定期发送允许该数据被发现的重复模式。

我们将我们的SSID和keyphrase转换成一系列标记值、字符串长度、nibble值和分隔符值，然后将所有这些值编码并传输为数据包长度。

我们使用两个标签——一个是1399 代表SSID标签和一个值1459的关密码标签和一个标准分隔符序列，包含两个值- 3和23。

我们使用两个常数，L值为28，而C值为593，我们将在下面看到。因此，对于SSID，按照以下顺序生成下列值序列:

1399 代表ssid 名称

L加上以字节为单位的SSID的长度。

这两个分隔符值为3和23。

然后我们对SSID的每个字节进行循环，并为每个字节生成一组4个值: 两个值—一个用于字节的每个字节，如下一节所述。

然后是两个分离器值3和23。

值以相同的方式生成，用于关键短语(ssid = 1399 password = 1459)。

注意:TI Android library和Java applet库生成了如上所述的值，奇怪的是，TI iOS库产生了稍微不同的排序(这显然不会影响CC3000解码数据的能力)。这种差异可以在后面的示例数据长度转储中看到。

一旦我们有了所有这些值然后UDP数据包,每一个对应于一个值的数据量,从机发送运行智能配置应用程序,即一个刚刚描述的值生成,到另一个系统在同一网络(目前总是网络的默认网关)。

值发送多次,直到外部党,即CC3000启用设备,成功地处理他们从所有其他的网络流量,并使用它们来连接网络,这时它的广告出现在网络的方式传输应用程序可以检测并导致它停止传输。

请注意，需要支持的包长度范围在网络的最大传输单元(MTU)上有一个下界。目前，智能配置客户端应用程序期望MTU达到1500或更高(这是任何正常网络的合理期望)。

注意:根据IEEE标准802.11i-2004，附件H.4.1，用户可以将键作为64个十六进制数字的字符串(或者作为可打印ASCII字符的口令)输入。大概WEP和WPA规定了类似的限制。SSID必须是1到32字节之间的序列，没有指定的字符集(在这个StackOverflow答案中有更多的细节)，以及如何将SSID显示给最终用户应用程序(但是许多路由器显然只接受SSID的可打印ASCII字符)。

因此，如果我们假设ASCII字符编码为8位值，那么每个值都包含一个高和低的nibble,如:“M”在ASCII中是十六进制0x4D，高nibble是0x4，下nibble是0xD。

如果我们保持一个从0开始的序列号，并且每次生成一个值，然后为SSID的字符i(由高和低的nibble Hi和Li组成)，我们分别生成两个值，分别是序列号2i和(2i + 1)。每一个值都有一个高和低的nibble计算如下:

注意，包含i的高nibble的值是在包含i的低nibble之前生成的，并注意到caret，即。这里使用“^”,意味着XOR,而不是权力。

下面显示了SSID“MyPlace”将如何被分割成高和低的小块:

对于每4位nibble，我们生成一个值，它的下4位由nibble本身组成，其较高的4位包含了当前序列号和之前使用的nibble值的值。然后我们加上上面提到的常数C，即593，以这种方式生成的每个值，这就变成了编码这样一个值的包的长度。

注意，4位约束意味着我们只使用当前序号的下4位，即如果序号S在15以上，那么我们使用S % 16。

关键字以同样的方式编码，注意序列号在编码关键字时从0重新开始，也就是说，该值不是从编码SSID进行的。

目前，智能配置在关键字长度上设置了32个字符的上限，即短于相关WPA2标准允许的最大长度。

发现了一种方法，即从一个安全的无线网络向一个外部的一方(没有相关的网络关键字)主动地泄露信息，这很有趣，并且想知道是否有人曾经遇到过它，或者它是否新颖?我在Stack Overflow上问过这个问题，但后来我把这个问题转移到了姐妹网站crypto.stackexchange.com，因为人们认为那里更合适。

更新:2013年10月21日:我至少得到了一个好答案。在2007年的一篇论文中，P. Martin称“安全无线网络中的秘密通道”，你可以找到第4.4.2节“UDP数据包大小与MAC框架大小的实验”，它基本上描述了智能配置所使用的过程。关于智能配置，专利的问题已经出现了一两次(尽管从来没有人提供过任何实际的专利申请或授予专利号的指针)。我的问题的答案和其他评论似乎表明，智能配置背后的基本思想是绝对先于艺术的。

选择UDP包的目的地。当前的逻辑总是将UDP消息发送到默认网关地址，该消息会将SSID等编码到默认网关地址。然而，只要它是网络上另一台实际存在且能够接收数据包的另一台机器的地址，它们被发送到哪个地址并不重要。然而，决定一个明确的地址是有道理的。

CC3000不支持自组织网络，因此你永远不会得到一个在没有访问点(AP)的网络上使用它的情况，而且在大多数正常的设置中，AP也是默认网关。但是我不认为一个默认网关是强制性的(有人可以在这个问题上纠正我吗?)，你可以想象一个自我包含的wifi网络，在那里AP并不是通向其他任何地方的门户。

我不知道为什么我没有选择AP的地址而不是默认的网关。即使两者几乎总是相同的，我认为最终用户可能会有更多的运气，如果需要，询问谷歌或他们的ISP一级技术支持他们如何找到他们的wifi AP的地址，而不是询问默认网关。

注意:在一个使用AP的网络中，所有的流量都通过AP，所以即使一个人选择了一个机器的地址，而不是AP，流量仍然会被AP接收并通过AP重新传输到目标机器。如果您尝试使用CC3000，这不会引起问题，但它确实意味着毫无意义地复制了流量。 智能配置库的详细信息。 上面的部分覆盖的核心智能配置是如何工作的,下面介绍了TI的智能配置Java applet库的详细资料,不要立即似乎有关——他们可能会遗留下来的开发过程,或者他们可能刚刚没有清理掉与非默认的功能,可以使用如果某个CC3000设备配置在一个特定的方式。

可以设置用于将UDP数据包发送到另一个简单的设置，以绑定到本地机器上的任何可用端口的DatagramSocket。 可以将UDP数据包发送到的端口设置为15000。 一个可以设置mDNS UDP消息的端口，而不是5353。 一个可以设置的超时，即应用程序等待的时间，为CC3000启用的设备连接到5分钟以外的东西。 你可以设定所有细节的次数，在100毫秒的停顿前重新发送。默认情况下，这是1，也就是说，在每个详细信息传输之间，逻辑需要100毫秒的停顿。

我们可以设置两个分隔符值，即上面提到的3和23，以不同的值，更奇怪的是设置用来组成数据包的字符。

这些特性在库中是可用的，但是在这个库的顶部构建的TI智能配置应用程序从来没有使用过这些特性。

还可以设置用于侦听mDNS消息的套接字的网络接口。然而，这似乎完全没有意义，因为这只会影响到传出的多播数据报，而相关的逻辑只是寻找输入的数据报。

有一个例外，所有这些可配置性看起来毫无意义。

很难想象为什么要指定用于发送UDP数据包的DatagramSocket的绑定地址。 接收信息包的机器将忽略它们，因此选择一个特定的端口似乎是不相关的，并且加密的网络流量不能看到端口信息，因此它不应该与CC3000设备检测相关流量的能力有关。 mDNS总是使用端口5353，并且考虑到mDNS是如何使用的，很难想象端口号在特定的网络上被改变。 超时是相当随意的，5分钟看起来很长，所以如果一个人真的关心这个问题，调整它似乎是合理的。 能够在暂停之前设置完全重新传输的数量没有明显的好处。 这使我们能够改变分隔符的长度。也许这是可配置的CC3000设备。我看不到你想要改变默认值的原因。如果我怀疑一个人必须小心选择什么值。名称和标记值的短语,和常数C L上面所提到的,随着两个分隔符长度值,似乎都已被选定,确保没有重叠值之间的一种东西,另一个,当前设置意味着没有包长度编码的啃名称字符或短语最终将长度等于标签或分隔符的值。

注:上面提到的港口数字15000没有被TI注册，实际上属于一个名为hydap的合法服务，该服务已由HYPACK Inc.与IANA注册。这对任何人来说都不是问题。

多播中数 上面你看到了一些mDNS。这涉及到检测CC3000设备已经成功地连接到网络，并在本文中详细讨论。 CC3000用什么字符集? 智能配置Java applet库将SSID等存储为标准Java字符串，即Unicode字符序列。它转换这些字符串和数组之间的后退和前进的字节数在不同的点,但是不接受的字符集,如当它调用String.getBytes()总是使用表单使用平台的默认字符集。这将在大多数系统工作,包括几乎所有的东西都在美国和西欧,但显然是一个问题。CC3000可能有一个固定的字符集，在转换字符和字节时，应该在库中显式地使用它。

更新:实验表明，虽然TI Java applet库只是使用它正在运行的机器的默认字符集，但当转换到字节时，TI iOS和Android应用程序似乎都一致地使用UTF-8。

来自TI智能配置应用程序的数据包长度转储。 如果上面的任何一项都不太清楚，希望这一节将有助于提供一个实际的示例，说明TI智能配置应用程序在发送SSID“MyPlace”和密码“LetMeIn”时所生成的数据包长度。

第一个转储显示了由Android和Java applet应用程序生成的数据包长度。第一个colum只显示了发送包的UNIX时间，第二列显示了包的长度，然后是一个表示包长度编码的指示。

1381084544.032552000 1399