引言

概念

SmartConfig又名快連

• 當前設備在沒有和其他設備建立任何實際性通信鏈接的狀態(tài)下痕支，一鍵配置該設備接入WIFI

虛構連接一個實際場景

• 當手機端A接入WIFIS， 設備B沒有任何實質(zhì)性通信鏈接（信息孤立）
  • 如果設備B也想接入這個S
  • 肯定需要有人告訴B辩撑，S的的ssid纱新、password
  • 目前我們只有A的資源可以利用奢驯，所以只能A 告訴B

B在沒有任何鏈接的情況下适掰，A是如何告知B設備S的信息估蹄，這便是SmartConfig

虛構一個SmartConfig技術實現(xiàn)快連的場景

準備一個支持Smartconfig技術的設備
1.啟動這個設備
2.安裝制造商提供的手機app
3.在設備附近打開App塑煎，輸入需要接入的WIFI信息，確認臭蚁，不出意外的話就會鏈接上這個設備

SmartConfig的實現(xiàn)廠商

SmartCongfig的實際操作

上述廠商垮兑，是我能查到的應用到市場上面的幾個廠商冷尉，如有補充請下面評論區(qū)，給哥么提醒一下系枪。
哥么看到上面這么多的廠商雀哨，怎么搞？怎么開發(fā)私爷？

• 首先根據(jù)自己的需要雾棺、國家地區(qū)選擇最切實際的一個廠家
• 肯定需要一個硬件，那么就度娘当犯、谷爹搜索到設備廠商垢村，買一個支持SmartConfig的硬件，進行嘗試嚎卫。（買不起硬件,出門右拐淘寶）

實現(xiàn)過程

首先需求公司要做一個燈泡嘉栓、插座、一件配置的一款App拓诸，

1. 需要硬件支持
2. App
3. 成功率 10 6這種層次
   經(jīng)過一段時間的篩選侵佃，我們最終決定了用樂鑫,
   原因： 1. 有現(xiàn)成的開發(fā)板
   2. 文檔工具都有
   3. 國內(nèi)廠商也好溝通
   4. 滿足我們的需求
   然后開始整合資料，整合資源
   ESP8266完全教程資源包

樂鑫奠支、ESP8266芯片

源代碼
兩種配置模式：
1.Ap模式：

AP 是 (Wireless) AccessPoint 的縮寫馋辈，即 (無線) 訪問接入點。簡單來講就像是無線路由器一樣倍谜，設備打開后進入 AP 模式迈螟，在手機的網(wǎng)絡列表里面叉抡，可以搜索到類似 TPLINK_XXX 的名字（SSID）

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

esp8266進入混雜、SmartConfig esp8266先scan下AP 答毫，得到AP的相關信息,如工作的channel,然后配置wifi芯片工作在剛才scan到的channel上去接收UDP包褥民，如果沒有接收到，繼續(xù)配置ESP8266工作在另外的channel上洗搂，如此循環(huán)消返，直到收到UDP包為止

為什么要提前進行SCAN 下WIFI AP？

為了提高配置效率耘拇。假設當前網(wǎng)絡中只有兩個AP,一個AP工作在CHANEL1撵颊，另外個 ap工作在channel13,我們現(xiàn)在需要配置智能硬件連接到AP2 ,就是channel13上，如果不提前scan就需要從1--13掃描浪費時間 就是需要從channel1-chane2---...channnel13一直掃描了惫叛，如果掃描了AP倡勇，芯片馬上從AP CHANNNEL1 到channel13加快獲取到UDP包；

擴展

通過Yeelink提供的數(shù)據(jù)接口挣棕，用戶可以把自己的傳感器通過互聯(lián)網(wǎng)接入Yeelink物聯(lián)網(wǎng)云平臺译隘，從而實現(xiàn)隨時隨地獲取傳感器數(shù)據(jù)，為一些智能家居設備接入互聯(lián)網(wǎng)提供了物聯(lián)網(wǎng)云平臺支持洛心。

調(diào)試過程：

這個在谷歌找到的關于ti的Smartconfig的工作原理
CC3000 Smart Config - transmitting SSID and keyphrase
How does TI CC3000 wifi smart config work?
這兩篇寫的很詳細,下面開始是一篇文章的翻譯固耘，水準別看了就看個大概吧。

• 讓我們從頭開始,哥么有一個問題——哥么想要發(fā)送兩條信息,一個名稱和密碼词身，A在一個連接WIFI狀態(tài)下厅目，B在一個無網(wǎng)狀態(tài)下，但是B在監(jiān)聽周圍所擁有無線網(wǎng)絡流量法严，但是這些流量不能解密损敷。

• 無法解密wifi通信的人仍然可以看到很多信息，例如深啤，他們可以看到發(fā)送的每個數(shù)據(jù)包的源和接收者MAC地址拗馒。

• 哥么可以看到數(shù)據(jù)包的數(shù)據(jù)部分的長度。加密影響發(fā)送的數(shù)據(jù)包的大小溯街，但以一致的方式诱桂，例如，如果一個數(shù)據(jù)包在給定的數(shù)據(jù)包中發(fā)送了n字節(jié)的數(shù)據(jù)呈昔，那么加密的數(shù)據(jù)包將包含(n + x)字節(jié)挥等，其中x在所有數(shù)據(jù)包中是恒定的。

• 因此堤尾，我們的問題的解決方案是對發(fā)送的數(shù)據(jù)包的大小進行編碼(實際內(nèi)容是不相關的)肝劲。

• 安全網(wǎng)絡上的一方只向網(wǎng)絡上的另一方發(fā)送特定長度的UDP數(shù)據(jù)包。另一方對收到信息包不感興趣并不重要。

• 外部方不能直接知道包中包含UDP數(shù)據(jù)辞槐，但是包仍然包含基本類型信息掷漱，允許將許多數(shù)據(jù)包排除在考慮之外，例如任何不屬于802.11子類型“QoS數(shù)據(jù)”的包都可以被排除催蝗。

• 由于外部方事先不知道要查看哪一個wifi通道或哪個源和接收地址對必須注意一個切威，除了基礎數(shù)據(jù)，即編碼的SSID等丙号，還需要定期發(fā)送允許該數(shù)據(jù)被發(fā)現(xiàn)的重復模式。

• 我們將我們的SSID和keyphrase轉換成一系列標記值缰冤、字符串長度犬缨、nibble值和分隔符值，然后將所有這些值編碼并傳輸為數(shù)據(jù)包長度棉浸。

• 我們使用兩個標簽——一個是1399 代表SSID標簽和一個值1459的關密碼標簽和一個標準分隔符序列怀薛，包含兩個值- 3和23。

• 我們使用兩個常數(shù)迷郑，L值為28枝恋，而C值為593，我們將在下面看到嗡害。因此焚碌，對于SSID，按照以下順序生成下列值序列:

• 1399 代表ssid 名稱

• L加上以字節(jié)為單位的SSID的長度霸妹。

• 這兩個分隔符值為3和23十电。

• 然后我們對SSID的每個字節(jié)進行循環(huán)，并為每個字節(jié)生成一組4個值:
  兩個值—一個用于字節(jié)的每個字節(jié)叹螟，如下一節(jié)所述鹃骂。

• 然后是兩個分離器值3和23。

• 值以相同的方式生成罢绽，用于關鍵短語(ssid = 1399 password = 1459)畏线。

注意:TI Android library和Java applet庫生成了如上所述的值，奇怪的是良价，TI iOS庫產(chǎn)生了稍微不同的排序(這顯然不會影響CC3000解碼數(shù)據(jù)的能力)寝殴。這種差異可以在后面的示例數(shù)據(jù)長度轉儲中看到。

• 一旦我們有了所有這些值然后UDP數(shù)據(jù)包,每一個對應于一個值的數(shù)據(jù)量,從機發(fā)送運行智能配置應用程序,即一個剛剛描述的值生成,到另一個系統(tǒng)在同一網(wǎng)絡(目前總是網(wǎng)絡的默認網(wǎng)關)棚壁。

• 值發(fā)送多次,直到外部黨,即CC3000啟用設備,成功地處理他們從所有其他的網(wǎng)絡流量,并使用它們來連接網(wǎng)絡,這時它的廣告出現(xiàn)在網(wǎng)絡的方式傳輸應用程序可以檢測并導致它停止傳輸杯矩。

請注意，需要支持的包長度范圍在網(wǎng)絡的最大傳輸單元(MTU)上有一個下界袖外。目前史隆，智能配置客戶端應用程序期望MTU達到1500或更高(這是任何正常網(wǎng)絡的合理期望)。

• TI智能配置參考實現(xiàn)會重復發(fā)送與SSID和keyphrase相對應的完整的UDP數(shù)據(jù)包集曼验。在完整的整套值傳輸完成后，TI Java applet庫暫停了100ms, Android和iOS的庫不需要暫停炒考。
  編碼SSID或關鍵短語的字符盗温。
  如果一個SSID由n個0到n - 1組成，那么我們就產(chǎn)生了2n個相應的值孤紧。

注意:根據(jù)IEEE標準802.11i-2004，附件H.4.1拒秘，用戶可以將鍵作為64個十六進制數(shù)字的字符串(或者作為可打印ASCII字符的口令)輸入号显。大概WEP和WPA規(guī)定了類似的限制。SSID必須是1到32字節(jié)之間的序列躺酒，沒有指定的字符集(在這個StackOverflow答案中有更多的細節(jié))押蚤，以及如何將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值的值赫编。然后我們加上上面提到的常數(shù)C巡蘸，即593，以這種方式生成的每個值擂送，這就變成了編碼這樣一個值的包的長度悦荒。

注意，4位約束意味著我們只使用當前序號的下4位嘹吨，即如果序號S在15以上搬味，那么我們使用S % 16。

• 關鍵字以同樣的方式編碼，注意序列號在編碼關鍵字時從0重新開始碰纬，也就是說萍聊，該值不是從編碼SSID進行的。

• 目前悦析，智能配置在關鍵字長度上設置了32個字符的上限寿桨，即短于相關WPA2標準允許的最大長度。

• 發(fā)現(xiàn)了一種方法强戴，即從一個安全的無線網(wǎng)絡向一個外部的一方(沒有相關的網(wǎng)絡關鍵字)主動地泄露信息亭螟，這很有趣，并且想知道是否有人曾經(jīng)遇到過它骑歹，或者它是否新穎?我在Stack Overflow上問過這個問題媒佣，但后來我把這個問題轉移到了姐妹網(wǎng)站crypto.stackexchange.com，因為人們認為那里更合適陵刹。

• 更新:2013年10月21日:我至少得到了一個好答案。在2007年的一篇論文中欢嘿，P. Martin稱“安全無線網(wǎng)絡中的秘密通道”衰琐，你可以找到第4.4.2節(jié)“UDP數(shù)據(jù)包大小與MAC框架大小的實驗”，它基本上描述了智能配置所使用的過程炼蹦。關于智能配置羡宙，專利的問題已經(jīng)出現(xiàn)了一兩次(盡管從來沒有人提供過任何實際的專利申請或授予專利號的指針)。我的問題的答案和其他評論似乎表明掐隐，智能配置背后的基本思想是絕對先于藝術的狗热。

• 選擇UDP包的目的地。當前的邏輯總是將UDP消息發(fā)送到默認網(wǎng)關地址虑省，該消息會將SSID等編碼到默認網(wǎng)關地址匿刮。然而，只要它是網(wǎng)絡上另一臺實際存在且能夠接收數(shù)據(jù)包的另一臺機器的地址探颈，它們被發(fā)送到哪個地址并不重要熟丸。然而，決定一個明確的地址是有道理的伪节。

• CC3000不支持自組織網(wǎng)絡光羞，因此你永遠不會得到一個在沒有訪問點(AP)的網(wǎng)絡上使用它的情況，而且在大多數(shù)正常的設置中怀大，AP也是默認網(wǎng)關纱兑。但是我不認為一個默認網(wǎng)關是強制性的(有人可以在這個問題上糾正我嗎?)，你可以想象一個自我包含的wifi網(wǎng)絡化借，在那里AP并不是通向其他任何地方的門戶潜慎。

• 我不知道為什么我沒有選擇AP的地址而不是默認的網(wǎng)關。即使兩者幾乎總是相同的，我認為最終用戶可能會有更多的運氣勘纯，如果需要局服，詢問谷歌或他們的ISP一級技術支持他們?nèi)绾握业剿麄兊膚ifi AP的地址，而不是詢問默認網(wǎng)關驳遵。

注意:在一個使用AP的網(wǎng)絡中淫奔，所有的流量都通過AP，所以即使一個人選擇了一個機器的地址堤结，而不是AP唆迁，流量仍然會被AP接收并通過AP重新傳輸?shù)侥繕藱C器。如果您嘗試使用CC3000竞穷，這不會引起問題唐责，但它確實意味著毫無意義地復制了流量。
智能配置庫的詳細信息瘾带。
上面的部分覆蓋的核心智能配置是如何工作的,下面介紹了TI的智能配置Java applet庫的詳細資料,不要立即似乎有關——他們可能會遺留下來的開發(fā)過程,或者他們可能剛剛沒有清理掉與非默認的功能,可以使用如果某個CC3000設備配置在一個特定的方式鼠哥。

• 可以設置用于將UDP數(shù)據(jù)包發(fā)送到另一個簡單的設置，以綁定到本地機器上的任何可用端口的DatagramSocket看政。
  可以將UDP數(shù)據(jù)包發(fā)送到的端口設置為15000朴恳。
  一個可以設置mDNS UDP消息的端口，而不是5353允蚣。
  一個可以設置的超時于颖，即應用程序等待的時間，為CC3000啟用的設備連接到5分鐘以外的東西嚷兔。
  你可以設定所有細節(jié)的次數(shù)森渐，在100毫秒的停頓前重新發(fā)送。默認情況下冒晰，這是1同衣，也就是說，在每個詳細信息傳輸之間翩剪，邏輯需要100毫秒的停頓乳怎。

• 我們可以設置兩個分隔符值，即上面提到的3和23前弯，以不同的值蚪缀，更奇怪的是設置用來組成數(shù)據(jù)包的字符。

• 這些特性在庫中是可用的恕出，但是在這個庫的頂部構建的TI智能配置應用程序從來沒有使用過這些特性询枚。

• 還可以設置用于偵聽mDNS消息的套接字的網(wǎng)絡接口。然而浙巫，這似乎完全沒有意義金蜀，因為這只會影響到傳出的多播數(shù)據(jù)報刷后，而相關的邏輯只是尋找輸入的數(shù)據(jù)報。

• 有一個例外渊抄，所有這些可配置性看起來毫無意義尝胆。

• 很難想象為什么要指定用于發(fā)送UDP數(shù)據(jù)包的DatagramSocket的綁定地址。
  接收信息包的機器將忽略它們护桦，因此選擇一個特定的端口似乎是不相關的含衔，并且加密的網(wǎng)絡流量不能看到端口信息，因此它不應該與CC3000設備檢測相關流量的能力有關二庵。
  mDNS總是使用端口5353贪染，并且考慮到mDNS是如何使用的，很難想象端口號在特定的網(wǎng)絡上被改變催享。
  超時是相當隨意的杭隙，5分鐘看起來很長，所以如果一個人真的關心這個問題因妙，調(diào)整它似乎是合理的痰憎。
  能夠在暫停之前設置完全重新傳輸?shù)臄?shù)量沒有明顯的好處。
  這使我們能夠改變分隔符的長度攀涵。也許這是可配置的CC3000設備信殊。我看不到你想要改變默認值的原因。如果我懷疑一個人必須小心選擇什么值汁果。名稱和標記值的短語,和常數(shù)C L上面所提到的,隨著兩個分隔符長度值,似乎都已被選定,確保沒有重疊值之間的一種東西,另一個,當前設置意味著沒有包長度編碼的啃名稱字符或短語最終將長度等于標簽或分隔符的值。

注:上面提到的港口數(shù)字15000沒有被TI注冊玲躯，實際上屬于一個名為hydap的合法服務据德，該服務已由HYPACK Inc.與IANA注冊。這對任何人來說都不是問題跷车。

• 多播中數(shù)
  上面你看到了一些mDNS棘利。這涉及到檢測CC3000設備已經(jīng)成功地連接到網(wǎng)絡，并在本文中詳細討論朽缴。
  CC3000用什么字符集?
  智能配置Java applet庫將SSID等存儲為標準Java字符串善玫，即Unicode字符序列。它轉換這些字符串和數(shù)組之間的后退和前進的字節(jié)數(shù)在不同的點,但是不接受的字符集,如當它調(diào)用String.getBytes()總是使用表單使用平臺的默認字符集密强。這將在大多數(shù)系統(tǒng)工作,包括幾乎所有的東西都在美國和西歐,但顯然是一個問題茅郎。CC3000可能有一個固定的字符集，在轉換字符和字節(jié)時或渤，應該在庫中顯式地使用它系冗。

• 更新:實驗表明，雖然TI Java applet庫只是使用它正在運行的機器的默認字符集薪鹦，但當轉換到字節(jié)時掌敬，TI iOS和Android應用程序似乎都一致地使用UTF-8惯豆。

• 來自TI智能配置應用程序的數(shù)據(jù)包長度轉儲。
  如果上面的任何一項都不太清楚奔害，希望這一節(jié)將有助于提供一個實際的示例楷兽，說明TI智能配置應用程序在發(fā)送SSID“MyPlace”和密碼“LetMeIn”時所生成的數(shù)據(jù)包長度。

• 第一個轉儲顯示了由Android和Java applet應用程序生成的數(shù)據(jù)包長度华临。第一個colum只顯示了發(fā)送包的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棋弥，相反，它總是發(fā)送一個10個分隔符值對的序列诚欠，如圖所示顽染，然后發(fā)送SSID和keyphrase。這里很難調(diào)用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智能配置應用程序之前振亮，先開始記錄數(shù)據(jù)包。

$ tshark -i en0 -I -w output.pcap

• 注意我標記使您的機器的無線網(wǎng)絡接口進入監(jiān)控模式,這對其他禁用標準網(wǎng)絡訪問tshark運行時機器但允許tshark看到所有的交通網(wǎng)絡上,不僅交通用于機器上運行鞭莽。在我的Mac上坊秸，將網(wǎng)絡接口放入監(jiān)控模式運行良好，但在其他平臺上澎怒，這可能會更加復雜——我將在以后的文章中進一步討論這個問題褒搔。

• 然后，我在另一臺機器上運行了特別的智能配置應用程序喷面，比如iPhone星瘾、Android手機或一臺不同的臺式機。我點擊了每個智能配置應用程序中的start按鈕惧辈，告訴它開始傳輸SSID等死相，并讓它運行一段時間。不需要有一個實際的CC3000支持設備監(jiān)聽數(shù)據(jù)咬像。幾秒鐘后算撮，我用control-C殺死了tshark進程生宛，并在智能配置應用程序中點擊了stop。

• 產(chǎn)生的網(wǎng)絡流量最終在文件輸出中結束肮柜。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必須是應用程序作為網(wǎng)關使用的IP地址。

注意痴晦，我排除了icmp包南吮，這些是控制包，可以包含與UDP過濾器匹配的嵌入式UDP數(shù)據(jù)包誊酌。在我們的例子中部凑，生成icmp包，告訴我們我們發(fā)送的數(shù)據(jù)包是不可到達的碧浊。wlan.fc涂邀。重試過濾器我也不排除重傳數(shù)據(jù)包——我將在后面的帖子中討論這個。

• 如這里所示箱锐，tshark實際上可以解密wifi數(shù)據(jù)包(這是一個CC3000支持的設備比勉，它在等待網(wǎng)絡密碼顯然無法做到)。這樣驹止，它就可以使用更高級別的網(wǎng)絡術語(比如IP協(xié)議)來過濾流量敷搪，比如UDP和IP地址。

• 如果選擇wlan幢哨。enable_decryption設置為TRUE，如上所示嫂便，tshark將搜索在文件~/中進行解密所需的關鍵短語捞镰。wireshark/80211_keys，希望找到類似的東西:

"wpa-pwd","LetMeIn:MyPlace"

• 請注意毙替，關鍵字出現(xiàn)在SSID之前岸售，而在文件80211_keys中存儲密鑰(是的)對wireshark/tshark來說是相對陌生的。對于早期版本的tshark厂画，您可能需要指定關鍵信息作為命令行選項-谷歌為您的版本工作凸丸。

• 但是，即使它有一個關鍵短語袱院，它也只能對流量進行解密屎慢，如果您的pcap文件包含了由ip指定的設備生成的EAPOL包瞭稼。src通過與美聯(lián)社的安全連接的初步談判，迫使我的設備產(chǎn)生這樣的數(shù)據(jù)包腻惠，我將手機在飛機模式和我的臺式機上移動环肘，我暫時禁用了，然后重新啟用了wifi集灌。這似乎并不總是有效——我不知道即使是禁用和重新啟用設備悔雹，有時也可以避免重新協(xié)商它的連接。我們可以檢查pcap文件是否包含這樣的EAPOL數(shù)據(jù)包:
  $ tshark -r sc-ios.pcap -Y eapol

• 您應該看到大約四個與您的設備相對應的包(檢查顯示的MAC地址是否與設備的MAC地址相匹配)欣喧。

• 顯然CC3000無法解密這樣的數(shù)據(jù)包