>> wpa_supplicant_set_suites() can be called without providing a scan >> result. Don't flush ie elements in this case. > Could you please provide more details and a debug log showing a case > where this ends up flushing IE information incorrectly? Does this > actually fix a connection in some cases? This is not really "fixing" a connection in the current code. It just gets rid of a avoidable scan in some cases. The next version for Extended Key ID support patches depends on it or it breaks some owe connections when enabled and it looks like some connections are currently only working due to another decision or maybe a bug. (The IE mismatch detection issue outlined below.) Let's start with the reasoning why I think it should be changed: wpa_supplicant_set_suites() can be called with bss set to NULL: * @bss: Scan results for the selected BSS, or %NULL if not available Now when bss is NULL bss_wpa, bss_rsn, bss_rsnx and bss_osen are unconditionally NULL, too. Therefore ap_ies_from_associnfo = 0 is only the trigger to delete any ie data stored in the state machine. But any data stored there should still be "valid" and in fact may be needed later again. I'm pretty sure the intent for ap_ies_from_associnfo is to make sure we only store ie data from a beacon in the state machine, to have them later available in wpa_supplicant_validate_ie() to be verified against the IE from eapol#3. wpa_supplicant_validate_ie() is by the way also assuming that the variables are set and for some reason is not triggering a RSN mismatch when ap_wpa_ie or ap_rsn_ie the state machine is NULL. (It's done for ap_rsnxe.) We may want to fix that, too... I'll send you an alternate patch for this one including that, too. But that may trigger disconnects with some broken APs and is a bit more risky. With the code as it is today we just have some suboptimal cases we can see in the following tests: owe_transition_mode owe_transition_mode_connect_cmd owe_transition_mode_multi_bss owe_transition_mode_open_multiple_scans Looking at owe_transition_mode.log0 from a test run we see the following order of events: (I generously removed lines and just kept enough to see the picture. The full logfile is available here: https://www.awhome.eu/index.php/s/jDQfpZmDGwsLPXA and named cf28cfc12-orig-owe_transition_mode.log0) line log message 321 wlan0: Request association with 02:00:00:00:03:00 337 wlan0: WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 4194304 proto 2 339 wlan0: WPA: clearing AP WPA IE --- here we set the variable 340 WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 12 cc 00 341 wlan0: WPA: clearing AP RSNXE 361 wlan0: SME: Trying to authenticate with 02:00:00:00:03:00 (SSID='owe-random' freq=2412 MHz) 367 wlan0: State: INACTIVE -> AUTHENTICATING 435 wlan0: State: AUTHENTICATING -> ASSOCIATING 497 wlan0: State: ASSOCIATING -> ASSOCIATED 508 wlan0: Associated to a new BSS: BSSID=02:00:00:00:03:00 511 wlan0: Network configuration found for the current AP 512 wlan0: WPA: Using WPA IE from AssocReq to set cipher suites 513 wlan0: WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 4194304 proto 2 --- here are the variables cleared without any good reason --- 515 wlan0: WPA: clearing AP WPA IE 516 wlan0: WPA: clearing AP RSN IE 517 wlan0: WPA: clearing AP RSNXE 532 wlan0: Associated with 02:00:00:00:03:00 583 wlan0: State: ASSOCIATED -> 4WAY_HANDSHAKE 592 wlan0: WPA: RX message 1 of 4-Way Handshake from 02:00:00:00:03:00 (ver=0) 606 wlan0: WPA: Sending EAPOL-Key 2/4 630 wlan0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE 631 wlan0: WPA: RX message 3 of 4-Way Handshake from 02:00:00:00:03:00 (ver=0) --- here we need the deleted data again and trigger a scan the set the variables again --- 636 wlan0: WPA: No WPA/RSN IE for this AP known. Trying to get from scan results 637 nl80211: Received scan results (3 BSSes) 638 nl80211: Scan results indicate BSS status with 02:00:00:00:03:00 as associated --- but we don't get them and as a result bypass the (also broken?) IE mismatch check 647 wlan0: WPA: Could not find AP from the scan results 652 wlan0: WPA: Sending EAPOL-Key 4/4 >> diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c >> @@ -1378,7 +1378,7 @@ int wpa_supplicant_set_suites(struct wpa_supplicant *wpa_s, >> wpa_sm_set_param(wpa_s->wpa, WPA_PARAM_RSN_ENABLED, >> !!(ssid->proto & (WPA_PROTO_RSN | WPA_PROTO_OSEN))); >> >> - if (bss || !wpa_s->ap_ies_from_associnfo) { >> + if (bss && !wpa_s->ap_ies_from_associnfo) { >> if (wpa_sm_set_ap_wpa_ie(wpa_s->wpa, bss_wpa, >> bss_wpa ? 2 + bss_wpa[1] : 0) || > > This does not flush IEs if bss != NULL (that uses the BSS table entry > from scan results). I'm not sure I understand why the IEs should not be > cleared if there is neither a BSS entry nor IEs from association > information. I stopped digging into that after discovering that the bss is an optional argument. But as explained above we must not update the state machine variables with IEs from association requests. So I assume that was the intent of the code and we just use the wrong logical operation for that. Which then deletes the variables. It could be that the correct fix is to make the bss mandatory or at least never call wpa_supplicant_set_suites() when one of the variables are set... But that's not my understanding of the code. Alexander _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
