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的理解。