https://blog.csdn.net/lb5761311/article/details/77945848
AirKiss原理分析
一、 AirKiss概述
AirKiss技術是一種創新性的信息傳遞技術。通過該技術可以便捷的向一臺 與外界沒有建立任何一種實質性連接(包括有線、無線、藍牙、NFC等)的設備傳遞信息(可以是環境中Wifi的ssid、密碼等信息)。
AirKiss 技術示意圖如下圖所示，智能插座與外界沒有建立任何一種實質性連接， 可以稱之爲信息孤島。通過 Air Kiss 技術，微信客戶端 可以將環境中的 Wifi 的ssid 與密碼便捷的隔空傳遞給智能插座，從而使得智能插座能夠快速的接入 Wifi。
二、傳統配置上網過程
例如我們買了一個路由器，路由器是沒有按鍵和屏顯示的。而我們都知道，路由器要配置好運營商的賬號和密碼才能接入互聯網的。一般的做法都是路由器作爲熱點AP，其提供一個WebServer來設置路由的各項參數，默認IP是192.168.1.1（或者其他IP，路由器說明書上會說明）；我們通過電腦有線接入路由器，通過DHCP自動分配到一個192.168.1段的地址。然後通過瀏覽器來訪問http://192.168.1.1，即可以進入路由器設置界面進行設置，包括運營商的賬號和密碼、本機的SSID和密碼。然後我們的手機就可以開啓wifi掃描到SSID，輸入密碼即可以訪問互聯網了。
再比如，我們家裏已經有了一個可以上網的路由器（SSIDx和pwdx）。我們購買了一個無線攝像頭裝在家裏。它自然也要連到家裏的路由，才能訪問這個攝像頭的廠商，這樣我們纔可以用手機的APP接收到廠商服務器傳過來的數據進行顯示。攝像頭也沒有顯示屏和按鍵（reset鍵不算啦）。傳統的配置方法是：
1）攝像頭恢復出廠設置後默認進入AP（熱點）+Station（工作站）狀態。AP熱點的SSID和密碼由攝像頭的說明書說明，是廠商默認的。手機通過wifi連接到該AP，然後通過瀏覽器訪問http://192.168.1.1(也是廠商默認的)，在該界面設置家裏的路由器的SSID和密碼，便於其作爲Station連入家裏的路由器。
2）當攝像頭連接路由器成功後，其即單獨以Station的模式運行（不用再做AP可以省功耗），其會立即訪問廠商的服務器（其內部程序代碼會hardcode廠商服務的域名或者IP），告知其已經上線，並且要在一段週期內發送Beacon心跳包維持長連接。
3）手機斷開攝像頭的AP熱點，連接家裏的路由器。打開攝像頭的APP，即可以通過廠商服務器查看家裏的攝像頭的效果。
所以傳統的配置上網方法是wifi設備必須以AP的模式運行，配置好以後再轉回Station模式運行。是不是比較費事？
三 、 Airkiss配網基本流程
1. wifi智能設備以station混雜模式運行
2. 手機微信客戶端通過Airkiss發送家裏的路由器ssid和密碼
3. wifi設備通過抓包獲取到ssid和密碼，然後連接到家裏的路由器
四、智能配置的基本原理
1.混雜模式
wifi設備剛開始同樣是以Station的模式運行，但是還有一個混雜模式。是什麼意思？它是指正常的wifi設備都有一個MAC地址，其硬件電路會自動過濾目標MAC地址跟其MAC不同的數據包。開啓混雜模式就是我們平常時說的抓包，就是空中符合802.11格式的數據包都接收進來，不管MAC是否一樣。
很明顯，手機智能配置APP並不知道該wifi設備的MAC地址，所以手機wifi發送出的數據包，通過家裏的路由器轉發出去時，wifi設備必須要在混雜模式下才能接收到這些數據包。
2. 信道切換
802.11有多個信道，某一個時候wifi設備和路由器都處於某一個信道。路由器一般都是默認在第六信道，所以要想家裏的網信號好一點，可以嘗試將路由器的信道改到一個其他道，這樣就不會和鄰居家的wifi信道重疊了。wifi信號混在同一個頻道就會互相干擾
同理，我們也不能假定wifi設備是處於哪個信道，但是我們可以在app中確定手機wifi的發送信道，這樣要求wifi設備在一定的時刻切換信道，以便與接收到數據包。當wifi設備檢測到有效的數據包，藥鎖定在該信道進行後續的通信
3. 利用數據幀的長度來承載有效信息
我們先來看一看802.2 SNAP（802.11的物理層協議）的數據幀格式
DA字段表示目標mac地址，SA字段表示源mac地址，Length字段表示後面數據的長度，LLC字段表示LLC頭，SNAP字段包括3bytes的廠商代碼和2bytes的協議類型標識，DATA字段爲負載，對於加密信道來說是密文的，FCS字段表示幀檢驗序列。
從無線信號監聽方的角度來說，不管無線信道有沒有加密DA、SA、Length、LLC、SNAP、FCS字段總是暴露的，因此信號監聽方便有了從這6個字段獲取信息的可能。但從發送方的角度來說，由於操作系統的限制(比如ISO或者Android)，DA、SA、LLC、SNAP、FCS五個字段的控制需要很高的控制權限，發送方一般是很難拿到的。因此只剩下Length這一字段，發送方可以通過改變其所需要發送數據包的長度進行很方便的控制。所以，只要制定出一套利用長度編碼的通信協議，就可利用802.2 SNAP 數據包中的Length字段進行信息傳遞
在實際應用中，我們採用UDP廣播包作爲信息的載體。信息發送方向空間中發送一系列的UDP廣播包，其中每一包的長度(即Length字段)都按照AirKiss通信協議進行編碼，信息接收方利用混雜模式監聽空間中的無線信號，並從數據鏈路層截取802.2 SNAP格式數據包，便可得到已編碼的Length字段，隨後接收方便可根據Air Kiss通信協議解析出需要的信息。
五、Airkiss通信協議
5.1 物理層協議
在信號載體方面，採用 wifi 無線信號進行信息傳遞，1-14 全信道支持。 在信號編碼方面，802.2 SNAP 數據包中的 Length 字段爲數據發送方唯一可 AP 轉發 UDP 廣 播包 發 送 長 度 經 過 編碼的 UDP 廣 播包 監聽無線廣播包，從數據鏈 路層截取數據包，得到已編 碼的 Length 字段 ，再 根據 Air Kiss 通信協議解析出需要 的信息 控字段，因此 Air Kiss 通信協議利用發送數據包的長度進行編碼。由於受到 MTU 的限制，Length 字段最大可編碼位數爲 10bit。但實際測試過程中發現， UDP 包長度與丟包率、亂序率成正比。因此本協議中，我們把 Length 字段編碼位 數限制在 9bit，即 UDP 廣播包的發送長度不大於 512 字節
我們身處的無線網絡環境有可能及其複雜，很有可能在同一個空間中存在 多個 AP，而這些 AP 又分佈在相同或者不同的信道上，這樣接收者一開始是 不知道發送方在 1-14 哪個信道上發送信息，而且同一個信道上也可能會有很 多設備在發送 UDP 廣播包。在這種情況下，接收方監聽到的數據包是海量的。 必須從海量的數據信息中定位出發送方所在的信道和發送方的 mac 地址。另外， 由於在 UDP 廣播包發送過程中，一個 UDP 層的數據包，要經過 IP 層、數據鏈 路層的封裝，並且通過加密(加密方式包括 WPA2、WPA、WEP 三種)後纔會被髮 送出去，所以發送方發送 UDP 廣播包的長度與接收方監聽 SNAP 包中的 Length 字段值存在差異，這就需要進行轉義。然而，由於底層加密方式的不確 定性，使得這個差異值也具有不確定性。 爲解決這兩個問題，在發送鏈路層數據（見下節）之前，需要先發送 400ms 的前導域（400ms = 8*50ms，即如果設備端以 50ms 的頻率切換信道， 則可以覆蓋 8 個信道，因爲一般用戶環境不用監聽 14 個信道，所以覆蓋 8 個 信道足已)。前導域由 4 個字節組成，其值固定爲｛1,2,3,4｝。接收方在接收到這 些前導域數據包後，利用 SNAP 包中的 Length 字段與之相減，從而獲取到這 個差異值。 舉個例子，接受方通過監聽，在鏈路層截獲 802.2 SNAP 格式的前導數據 包，其 Length 字段的值分別爲 53，54，55，56，那差異值就能確定爲 53- 1=52。之後接收方接收到數據之後都用 SNAP 包的 Length 字段值減去 52，即能 得到實際的信息數據。
5.2 鏈路層協議
5.2.1鏈路層數據結構如下圖所示：
鏈路層數據結構可分爲兩類，control 字段與 data 字段，magic code、prefix code、sequence header field 屬於 control 字段，data field 屬於 data 字段。control 字 段與 data 字段以第 8bit 位（最高位）加以區別，該位爲 1 表示 data field 字段， 爲 0 表示 control 字段。在 control 字段中，magic code 字段與 prefix code 字段完 全相同，magic code 字段與 sequence header 字段通過第 7bit 位加以區分，該位 爲 1 表示 sequence header 字段，爲 0 表示 magic code 字段。
以下分別對各個字段進行詳細介紹。
5.2.2 magic code 字段的數據結構如下圖所示：
1
Magic爲4個數據幀，前兩個幀的兩個9bit記錄將要發送的數據（PWD+Ramdon+SSID）的長度。每個bit的高 5 位爲 magic code 字段，低 4 位爲 information 字段。前兩個 9bits 的 information 字段分別裝載要發送數據長度 的高 4 位和低 4 位，
後兩個幀的兩個9bit記錄SSID的CRC校驗值。兩個 9bits 的 information 字段分別裝載要發送 ssid 的 crc8 值的高 4 位和低 4 位。路由器的SSID是會被路由器廣播出來的，例如我們手機wifi掃描到路由器的名稱就是SSID。因此wifi設備也能得到路由器的SSID，其只要計算目前所能獲取到的SSID的CRC值跟MAGIC的SSID CRC值一樣，那之後的SSID數據就不用接收了，這樣能夠提高配置上網速度。Magic很重要，因此發送5遍。
5.2.3 prefix code 字段的數據結構如下圖所示：
PrefixCode爲4個數據幀，前兩個幀的兩個9bit記錄PWD的數據長度，
前兩個幀的 information 字段分別裝載PWD的長度的高4位和低4位。
後兩個幀的兩個9bit記錄PWD長度的CRC校驗值。這兩個幀的 information 字段分別裝載發送密碼長度 的 crc8 值的高 4 位和低 4 位。
PrefixCode有兩個作用，首先是表示數據序列的正式開始，其次告訴接收 端發送密碼的長度，以便接收方在接收完數據後，對數據進行分割解密。
Magic中發送的長度是所有數據的長度，包括密碼PWD、隨機數（wifi配置成功後要回復該隨機數作爲回覆）和SSID。而這裏是PWD的長度，用於對接收到的數據進行分段。
5.2.3 Sequence序列包括一個sequence header序列索引和一個data field序列
我們把待發送的數據以 4字節進行劃分，每 4 個數據組成一個 sequence， 以 sequence 爲單位進行數據的發送。每個sequence 都由sequence header字段和data 字段組成。最後一個sequence 如果不夠 4 個數據，不用補全。如我家路由的PWD是8313huang，那其會分爲3個序列，分別是“8313”、“huan”“g”進行發送。Sequence header包括索引值和CRC值，而Data field就是4個數據幀，包含要發送的數據，如“8313”等。
5.2.3.1 sequence header 字段的數據結構如下圖所示：
sequence header 字段由兩個 9bits 組成，第一個的低 7位裝載的是從本 sequence index 開始到本 sequence 結束髮送的所有數據的 crc8 的低 7 位值（計算 過程中不計入字段標識位，因此 sequence index 最高位需補 0），在接收完一個 sequence 的數據之後，需進行 crc8 值的效驗，如果不相同，證明該 sequence 的 數據接收出錯，應該丟棄。
5.2.3.2 data 字段的數據結構如下圖所示：
data 字段由 4 個 9bits 組成，每個 9bits 的第 8 位爲控制位，固定爲 1，其餘 的 8 位裝載需要傳輸的數據。
六、應用層協議
發送方所要發送的數據由三部分組成：密碼、隨機數、ssid。其中隨機數的作用 是，當數據接收方連上 AP 之後，立即發送以該隨機數爲內容的 UDP 廣播包， 當發送方收到該廣播包後就能確認接收方已經準確接收到所有數據。密碼和 ssid 都’\0’結尾，並且分別用 AES 進行加密，再發送。這三部分數據的發送順序爲先 發送密碼，再發送隨機數，最後發送 ssid，如下圖所示：
來源：CSDN
原文：https://blog.csdn.net/lb5761311/article/details/77945848
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！
