1. 命令介紹 由圖4-1的介紹可知，WPAS對外通過控制接口模塊與客戶端通信。在Android平臺中，WPAS的客戶端是位于Framework中的WifiService。用戶在Settings界面進行Wi-Fi相關的操作最終都會經由WifiService通過發送命令的方式轉交給wpa_supplicant去執行。 WPAS定義了許多命令，常見的： * **PING**：心跳檢測命令。客戶端用它判斷WPAS是否工作正常。WPAS收到”PING”命令后需要回復“PONG”。 * **MIB**：客戶端用該命令獲取設備的MIB信息。 * **STATUS**：客戶端用該命令來獲取WPAS的工作狀態。 * **ADD_NETWORK**：為WPAS添加一個新的無線網絡。它將返回此新無線網絡的id（從0開始）。注意：此network id非常重要，客戶端后續將通過它來指明自己想操作的無線網絡。 * **SET_NETWORK** `<network id> <variable> <value>`：network id是無線網絡的id。此命令用于設置指定無線網絡的信息。其中variable為參數名，value為參數的值。 * **ENABLE_NETWORK** `<network id>`：使能某個無線網絡。此命令最終將促使WPAS發起一系列操作以加入該無線網絡。 除了接收來自Client的命令外，WPAS也會主動給Client發送命令。例如，WPAS需用戶為某個無線網絡輸入密碼。這類命令稱之為Interactive Request，其格式如下。 WPAS向客戶端發送的命令遵循以下格式： `CTRL-REQ-<field name>-<network id>-<human readable text>`格式。 如CTRL-REQ-PASSWORD-0-Passwork needed for SSID test-network。這條命令表示需要用戶為0號網絡輸入密碼。 客戶端處理完后，需回復`CTRL-RSP-<field name>-<network id>-<value>`。 目前支持的field包括PASSWORD、IDENTITY（EAP中的identity或者用戶名）、PIN等。 最后，WPAS還可通過形如“`CTRL-EVENT-<field>-<text>`”的命令向客戶端通知一些事情。 **提示**：除了“CTRL-EVENT-XXX”之外，WPAS還支持形如“WPA:XXX”和“WPS-XXX”的通知事件。這些事件和WPA和WPS有關。下一章分析WifiService時我們還能見到它們。 圖4-2所示為筆者利用wpa_cli測試status命令得到的結果。 :-:  圖4-2 wpa_cli命令測試示意 圖4-2所示為status命令的結果。圖中最后幾行顯示WPAS向wpa_cli返回了兩個CTRL-EVENT信息。 2. 控制API介紹 Android平臺中WifiService是WPAS的客戶端，它和WPAS交互時必須使用wpa_supplicant提供的API。這些API聲明于wpa_ctrl.h中，其用法如下： ~~~ //必須包含此頭文件，鏈接時需包含libwpa_client.so動態庫 #include “wpa_ctrl.h” ~~~ 客戶端使用wpa_ctrl時首先要分配控制對象。下面兩個API用于創建和銷毀控制對象wpa_ctrl： ~~~ //創建一個wpa控制端對象wpa_ctrl。Android平臺中，參數ctrl_path代表unix域socket的位置 struct wpa_ctrl * wpa_ctrl_open(const char *ctrl_path); void wpa_ctrl_close(struct wpa_ctrl *ctrl);//注銷wpa_ctrl控制對象 ~~~ 下面這個函數用于發送命令給WPAS。 ~~~ //客戶端發送命令給wpa_supplicant，回復的消息保存在reply中 int wpa_ctrl_request(struct wpa_ctrl *ctrl, const char *cmd, size_t cmd_len, char *reply, size_t *reply_len,void (*msg_cb)(char *msg, size_t len)); ~~~ msg_cb是一個回調函數，該參數的設置和WPAS中C/S通信機制的設計有關： 從Client角度來看，它發送給WPAS的命令所對應的回復屬于solicited event（意為有請求的事件），而前面所提到的CTRL-EVENT事件（用于通知事件）對應為unsolicited event（意為未請求的事件）。當Client在等待某個命令的回復時，WPAS同時可能有些通知事件要發送給客戶端，這些通知事件不是該命令的回復，所以不能通過wpa_ctrl_request的reply參數返回。 為了防止丟失這些通知事件，wpa_cli設計了一個msg_cb回調用于客戶端在等待命令回復的時候處理那些unsolicited event。 這種一個函數完成兩樣完全不同的功能的設計實在有些特別，所以wpa_supplicant規定只有打開通知事件監聽功能的wpa_ctrl對象才能在wpa_ctrl_request中通過msg_cb獲取通知事件。而打開通知事件監聽功能相關的API如下所示。 ~~~ //打開通知事件監聽功能 int wpa_ctrl_attach(struct wpa_ctrl *ctrl); //打開通知事件監聽功能的wpa_ctrl對象能直接調用下面的函數來接收unsolicited event int wpa_ctrl_recv(struct wpa_ctrl *ctrl, char *reply, size_t *reply_len); ~~~ 如果客戶端并不發送命令，而只是想接收Unsolicited event的話，可通過wpa_ctrl_recv函數來達到此目的。 綜上所述，單獨使用wpa_ctrl_recv和wpa_ctrl_request都不方便。所以，一種常見的用法是：客戶端創建兩個wpa_ctrl對象來簡化自己的邏輯處理： * 一個打開了通知事件監聽功能的wpa_ctrl對象將只通過wpa_ctrl_recv來接收通知事件。 * 另外一個wpa_ctrl專職用于發送命令和接收回復。由于沒有調用wpa_ctrl_attach，故它不會收到通知事件。 **提示**：下一章分析WifiService時將見到這種創建兩個wpa_ctrl對象的做法。