引言
概念
SmartConfig又名快连
- 当前设备在没有和其他设备建立任何实际性通信链接的状态下，一键配置该设备接入WIFI
虚构连接一个实际场景
- 当手机端A接入WIFI
S， 设备B没有任何实质性通信链接（信息孤立）- 如果设备
B也想接入这个S - 肯定需要有人告诉
B，S的的ssid、password - 目前我们只有A的资源可以利用，所以只能
A告诉B
- 如果设备
B在没有任何链接的情况下，A是如何告知B设备S的信息，这便是SmartConfig
虚构一个SmartConfig技术实现快连的场景
准备一个支持Smartconfig技术的设备
1.启动这个设备
2.安装制造商提供的手机app
3.在设备附近打开App，输入需要接入的WIFI信息，确认，不出意外的话就会链接上这个设备
SmartConfig的实现厂商
| 编号 | 厂商 | 芯片厂商 | 技术名称 | 发包方式 |
|---|---|---|---|---|
| 1 | TI | CC3200 | SmartConfig | 往某一个固定IP发UDP包 |
| 2 | 高通 | QCA4004/QCA4002 | SmartConnection | - |
| 3 | 联发科MTK | MTK7681 | SmartConnection | 组播地址编码 |
| 4 | MARVELL | MC200+8801/MW300 | EasyConnect | 组播地址编码 |
| 5 | Reltek | AMEBA | SimpleConfig | 组播地址编码 |
| 6 | 乐鑫 | ESP8266 | SmartConfig | 组播，通过长度编码 |
| 7 | 新案线 | NL6621 | SmartConfig | 组播地址编码 |
| 8 | 微信 | - | AirKiss | 全网广播，通过长度编码 |
SmartCongfig的实际操作
上述厂商，是我能查到的应用到市场上面的几个厂商，如有补充请下面评论区，给哥么提醒一下。
哥么看到上面这么多的厂商，怎么搞？怎么开发？
- 首先根据自己的需要、国家地区选择最切实际的一个厂家
- 肯定需要一个硬件，那么就度娘、谷爹搜索到设备厂商，买一个支持SmartConfig的硬件，进行尝试。（买不起硬件,出门右拐淘宝）
实现过程
首先需求公司要做一个灯泡、插座、一件配置的一款App，
- 需要硬件支持
- App
- 成功率 10 6这种层次
经过一段时间的筛选，我们最终决定了用乐鑫,
原因： 1. 有现成的开发板
2. 文档工具都有
3. 国内厂商也好沟通
4. 满足我们的需求
然后开始整合资料，整合资源
ESP8266完全教程资源包
乐鑫、ESP8266芯片
源代码
两种配置模式：
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或更高(这是任何正常网络的合理期望)。
- TI智能配置参考实现会重复发送与SSID和keyphrase相对应的完整的UDP数据包集。在完整的整套值传输完成后，TI Java applet库暂停了100ms, Android和iOS的库不需要暂停。
编码SSID或关键短语的字符。
如果一个SSID由n个0到n - 1组成，那么我们就产生了2n个相应的值。
注意:根据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计算如下:
image.png
注意，包含i的高nibble的值是在包含i的低nibble之前生成的，并注意到caret，即。这里使用“^”,意味着XOR,而不是权力。
-
下面显示了SSID“MyPlace”将如何被分割成高和低的小块:
image.png
对于每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 <----- SSID tag
1381084544.033572000 35 <----- SSID length + 28
1381084544.033589000 3 <--+-- separator
1381084544.033594000 23 <--'
1381084544.033667000 597 <----- 'M' hi-nibble
1381084544.033675000 3 <--+-- separator
1381084544.033723000 23 <--'
1381084544.034369000 686 <----- 'M' lo-nibble
1381084544.035385000 3 <--+-- separator
1381084544.036271000 23 <--'
1381084544.036448000 840 <----- 'y' hi-nibble
1381084544.036467000 3 <--+-- separator
1381084544.036481000 23 <--'
1381084544.036541000 666 <----- 'y' lo-nibble
1381084544.037262000 3 <--+-- separator
1381084544.037271000 23 <--'
1381084544.037496000 806 <----- 'P' hi-nibble
1381084544.038019000 3 <--+-- separator
1381084544.038032000 23 <--'
1381084544.038097000 593 <----- 'P' lo-nibble
1381084544.043096000 3 <--+-- separator
1381084544.044209000 23 <--'
1381084544.044785000 695 <----- 'l' hi-nibble
1381084544.045422000 3 <--+-- separator
1381084544.045855000 23 <--'
1381084544.048359000 621 <----- 'l' lo-nibble
1381084544.049327000 3 <--+-- separator
1381084544.049347000 23 <--'
1381084544.049406000 663 <----- 'a' hi-nibble
1381084544.049412000 3 <--+-- separator
1381084544.049416000 23 <--'
1381084544.049568000 834 <----- 'a' lo-nibble
1381084544.050052000 3 <--+-- separator
1381084544.050067000 23 <--'
1381084544.050808000 775 <----- 'c' hi-nibble
1381084544.051463000 3 <--+-- separator
1381084544.052082000 23 <--'
1381084544.055415000 804 <----- 'c' lo-nibble
1381084544.056319000 3 <--+-- separator
1381084544.056334000 23 <--'
1381084544.056398000 839 <----- 'e' hi-nibble
1381084544.056404000 3 <--+-- separator
1381084544.056407000 23 <--'
1381084544.056644000 774 <----- 'e' lo-nibble
1381084544.058021000 3 <--+-- separator
1381084544.058034000 23 <--'
1381084544.059236000 1459 <----- passphrase tag
1381084544.059252000 35 <----- passphrase length + 28
1381084544.059255000 3 <--+-- separator
1381084544.059258000 23 <--'
1381084544.059261000 597 <----- 'L' hi-nibble
1381084544.059937000 3 <--+-- separator
1381084544.059949000 23 <--'
1381084544.060043000 685 <----- 'L' lo-nibble
1381084544.060723000 3 <--+-- separator
1381084544.060729000 23 <--'
1381084544.060884000 823 <----- 'e' hi-nibble
1381084544.061407000 3 <--+-- separator
1381084544.061411000 23 <--'
1381084544.061954000 678 <----- 'e' lo-nibble
1381084544.062651000 3 <--+-- separator
1381084544.062709000 23 <--'
1381084544.063217000 616 <----- 't' hi-nibble
1381084544.063696000 3 <--+-- separator
1381084544.063699000 23 <--'
1381084544.064344000 629 <----- 't' lo-nibble
1381084544.064893000 3 <--+-- separator
1381084544.064897000 23 <--'
1381084544.065561000 629 <----- 'M' hi-nibble
1381084544.066131000 3 <--+-- separator
1381084544.066221000 23 <--'
1381084544.066947000 654 <----- 'M' lo-nibble
1381084544.066955000 3 <--+-- separator
1381084544.067371000 23 <--'
1381084544.067491000 679 <----- 'e' hi-nibble
1381084544.067871000 3 <--+-- separator
1381084544.068325000 23 <--'
1381084544.069089000 838 <----- 'e' lo-nibble
1381084544.069097000 3 <--+-- separator
1381084544.069593000 23 <--'
1381084544.069711000 837 <----- 'I' hi-nibble
1381084544.070191000 3 <--+-- separator
1381084544.070656000 23 <--'
1381084544.074244000 842 <----- 'I' lo-nibble
1381084544.074259000 3 <--+-- separator
1381084544.075225000 23 <--'
1381084544.075286000 679 <----- 'n' hi-nibble
1381084544.075291000 3 <--+-- separator
1381084544.075293000 23 <--'
1381084544.075521000 783 <----- 'n' lo-nibble
1381084544.075533000 3 <--+-- separator
1381084544.076058000 23 <--'
-------------------------- No delay on Android, 100ms delay with Java applet library, then repeat from start again.
1381084544.076246000 1399 <----- SSID tag
1381084544.076850000 35 <----- SSID length + 28
...
- 由TI iOS和Java applet智能配置应用程序生成的输出是相同的(除了记录的100ms延迟)。然而，奇怪的是，iOS智能配置应用程序并没有在SSID和keyphrase的字符之间插入分隔符3和23，相反，它总是发送一个10个分隔符值对的序列，如图所示，然后发送SSID和keyphrase。这里很难调用3和23分隔符但我在这里用了这个名字
1381085051.154799000 3 <--+-- separator 1
1381085051.159414000 23 <--'
1381085051.164143000 3 <--+-- separator 2
1381085051.170050000 23 <--'
1381085051.174861000 3 <--+-- separator 3
1381085051.179503000 23 <--'
1381085051.185282000 3 <--+-- separator 4
1381085051.190274000 23 <--'
1381085051.195296000 3 <--+-- separator 5
1381085051.200047000 23 <--'
1381085051.206394000 3 <--+-- separator 6
1381085051.211076000 23 <--'
1381085051.215383000 3 <--+-- separator 7
1381085051.225363500 23 <--'
1381085051.235344000 3 <--+-- separator 8
1381085051.235459000 23 <--'
1381085051.236902000 3 <--+-- separator 9
1381085051.241718000 23 <--'
1381085051.249366000 3 <--+-- separator 10
1381085051.253099000 23 <--'
1381085051.257767000 1399 <----- SSID tag
1381085051.262315500 35 <----- SSID length + 28
1381085051.266864000 597 <----- 'M' hi-nibble
1381085051.273117000 686 <----- 'M' lo-nibble
1381085051.278023500 840 <----- 'y' hi-nibble
1381085051.282930000 666 <----- 'y' lo-nibble
1381085051.291178000 806 <----- 'P' hi-nibble
1381085051.294688000 593 <----- 'P' lo-nibble
1381085051.299266000 695 <----- 'l' hi-nibble
1381085051.308603000 621 <----- 'l' lo-nibble
1381085051.311723000 663 <----- 'a' hi-nibble
1381085051.315706000 834 <----- 'a' lo-nibble
1381085051.321567000 775 <----- 'c' hi-nibble
1381085051.326156000 804 <----- 'c' lo-nibble
1381085051.332654000 839 <----- 'e' hi-nibble
1381085051.337025000 774 <----- 'e' lo-nibble
1381085051.342818000 1459 <----- passphrase tag
1381085051.346519000 35 <----- passphrase length + 28
1381085051.353083000 597 <----- 'L' hi-nibble
1381085051.359196000 685 <----- 'L' lo-nibble
1381085051.362984000 823 <----- 'e' hi-nibble
1381085051.366772000 678 <----- 'e' lo-nibble
1381085051.373192000 616 <----- 't' hi-nibble
1381085051.382117000 629 <----- 't' lo-nibble
1381085051.386131000 629 <----- 'M' hi-nibble
1381085051.390145000 654 <----- 'M' lo-nibble
1381085051.393997000 679 <----- 'e' hi-nibble
1381085051.400047000 838 <----- 'e' lo-nibble
1381085051.404880000 837 <----- 'I' hi-nibble
1381085051.412003000 842 <----- 'I' lo-nibble
1381085051.414365000 679 <----- 'n' hi-nibble
1381085051.420336000 783 <----- 'n' lo-nibble
--------------------------- No delay then repeat from start again.
1381085051.432048500 3 <--+-- separator 1
1381085051.443761000 23 <--'
使用tshark对wifi包进行转储和解密。上面的转储是用著名的包分析工具Wireshark的命令行版本生成的，称为tshark。Wireshark可用于Mac OS X、Windows和Linux。下面展示了我如何使用它来生成这些转储文件。
首先，我在使用特定的TI智能配置应用程序之前，先开始记录数据包。
$ tshark -i en0 -I -w output.pcap
注意我标记使您的机器的无线网络接口进入监控模式,这对其他禁用标准网络访问tshark运行时机器但允许tshark看到所有的交通网络上,不仅交通用于机器上运行。在我的Mac上，将网络接口放入监控模式运行良好，但在其他平台上，这可能会更加复杂——我将在以后的文章中进一步讨论这个问题。
然后，我在另一台机器上运行了特别的智能配置应用程序，比如iPhone、Android手机或一台不同的台式机。我点击了每个智能配置应用程序中的start按钮，告诉它开始传输SSID等，并让它运行一段时间。不需要有一个实际的CC3000支持设备监听数据。几秒钟后，我用control-C杀死了tshark进程，并在智能配置应用程序中点击了stop。
产生的网络流量最终在文件输出中结束。pcap，注意这个文件的大小可以快速增长，因为我们在一个给定的wifi通道上记录所有的流量，不只是智能配置相关的流量。
然后我们就可以过滤掉智能配置的流量，然后像上面那样把它转储出来:
$ tshark -r output.pcap -o 'wlan.enable_decryption:TRUE'
-Y 'wlan.fc.retry == 0 && !icmp && udp && ip.src == 192.168.1.177 && ip.dst == 192.168.1.1 && udp.dstport == 15000'
-T fields -e frame.time_epoch -e data.len | head -n 512
- 必须将src更改为运行智能配置应用程序的设备的IP地址，例如iPhone和IP。dst必须是应用程序作为网关使用的IP地址。
注意，我排除了icmp包，这些是控制包，可以包含与UDP过滤器匹配的嵌入式UDP数据包。在我们的例子中，生成icmp包，告诉我们我们发送的数据包是不可到达的。wlan.fc。重试过滤器我也不排除重传数据包——我将在后面的帖子中讨论这个。
如这里所示，tshark实际上可以解密wifi数据包(这是一个CC3000支持的设备，它在等待网络密码显然无法做到)。这样，它就可以使用更高级别的网络术语(比如IP协议)来过滤流量，比如UDP和IP地址。
如果选择wlan。enable_decryption设置为TRUE，如上所示，tshark将搜索在文件~/中进行解密所需的关键短语。wireshark/80211_keys，希望找到类似的东西:
"wpa-pwd","LetMeIn:MyPlace"
请注意，关键字出现在SSID之前，而在文件80211_keys中存储密钥(是的)对wireshark/tshark来说是相对陌生的。对于早期版本的tshark，您可能需要指定关键信息作为命令行选项-谷歌为您的版本工作。
但是，即使它有一个关键短语，它也只能对流量进行解密，如果您的pcap文件包含了由ip指定的设备生成的EAPOL包。src通过与美联社的安全连接的初步谈判，迫使我的设备产生这样的数据包，我将手机在飞机模式和我的台式机上移动，我暂时禁用了，然后重新启用了wifi。这似乎并不总是有效——我不知道即使是禁用和重新启用设备，有时也可以避免重新协商它的连接。我们可以检查pcap文件是否包含这样的EAPOL数据包:
$ tshark -r sc-ios.pcap -Y eapol您应该看到大约四个与您的设备相对应的包(检查显示的MAC地址是否与设备的MAC地址相匹配)。
显然CC3000无法解密这样的数据包