三、例項分析
僅列舉幾個特例，其他的報文大同小異。乙個正常的報文一般是有請求，則會有回應。
1、 正常無線的共享金鑰認證的互動過程：如下圖：共享金鑰認證是除開放系統認證以外的另外一種鏈路認證機制。共享金鑰認證需要站點和裝置端配置相同的共享金鑰。
共享金鑰認證的認證過程為：
站點先向裝置傳送認證請求，無線裝置端會隨機產生乙個challenge包（即乙個字串）傳送給站點；
站點會將接收到challenge 加密後再傳送給無線裝置端；
無線裝置端接收到該訊息後，對該訊息進行解密，然後對解密後的字串與原始字串進行比較。
如果相同，則說明站點通過了shared key 鏈路認證；否則shared key 鏈路認證失敗。
a、 描掃（主動或被動）。
b、 站點向ap發起幀探測請求。
c、 ap發出探測響應。
d、站點向ap發起認證請求。auth?
e、 ap無線裝置端會隨機產生乙個challenge包（即乙個字串）傳送給站點。
f、 站點會將接收到challenge 加密後再傳送給無線裝置端。
g、無線裝置端接收到該訊息後，對該訊息進行解密，然後對解密後的字串和原始字串進行比較。如果相同，則說明站點通過了shared key 鏈路認證；否則shared key 鏈路認證失敗。
h、 站點向ap發起關聯請求。assoc?
i、 ap向站點的響應關聯請求。
在報文中可以看到如下資訊：在probe response中可以看到wep?為加密模式。
在authentication報文中可以看到如下資訊：認證方式為shared key
詳細的分析請見另一篇文件。
2、如下圖，站點出現問題無法關聯assoc時，報文中可能會給出部分提示，如malformed packet。
站點向ap發起認證請求，ap再向站點發起認證響應並加密，站點再發起異常報文，最後中斷連線。就這樣不停的認證直到站點終止連線才會終斷向ap發出的請求。
這種情形站點與ap之間則無法連線。
3、ap軟體存在的問題：下圖是ap出現異常無法與網絡卡進行連線。如下圖所示，站點發起乙個探測請求的廣播包，ap發起響應，站點再次向已知的ap發起探測請求，ap未發起響應。則說明ap存在問題。如果ap一直未發出響應請求，因此，站點與ap無法連線成功。
probe request(broadcast)與probe response報文。
probe request報文，但ap沒有probe response響應報文。
4、站點不加密，ap為wpa時的出錯資訊
（1）、發起探測幀（包含請求探測幀和響應探測幀）;
（2）、發起認證幀（包含認證請求和響應請求幀）;
（3）、發起關聯幀
（包含關聯請求和關聯響應）;
（4）、deauthentication幀。
在互動過程中，association中privacy值為1（1表示加密，0表示不加密），後面訊息中出現deauthentication則表示無法連線加密方式或密碼不一至。
出現deauthentication的報文，如下圖：
5、站點與ap同時設定為wpa加密模式。
（1）、發起探測幀（包含請求探測幀和響應探測幀）;
（2）、發起認證幀（包含認證請求和響應請求幀）;
（3）、發起關聯幀（包含關聯請求和關聯響應）;
（4）、eapol幀（裡面含有eapol的加密解密的互動過程）：
如果發現報文中只有前半部分或異常，則站點與ap無法連線。
本文件主要介紹無線的簡單互動過程。出現異常時還需具體分析。
RTSP互動過程
1.2.rtsp的報文結構 rtsp有兩類報文 請求報文和響應報文。請求報文是指從客戶向伺服器傳送請求報文，響應報文是指從伺服器到客戶的回答。由於 rtsp 是面向正文的 text oriented 因此在報文中的每乙個欄位都是一些 ascii 碼串，因而每個欄位的長度都是不確定的。rtsp報文由三...
RPC Python RPC互動過程
本系列均來自大神 老錢 的小冊學習 rpc remote procedure call 即遠端過程呼叫，是分布式系統常見的一種通訊方法，已經有 40 多年歷史。當兩個物理分離的子系統需要建立邏輯上的關聯時，rpc 是牽線搭橋的常見技術手段之一。除 rpc 之外，常見的多系統資料互動方案還有分布式訊息...
SSL Tls協議互動過程
client hello server hello 協商演算法及證書返回用於客戶端驗證 client key change 利用客戶端和伺服器端的 28位元組隨機數生成主金鑰 利用主金鑰生成 mac加密金鑰，生成資料加密金鑰都是對稱金鑰 change cipher spce 客戶端後面的資料採用對稱...