EAP-WSC流程涉及到EAPOL中的四個狀態機(SUPP_PAE、KEY_RX、SUPP_BE、Port Timers)以及EAP SM之間的聯動。當STA成功關聯到AP后,EAPOL及EAP狀態機情況如下(詳情請參考第4章4.5.3.4.3“eapol_sm_notify_portEnabled分析”一節):
* SUPP_PAE為DISCONNECTED狀態
* KEY_RX為NO_KEY_RECEIVE狀態
* SUPP_BE為IDLE狀態
* EAP_SM為DISABLED狀態。
根據6.2.3“Registration Protocol介紹”一節中的圖6-7,EAP-WSC流程的開始于STA向AP發送的EAPOL-Start幀。是什么原因導致STA發送EAPOL-Start幀呢?來看下文。
**1、發送EAPOL-Start**
在STA關聯到AP流程的最后,eapol_sm_notify_portEnabled將設置portEnabled為1,根據代碼(eapol_supp_sm.c中SM_STEP(SUPP_PAE))以及第4章圖4-28(Supplicant PAE SM狀態示意圖)可知,SUPP_PAE下一個要進入的狀態是CONNECTING,其EA(Entry Aciton)代碼為:
**eapol_supp_sm.c::SM_STATE(SUPP_PAE, CONNECTING)**
~~~
SM_STATE(SUPP_PAE, CONNECTING)
{
//SUPP_PAE_state此時的值為SUPP_PAE_DISCONNECTED,故send_start為0
//下面注意這個判斷很重要,我們待會還會回到此處
int send_start = sm->SUPP_PAE_state == SUPP_PAE_CONNECTING;
SM_ENTRY(SUPP_PAE, CONNECTING);
if (send_start) {
sm->startWhen = sm->startPeriod;
sm->startCount++;
} else {
#ifdef CONFIG_WPS //
sm->startWhen = 1; //注意,如果WPAS支持WPS,則startWhen值為1
#else /* CONFIG_WPS */
sm->startWhen = 3;
#endif /* CONFIG_WPS */
}
//啟動Port Timers SM,Port Timers SM將遞減startWhen,并調用eapol_sm_step以重新遍歷狀態機
eapol_enable_timer_tick(sm);
sm->eapolEap = FALSE; ..
//由于send_start為0,所以此時還不會發送EAPOL-Start包
if (send_start)
eapol_sm_txStart(sm);
}
~~~
根據代碼中的注釋,當Port Timers SM運行時,它將遞減startWhen變量(結果是startWhen的值變為0),然后通過eapol_sm_step重新遍歷狀態機。在該函數中,PAE的SM_STEP將被調用以檢查是否需要進行狀態切換,相關代碼如下所示:
**eapol_supp_sm.c::SM_STEP(SUPP_PAE)**
~~~
SM_STEP(SUPP_PAE)
{
......//略去不相關的內容
else switch (sm->SUPP_PAE_state) { //SUPP_PAE_state還處于CONNECTING狀態
......
case SUPP_PAE_CONNECTING:
if (sm->startWhen == 0 && sm->startCount < sm->maxStart)
SM_ENTER(SUPP_PAE, CONNECTING);//由于startWhen為0,PAE將重新進入CONNECTING狀態
......
break;
case SUPP_PAE_AUTHENTICATING:
......
}
}
~~~
根據上面代碼可知,PAE將再次從CONNECTING狀態進入CONNECTING狀態。請讀者回顧SM_STATE(SUPP_PAE, CONNECTING)函數。這一次sendStart將取值1,所以eapol_sm_txStart會被調用。該函數的代碼如下所示:
**eapol_supp_sm.c::eapol_sm_txStart**
~~~
static void eapol_sm_txStart(struct eapol_sm *sm)
{
//eapol_send函數指針指向wpa_supplicant_eapol_send,相關代碼在wpas_glue.c中。請讀者自行閱讀
sm->ctx->eapol_send(sm->ctx->eapol_send_ctx,IEEE802_1X_TYPE_EAPOL_START, (u8 *) "", 0);
sm->dot1xSuppEapolStartFramesTx++;
sm->dot1xSuppEapolFramesTx++;
}
~~~
由上述代碼可知,eapol_send的實例wpa_supplicant_eapol_send將最終發送EAPOL-Start幀。
**2、狀態機切換處理介紹**
STA發出EAPOL-Start后,AP將發送EAP-Request/Identity包。STA處理EAP-Request/Identity后將回復EAP-Response/Identity包。上述流程將觸發EAPOL中的PAE、BE和EAP狀態機聯動。此聯動過程相當復雜。故本節將以EAP-Request/Identity為入口,分析WPAS中狀態機的切換處理。
>[info] 注意:此處的狀態機聯動實際上反映的是WPAS中EAP包處理的通用流程。學習過程中,請讀者務必結合第4章4.4“EAP和EAPOL模塊介紹”一節介紹的理論知識。
先來看EAP-Request的處理。WPAS中,EAP包接收的函數是wpa_supplicant_rx_eapol(相關分析請參考第4章4.5.3.5“EAPOL-Key交換流程分析”一節對wpa_supplicant_rx_eapol的介紹)。在那里,我們說過非PSK認證方法將由eapol_sm_rx_eapol處理。故直接來看eapol_sm_rx_eapol函數,代碼如下所示:
**eapol_supp_sm.c::eapol_sm_rx_eapol**
~~~
int eapol_sm_rx_eapol(struct eapol_sm *sm, const u8 *src, const u8 *buf, size_t len)
{
const struct ieee802_1x_hdr *hdr; const struct ieee802_1x_eapol_key *key;
int data_len; int res = 1; size_t plen;
sm->dot1xSuppEapolFramesRx++;
hdr = (const struct ieee802_1x_hdr *) buf;
sm->dot1xSuppLastEapolFrameVersion = hdr->version;
os_memcpy(sm->dot1xSuppLastEapolFrameSource, src, ETH_ALEN);
plen = be_to_host16(hdr->length);
......
#ifdef CONFIG_WPS
//workaround中文意思為“變通方案”。在WPAS中,它表示為了兼容某些AP的錯誤行為(例如發送的EAP包
//格式不符合要求),而采用繞過去的方法來處理
if (sm->conf.workaround && plen < len - sizeof(*hdr) &&
hdr->type == IEEE802_1X_TYPE_EAP_PACKET &&
len - sizeof(*hdr) > sizeof(struct eap_hdr)) {
......
}
#endif
data_len = plen + sizeof(*hdr);
switch (hdr->type) {
case IEEE802_1X_TYPE_EAP_PACKET: //本例中,我們收到的是EAP-Request包,滿足此case條件
......
wpabuf_free(sm->eapReqData);
sm->eapReqData = wpabuf_alloc_copy(hdr + 1, plen);
if (sm->eapReqData) {
sm->eapolEap = TRUE; //設置條件變量
eapol_sm_step(sm); //觸發狀態機運行
}
break;
......
}
return res;
}
~~~
WPAS每收到一個EAP包都會觸發上述代碼中流程。回顧一下eapol_sm_step中和狀態機運轉相關的代碼:
**eapol_supp_sm.c::eapol_sm_step**
~~~
void eapol_sm_step(struct eapol_sm *sm)
{
int i;
for (i = 0; i < 100; i++) {
sm->changed = FALSE;
SM_STEP_RUN(SUPP_PAE);//先執行SUPP_PAE狀態機
SM_STEP_RUN(KEY_RX); //再運轉KEY_RX狀態機
SM_STEP_RUN(SUPP_BE); //最后運轉SUPP_BE狀態機
if (eap_peer_sm_step(sm->eap)) //執行EAP_SM狀態機
sm->changed = TRUE;
if (!sm->changed)
break;
}
......
}
~~~
其中,eap_peer_sm_step的代碼如下所示:
**eap.c::eap_peer_sm_step**
~~~
int eap_peer_sm_step(struct eap_sm *sm)
{
int res = 0;
do { //無限循環,直到EAP SM穩定后才退出
sm->changed = FALSE;
SM_STEP_RUN(EAP);
if (sm->changed)
res = 1;
} while (sm->changed);
return res;
}
~~~
通過上述代碼可知,EAPOL和EAP的狀態機聯動過程如下:
1. EAPOL先按順序遍歷PAE、KEY_RX、BE狀態機。
2. 然后執行EAP狀態機。只有EAP SM穩定后(即eap_peer_sm_step函數中的sm->changed為FALSE時)才退出eap_peer_sm_step。
3. 如果上述四個狀態機有任何一個狀態機的狀態不穩定(即sm->changed為TRUE),則繼續遍歷所有狀態機。
特別需要指出的是,狀態機A運行時可能會修改一些條件變量從而導致狀態機B發生狀態切換。雖然第4章對每個狀態機的狀態切換圖都有詳細介紹,但讀者很難理清楚狀態機之間是如何互相影響的。在此,筆者整理了WPAS從發送EAPOL-Start包到接收EAP-Request/Identity以及回復EAP-Reponse/Identity這一過程中四個狀態機的切換過程,如圖6-34所示:
:-: 
圖6-34 EAP-Request/Response Identity流程中的狀態機聯動示意
圖6-34中:最上面一行顯示了PAE、KEY_RX、BE和EAP_SM的初始狀態。由于EAP-WSC不會收發EAPOL-Key幀,所以KEY_RX將不參與聯動過程。
圖中的方框上部所示為狀態機以及當前的狀態,格式為狀態機名_狀態名,如PAE_CONNECTING等。方框下部所示為該狀態機對應狀態的EA處理(由于篇幅原因,圖中EA僅列出了一些重要的處理邏輯)。
當狀態機A從一個狀態切換到另一個狀態時,切換過程用實箭頭表示(例如第二行中,PAE_CONNECTING切換到PAE_RESTART,切換條件為“eapolEap為TRUE”。當WPAS收到一個EAP幀時,該變量將在上文介紹的eapol_sm_rx_eapol函數中被設置為TRUE)。
當狀態機A在其EA處理中修改了某些條件變量(或者外界設置了某個條件變量)導致狀態機B發生狀態切換時,其切換過程用虛箭頭表示。例如第二行中的PAE_RESTART狀態,其EA將設置eapRestart為TRUE,而該條件和portEnabled將共同促使EAP_SM進入INITILIAZE狀態。
第二行表示eapol_sm_step第一次循環過程中的狀態機切換以處理接收到的EAP-Request/Identity包。但這一輪還不會真正處理EAP包。
第三行表示eapol_sm_step的第二次循環。在這次循環過程中,EAP狀態機將處理EAP-Request/Identity包。在解析該包時,發現它包含了Identity信息,所以EAP SM將進入IDENTITY狀態去處理它。處理完畢后,EAP SM將構造一個EAP-Response/Identity包,并設置eapResp變量為TRUE。
第三行中,eapResp變量將使得BE進入RESPONSE狀態,該狀態的EA將調用txsuppResp發送這個EAP-Response/Identity包。
當圖6-34執行完畢后,EAPOL和EAP狀態機將進入穩定狀態,這樣,eapol_sm_step得以返回。根據EAP-WSC的流程,WPAS下一步將繼續接收并處理EAP包。在這以后的過程中(從M1到M8):
PAE保持Authenticating狀態不變。
當EAPOL收到一個EAP包后,BE將從RECEIVE狀態切換至REQUEST狀態。EAP將根據EAP包的信息從IDLE狀態轉移到其他狀態(首先是RECEIVED狀態,在該狀態中將解析EAP包的內容,根據內容以進入GET_METHOD或METHOD狀態以處理EAP包)。
EAP狀態機處理完EAP包,BE將進入RESPONSE狀態并發送EAP回復包。整個流程將反復執行,直到EAP-WSC流程終結。
所以,對EAP-WSC流程來說,EAPOL狀態機的執行過程比較固定。而對EAP SM來說,它將根據EAP包內容的不同而轉移到不同的狀態。下面我們將直接進入EAP對應的狀態以分析不同EAP包的處理過程。
注意,根據圖4-21關于EAP SM的描述,當portEnabled值為TRUE時,應該從DISABLED狀態切換至INITIALIZE狀態。不過,我們在4.5.3.3.3“wpa_supplicant_associate分析之三”一節中曾提到說由于force_disabled變量為TRUE,EAP_SM是無法轉入INITIALIZED狀態的。為什么此處它卻可以呢?原來。由于本例使用的key_mgmt是WPA_KEY_MGMT_WPS,所以force_disabled變量將被設置為FALSE,這樣EAP SM就可以轉換至INITIALIZE狀態了。其間的細節內容請讀者參考wpa_supplicant_initiate_eapol及內部所調用的eapol_sm_notify_config函數。
**3、EAP-Request/Identity處理**
EAP狀態機的RECEIVED狀態將對收到的EAP包進行解析,相關代碼如下所示。
**eap.c::SM_STATE(EAP,RECEIVED)**
~~~
SM_STATE(EAP, RECEIVED)
{
const struct wpabuf *eapReqData;
SM_ENTRY(EAP, RECEIVED);
eapReqData = eapol_get_eapReqData(sm);
eap_sm_parseEapReq(sm, eapReqData);// 解析收到的EAP包
sm->num_rounds++;
}
~~~
eap_sm_parseEapReq的代碼如下所示。
**eap.c::eap_sm_parseEapReq**
~~~
static void eap_sm_parseEapReq(struct eap_sm *sm, const struct wpabuf *req)
{
const struct eap_hdr *hdr; size_t plen; const u8 *pos;
......
hdr = wpabuf_head(req);
plen = be_to_host16(hdr->length);
......
sm->reqId = hdr->identifier;
if (sm->workaround) {...... }
switch (hdr->code) {
case EAP_CODE_REQUEST:
......
sm->rxReq = TRUE;
pos = (const u8 *) (hdr + 1);
sm->reqMethod = *pos++; // 對于EAP-Request Identity包而言,reqMethod=1
// 處理EAP-Request/WSC_Start,WSC_Start屬于擴展EAP協議
// 此處收到的是Identity包,所以下面這個if條件并不滿足
if (sm->reqMethod == EAP_TYPE_EXPANDED) {
......//
// 對于EAP-Request/WSC_Start而言,reqVendor取值為0x0372a
sm->reqVendor = WPA_GET_BE24(pos);
pos += 3;
// 獲取Vendor Type,值為0x1,表示SimpleConfig。請參考圖6-22
sm->reqVendorMethod = WPA_GET_BE32(pos);
}
break;
case EAP_CODE_RESPONSE:
......
break;
case EAP_CODE_SUCCESS:
sm->rxSuccess = TRUE;
break;
case EAP_CODE_FAILURE:
sm->rxFailure = TRUE; // 在EAP-WSC流程的最后,AP將發送EAP-Failure包
break;
......
}
}
~~~
根據圖6-34所示,EAP SM接著將進入IDENTITY狀態(讀者可參考eap.c中的eap_peer_sm_step_local函數),代碼如下所示。
**eap.c::SM_STATE(EAP,IDENTITY)**
~~~
SM_STATE(EAP, IDENTITY)
{
const struct wpabuf *eapReqData;
SM_ENTRY(EAP, IDENTITY);
eapReqData = eapol_get_eapReqData(sm);// 獲取EAP-Request包內容
eap_sm_processIdentity(sm, eapReqData);// 處理Identity,請讀者自行閱讀此函數
wpabuf_free(sm->eapRespData);
sm->eapRespData = NULL;
// 構造EAP-Response Identity包
sm->eapRespData = eap_sm_buildIdentity(sm, sm->reqId, 0);
}
~~~
來看看eap_sm_buildIdentity函數,代碼如下所示。
**eap.c::eap_sm_buildIdentity**
~~~
struct wpabuf * eap_sm_buildIdentity(struct eap_sm *sm, int id, int encrypted)
{
/*
獲取wpa_ssid中的eap_peer_config對象,它代表EAP配置信息。該eap_peer_config的來歷請
讀者自行閱讀wpa_supplicant_initiate_eapol及內部所調用的eapol_sm_notify_config函數。
總之,下面這個config對象將指向“WPS_PIN any”命令處理時創建的wpa_ssid中eap變量,它指向
一個eap_peer_config實例。
eap_get_config內部將通過函數指針調用eap_supp_sm.c中的eapol_sm_get_config函數。
*/
struct eap_peer_config *config = eap_get_config(sm);
struct wpabuf *resp; const u8 *identity; size_t identity_len;
if (config == NULL) { ......}
if (sm->m && sm->m->get_identity && .......) .......
else if (!encrypted && config->anonymous_identity)......
else {
// 對WSC來說,identity的值為“WFA-SimpleConfig-Enrollee-1-0”
identity = config->identity;
identity_len = config->identity_len;
}
if (identity == NULL) {
......// 沒有配置identity
} else if (config->pcsc) { ......}
// 構造EAP-Response/Identity回復包
resp = eap_msg_alloc(EAP_VENDOR_IETF, EAP_TYPE_IDENTITY, identity_len,EAP_CODE_RESPONSE, id);
......
wpabuf_put_data(resp, identity, identity_len);
return resp;
}
~~~
EAP-Request/Identity的處理流程比較簡單,此處就不再詳述。當AP收到來自STA的EAPResponse/Identity后,它將發送EAP-Request/WSC_Start幀。該幀將導致EAP SM進入GET_METHOD狀態,馬上來看相關代碼。
**4、EAP-Request/WSC_Start處理**
圖6-35所示為EAP-Request/WSC_Start幀的內容。
:-: 
圖6-35 EAP-Request/WSC_Start示例
首先處理該幀的是EAP_SM GET_METHOD狀態,相關代碼如下所示。
**eap.c::SM_STATE(EAP,GET_METHOD)**
~~~
SM_STATE(EAP, GET_METHOD)
{
int reinit;
EapType method;
SM_ENTRY(EAP, GET_METHOD);
if (sm->reqMethod == EAP_TYPE_EXPANDED) method = sm->reqVendorMethod;
else method = sm->reqMethod;
/*
判斷WPAS是否支持此vendor對應的方法。reqVendor的值為0x372a。在4.3.2節
“eap_register_methods分析”中,WPAS支持的各種EAP方法將通過在eap_register_methods
函數中被注冊,其中就有EAP-WSC方法。
*/
if (!eap_sm_allowMethod(sm, sm->reqVendor, method))
goto nak;
......
sm->selectedMethod = sm->reqMethod; // selectedMethod值為EAP_TYPE_EXPANDED(值為254)
if (sm->m == NULL)// sm->m指向一個eap_method對象,它代表一種特定的EAP算法
sm->m = eap_peer_get_eap_method(sm->reqVendor, method);
// 獲取EAP-WSC算法模塊對應的對象
if (!sm->m)
goto nak;
sm->ClientTimeout = EAP_CLIENT_TIMEOUT_DEFAULT;
if (reinit) ......
else
sm->eap_method_priv = sm->m->init(sm); // 初始化EAP-WSC算法
if (sm->eap_method_priv == NULL) {
......
// 錯誤處理
}
sm->methodState = METHOD_INIT;
return;
......
}
~~~
EAP-WSC算法的注冊代碼位于eap_peer_wsc_register函數(位于eap_wsc.c,請讀者自行閱
讀)中,它為EAP-WSC模塊定制了三個函數。
* eap_wsc_init和eap_wsc_deinit:用于EAP-WSC算法模塊資源的初始化和釋放。
* eap_wsc_process:處理EAP-WSC包(即類型為WSC_MSG的包)。
>[info] 提示 EAP-WSC的初始化函數比較簡單,請讀者自行研讀eap_wsc_init函數。
GET_METHOD之后,EAP SM下一個進入的狀態是METHOD,其代碼如下所示。
**eap.c::SM_STATE(EAP,METHOD)**
~~~
SM_STATE(EAP, METHOD)
{
struct wpabuf *eapReqData; struct eap_method_ret ret;
SM_ENTRY(EAP, METHOD);
......
eapReqData = eapol_get_eapReqData(sm); // 先獲得請求信息
os_memset(&ret, 0, sizeof(ret));
ret.ignore = sm->ignore; ret.methodState = sm->methodState;
ret.decision = sm->decision; ret.allowNotifications = sm->allowNotifications;
wpabuf_free(sm->eapRespData);
sm->eapRespData = NULL;
// 對WSC來說,process函數為eap_wsc_process
sm->eapRespData = sm->m->process(sm, sm->eap_method_priv, &ret, eapReqData);
......// 其他處理
}
~~~
由上面的代碼可知,對于EAP-WSC算法來說,process真正的實現是eap_wsc_process,下面將詳細介紹。
**5、eap_wsc_process介紹**
eap_wsc_process的代碼如下所示。
**eap_wsc.c::eap_wsc_process**
~~~
static struct wpabuf * eap_wsc_process(struct eap_sm *sm, void *priv,
struct eap_method_ret *ret,const struct wpabuf *reqData)
{
struct eap_wsc_data *data = priv; const u8 *start, *pos, *end;
size_t len; u8 op_code, flags, id; u16 message_length = 0;
enum wps_process_res res; struct wpabuf tmpbuf;
struct wpabuf *r;
// 校驗EAP-WSC包的頭部信息
pos = eap_hdr_validate(EAP_VENDOR_WFA, EAP_VENDOR_TYPE_WSC, reqData, &len);
......
op_code = *pos++; // 獲取OpCode
flags = *pos++; // 獲取標志位
if (flags & WSC_FLAGS_LF) {
......
// LF標志位處理
}
if (data->state == WAIT_FRAG_ACK) {
......
// MF標志位處理
}
// 消息類型檢查。當前EAP-WSC模塊的狀態是WAIT_START
if (data->state == WAIT_START) {
......// 檢查類型
eap_wsc_state(data, MESG); // 設置EAP-WSC的狀態
goto send_msg; // 直接跳轉到send_msg
} else if (op_code == WSC_Start) {
ret->ignore = TRUE;
return NULL;
}
......
if (flags & WSC_FLAGS_MF) {
......
// 分片處理
}
......
// 關鍵函數①wps_process_msg
res = wps_process_msg(data->wps, op_code, data->in_buf);
switch (res) {
case WPS_DONE:
eap_wsc_state(data, FAIL);
break;
......// WPS_CONTINUE,WPS_FAILURE和WPS_PENDING的處理
}
......
send_msg:
if (data->out_buf == NULL) {
data->out_buf = wps_get_msg(data->wps, &data->out_op_code);// 關鍵函數②
......
}
eap_wsc_state(data, MESG); //
r = eap_wsc_build_msg(data, ret, id);// 構造用于回復的EAP-WSC消息包
......
return r;
}
~~~
eap_wsc_process中有兩個關鍵函數。
* wps_process_msg:對于Enrollee來說,其內部將調用wps_enrollee_process_msg以處理接收到的EAP-WSC_MSG消息,例如M2、M4、M6、M8等消息。
* wps_get_msg:對于Enrollee來說,其內部將調用wps_enrollee_get_msg以構造M1、M3、M5、M7、WSC_Done等消息。
我們在前面已經介紹過M1~M8的內容。在WAPS的代碼中,這部分內容也比較簡單,所以本節不展開詳細討論。下面將介紹WPAS如何處理M8消息中的Credentials屬性集。畢竟,EAP-WSC算法的目的就是為了得到這個Credentials屬性集。
**6、M8消息處理**
M8消息的處理函數是wps_process_m8,相關代碼如下所示。
**wps_enrollee.c::wps_process_m8**
~~~
static enum wps_process_res wps_process_m8(struct wps_data *wps, const struct wpabuf *msg,
struct wps_parse_attr *attr)
{
struct wpabuf *decrypted;
struct wps_parse_attr eattr;
......
// 比較接收到的Enrollee Nonce和Authenticator的內容,防止被中間人篡改
if (wps_process_enrollee_nonce(wps, attr->enrollee_nonce) ||
wps_process_authenticator(wps, attr->authenticator, msg)) {
wps->state = SEND_WSC_NACK;
return WPS_CONTINUE;
}
......
// 解密Encrypted Settings屬性集合
decrypted = wps_decrypt_encr_settings(wps, attr->encr_settings, attr->encr_settings_len);
// 校驗
if (wps_validate_m8_encr(decrypted, wps->wps->ap,attr->version2 != NULL) < 0) {
......// 錯誤處理
}
// 解析Encrypted Settings屬性集合中攜帶的屬性信息
if (wps_parse_msg(decrypted, &eattr) < 0 ||
wps_process_key_wrap_auth(wps, decrypted, eattr.key_wrap_auth) ||
wps_process_creds(wps, eattr.cred, eattr.cred_len,eattr.num_cred,
attr->version2 != NULL) || wps_process_ap_settings_e(wps, &eattr, decrypted,
attr->version2 != NULL)) {
......// 錯誤處理
}
wpabuf_free(decrypted);
wps->state = WPS_MSG_DONE;
return WPS_CONTINUE;
}
~~~
上面代碼中:
* wps_decrypt_encr_settings先解密Encrpyted Settings屬性,解密后的內容保存在decrypted變量中,decrypted是一塊內存緩沖。
* 然后調用wps_parse_msg來解析decrypted緩沖。根據6.2.3節對M7和M8的介紹,EncryptedSettings包含一系列屬性。
* 調用wps_process_creds處理Encyrpted Settings中的Credentials屬性集。該屬性集的內容可參考表6-6。
wps_process_creds的代碼如下所示。
**wps_enrollee.c::wps_process_creds**
~~~
static int wps_process_creds(struct wps_data *wps, const u8 *cred[],
size_t cred_len[], size_t num_cred, int wps2)
{
size_t i;
int ok = 0;
.......
for (i = 0; i < num_cred; i++) {
int res;
res = wps_process_cred_e(wps, cred[i], cred_len[i], wps2);
// 處理屬性集中的每一項屬性
if (res == 0) ok++;
.......
}
......
return 0;
}
~~~
wps_process_cred_e函數的最后將通過cred_cb回調函數將屬性傳遞給wpa_supplicant。該回調函數在6.4.3節WSC模塊初始化分析時介紹的wpas_wps_init函數中被設置為wpa_supplicant_wps_cred,而此函數的代碼如下所示。
**wps_supplicant.c::wpa_supplicant_wps_cred**
~~~
static int wpa_supplicant_wps_cred(void *ctx,const struct wps_credential *cred)
{
struct wpa_supplicant *wpa_s = ctx;
struct wpa_ssid *ssid = wpa_s->current_ssid;
u8 key_idx = 0; u16 auth_type;
......
/*
wps_cred_processing默認為0,表示WPAS內部處理credentials信息。值為1表示將credentials
等信息將通過ctrl_iface發送給客戶端去處理。值為2表示credentials信息由WPAS內部處理,但也會發送
給客戶端。
*/
if (wpa_s->conf->wps_cred_processing == 1) return 0;
auth_type = cred->auth_type; // 獲取AP的認證算法
if (auth_type == (WPS_AUTH_WPAPSK | WPS_AUTH_WPA2PSK)) auth_type = WPS_AUTH_WPA2PSK;
// 檢查認證算法設置是否正確
if (auth_type != WPS_AUTH_OPEN && auth_type != WPS_AUTH_SHARED &&
auth_type != WPS_AUTH_WPAPSK && auth_type != WPS_AUTH_WPA2PSK) return 0;
// EAP-WSC工作基本完成,此時需要更新wpa_ssid對象的信息
if (ssid && (ssid->key_mgmt & WPA_KEY_MGMT_WPS)) {
os_free(ssid->eap.identity);
ssid->eap.identity = NULL ssid->eap.identity_len = 0;
os_free(ssid->eap.phase1); ssid->eap.phase1 = NULL;
os_free(ssid->eap.eap_methods); ssid->eap.eap_methods = NULL;
if (!ssid->p2p_group)
ssid->temporary = 0;
}
......
// 先恢復wpa_ssid的默認設置
wpa_config_set_network_defaults(ssid);
os_free(ssid->ssid);
ssid->ssid = os_malloc(cred->ssid_len);
if (ssid->ssid) {
os_memcpy(ssid->ssid, cred->ssid, cred->ssid_len);
ssid->ssid_len = cred->ssid_len;
}
// 結合屬性信息,更新wpa_ssid中的各個項。首先更新加密算法設置
switch (cred->encr_type) {
......
case WPS_ENCR_TKIP:
ssid->pairwise_cipher = WPA_CIPHER_TKIP;
break;
case WPS_ENCR_AES:
ssid->pairwise_cipher = WPA_CIPHER_CCMP;
break;
}
......// 更新認證算法設置
switch (auth_type) {
case WPS_AUTH_OPEN:
ssid->auth_alg = WPA_AUTH_ALG_OPEN;
ssid->key_mgmt = WPA_KEY_MGMT_NONE;
ssid->proto = 0;
break;
......
case WPS_AUTH_WPA2PSK:
ssid->auth_alg = WPA_AUTH_ALG_OPEN;
ssid->key_mgmt = WPA_KEY_MGMT_PSK;
ssid->proto = WPA_PROTO_RSN;
break;
}
if (ssid->key_mgmt == WPA_KEY_MGMT_PSK) {
// 更新PSK
if (cred->key_len == 2 * PMK_LEN) {
if (hexstr2bin((const char *) cred->key, ssid->psk,PMK_LEN))
return -1;
ssid->psk_set = 1;
ssid->export_keys = 1;
}......
}
// 處理某些使用混合加密模式的AP對WPS支持不夠完善的情況
wpas_wps_security_workaround(wpa_s, ssid, cred);
#ifndef CONFIG_NO_CONFIG_WRITE
if (wpa_s->conf->update_config && // 將配置信息寫到配置文件中對應的無線網絡項中
wpa_config_write(wpa_s->confname, wpa_s->conf)) { ......}
#endif /* CONFIG_NO_CONFIG_WRITE */
return 0;
}
~~~
圖6-36所示為Galaxy Note 2最終所設置的無線網絡配置信息。有了網絡信息,當STA和AP斷開后,它將使用新的網絡信息向AP發起關聯請求。這部分內容我們已經在第4章中重點介紹過了。
:-: 
圖6-36 WSC最終獲取的無線網絡配置信息
>[info] 提示 請讀者自行研究MSG_Done消息的構造,在那里WPAS將發送WPS-SUCCESS信息給上層的WifiMonitor。這樣,WifiStateMachine才能收到WPS_SUCCESS_EVENT消息。
回顧整個EAP-WSC流程,從代碼角度來說,該流程較難的部分不在EAP-WSC本身,而是在于狀態機聯動。讀者不妨仔細閱讀關于狀態機切換處理部分,然后研究EAP-WSC的內容。
>[info] 提示 建議讀者自行研究WPAS代碼中M1~M7的處理流程以加深對EAP-WSC的理解。
- 前言
- 第1章 準備工作
- 1.1 Android系統架構
- 1.2 工具使用
- 1.2.1 Source Insight的使用
- 1.2.2 Eclipse的使用
- 1.2.3 BusyBox的使用
- 1.3 本書資源下載說明
- 第2章 深入理解Netd
- 2.1 概述
- 2.2 Netd工作流程
- 2.2.1 main函數分析
- 2.2.2 NetlinkManager分析
- 2.2.3 CommandListener分析
- 2.2.4 DnsProxyListener分析
- 2.2.5 MDnsSdListener分析
- 2.3 CommandListener中的命令
- 2.3.1 iptables、tc和ip命令
- 2.3.2 CommandListener構造函數和測試工具ndc
- 2.3.3 InterfaceCmd命令
- 2.3.4 IpFwd和FirewallCmd命令
- 2.3.5 ListTtysCmd和PppdCmd命令
- 2.3.6 BandwidthControlCmd和IdletimerControlCmd命令
- 2.3.7 NatCmd命令
- 2.3.8 TetherCmd和SoftapCmd命令
- 2.3.9 ResolverCmd命令
- 2.4 NetworkManagementService介紹
- 2.4.1 create函數詳解
- 2.4.2 systemReady函數詳解
- 2.5 本章總結和參考資料說明
- 2.5.1 本章總結
- 2.5.2 參考資料說明
- 第3章 Wi-Fi基礎知識
- 3.1 概述
- 3.2 無線電頻譜和802.11協議的發展歷程
- 3.2.1 無線電頻譜知識
- 3.2.2 IEEE 802.11發展歷程
- 3.3 802.11無線網絡技術
- 3.3.1 OSI基本參考模型及相關基本概念
- 3.3.2 802.11知識點導讀
- 3.3.3 802.11組件
- 3.3.4 802.11 Service介紹
- 3.3.5 802.11 MAC服務和幀
- 3.3.6 802.11 MAC管理實體
- 3.3.7 無線網絡安全技術知識點
- 3.4 Linux Wi-Fi編程API介紹
- 3.4.1 Linux Wireless Extensions介紹
- 3.4.2 nl80211介紹
- 3.5 本章總結和參考資料說明
- 3.5.1 本章總結
- 3.5.2 參考資料說明
- 第4章 深入理解wpa_supplicant
- 4.1 概述
- 4.2 初識wpa_supplicant
- 4.2.1 wpa_supplicant架構
- 4.2.2 wpa_supplicant編譯配置
- 4.2.3 wpa_supplicant命令和控制API
- 4.2.4 git的使用
- 4.3 wpa_supplicant初始化流程
- 4.3.1 main函數分析
- 4.3.2 wpa_supplicant_init函數分析
- 4.3.3 wpa_supplicant_add_iface函數分析
- 4.3.4 wpa_supplicant_init_iface函數分析
- 4.4 EAP和EAPOL模塊
- 4.4.1 EAP模塊分析
- 4.4.2 EAPOL模塊分析
- 4.5 wpa_supplicant連接無線網絡分析
- 4.5.1 ADD_NETWORK命令處理
- 4.5.2 SET_NETWORK命令處理
- 4.5.3 ENABLE_NETWORK命令處理
- 4.6 本章總結和參考資料說明
- 4.6.1 本章總結
- 4.6.2 參考資料說明
- 第5章 深入理解WifiService
- 5.1 概述
- 5.2 WifiService的創建及初始化
- 5.2.1 HSM和AsyncChannel介紹
- 5.2.2 WifiService構造函數分析
- 5.2.3 WifiStateMachine介紹
- 5.3 加入無線網絡分析
- 5.3.1 Settings操作Wi-Fi分析
- 5.3.2 WifiService操作Wi-Fi分析
- 5.4 WifiWatchdogStateMachine介紹
- 5.5 Captive Portal Check介紹
- 5.6 本章總結和參考資料說明
- 5.6.1 本章總結
- 5.6.2 參考資料說明
- 第6章 深入理解Wi-Fi Simple Configuration
- 6.1 概述
- 6.2 WSC基礎知識
- 6.2.1 WSC應用場景
- 6.2.2 WSC核心組件及接口
- 6.3 Registration Protocol詳解
- 6.3.1 WSC IE和Attribute介紹
- 6.3.2 802.11管理幀WSC IE設置
- 6.3.3 EAP-WSC介紹
- 6.4 WSC代碼分析
- 6.4.1 Settings中的WSC處理
- 6.4.2 WifiStateMachine的處理
- 6.4.3 wpa_supplicant中的WSC處理
- 6.4.4 EAP-WSC處理流程分析
- 6.5 本章總結和參考資料說明
- 6.5.1 本章總結
- 6.5.2 參考資料說明
- 第7章 深入理解Wi-Fi P2P
- 7.1 概述
- 7.2 P2P基礎知識
- 7.2.1 P2P架構
- 7.2.2 P2P Discovery技術
- 7.2.3 P2P工作流程
- 7.3 WifiP2pSettings和WifiP2pService介紹
- 7.3.1 WifiP2pSettings工作流程
- 7.3.2 WifiP2pService工作流程
- 7.4 wpa_supplicant中的P2P
- 7.4.1 P2P模塊初始化
- 7.4.2 P2P Device Discovery流程分析
- 7.4.3 Provision Discovery流程分析
- 7.4.4 GO Negotiation流程分析
- 7.5 本章總結和參考資料說明
- 7.5.1 本章總結
- 7.5.2 參考資料說明
- 第8章 深入理解NFC
- 8.1 概述
- 8.2 NFC基礎知識
- 8.2.1 NFC概述
- 8.2.2 NFC R/W運行模式
- 8.2.3 NFC P2P運行模式
- 8.2.4 NFC CE運行模式
- 8.2.5 NCI原理
- 8.2.6 NFC相關規范
- 8.3 Android中的NFC
- 8.3.1 NFC應用示例
- 8.3.2 NFC系統模塊
- 8.4 NFC HAL層討論
- 8.5 本章總結和參考資料說明
- 8.5.1 本章總結
- 8.5.2 參考資料說明
- 第9章 深入理解GPS
- 9.1 概述
- 9.2 GPS基礎知識
- 9.2.1 衛星導航基本原理
- 9.2.2 GPS系統組成及原理
- 9.2.3 OMA-SUPL協議
- 9.3 Android中的位置管理
- 9.3.1 LocationManager架構
- 9.3.2 LocationManager應用示例
- 9.3.3 LocationManager系統模塊
- 9.4 本章總結和參考資料說明
- 9.4.1 本章總結
- 9.4.2 參考資料說明
- 附錄