Unable to Connect to Open Network (Part 2)

[Cy Schubert]

Hi,

Last week I posted an email discussing a regression from 2.9 a FreeBSD user 
discovered. I was able to reproduce the problem locally using a Netgear 
WNDR3700v3 (I have two of these, results the same on both).

The problem occurs when the primary VAP is configured with WPA and the 
secondary VAP (guest network on Netgear) is open and unprotected. What I'm 
seeing is an IE that causes wpa_supplicant to assume WPA even though 
key_mgmt=NONE.

The hackish patch below works around the problem:

diff --git a/contrib/wpa/src/drivers/driver_bsd.c b/contrib/wpa/src/drivers/
driver_bsd.c
index c455bc931036..b39198b7249b 100644
--- a/contrib/wpa/src/drivers/driver_bsd.c
+++ b/contrib/wpa/src/drivers/driver_bsd.c
@@ -1209,6 +1209,10 @@ wpa_driver_bsd_associate(void *priv, struct 
wpa_driver_associate_params *params)
 	int privacy;
 	int ret = 0;
 
+	/* XXX woraround for PR/264238 until a better solution can be found */
+	const u8 *wpa_ie_save;
+	size_t wpa_ie_len_save;
+
 	wpa_printf(MSG_DEBUG,
 		"%s: ssid '%.*s' wpa ie len %u pairwise %u group %u key mgmt %u"
 		, __func__
@@ -1256,9 +1260,26 @@ wpa_driver_bsd_associate(void *priv, struct 
wpa_driver_associate_params *params)
 		ret = -1;
 	if (wpa_driver_bsd_set_auth_alg(drv, params->auth_alg) < 0)
 		ret = -1;
+
+	/* XXX woraround for PR/264238 until a better solution can be found */
+	if (params->pairwise_suite == WPA_CIPHER_NONE &&
+	    params->group_suite == WPA_CIPHER_NONE &&
+	    params->key_mgmt_suite == WPA_KEY_MGMT_NONE &&
+	    params->wpa_ie_len != 0) {
+		wpa_ie_save = params->wpa_ie;
+		wpa_ie_len_save = params->wpa_ie_len;
+		params->wpa_ie = NULL;
+		params->wpa_ie_len = 0;
+	} else {
+		wpa_ie_save = NULL;
+		wpa_ie_len_save = 0;
+	}
+
 	/* XXX error handling is wrong but unclear what to do... */
-	if (wpa_driver_bsd_set_wpa_ie(drv, params->wpa_ie, params->wpa_ie_len) < 
0)
-		return -1;
+	if (wpa_driver_bsd_set_wpa_ie(drv, params->wpa_ie, params->wpa_ie_len) < 
0) {
+		ret = -1;
+		goto bsd_assoc_exit;
+	}
 
 	privacy = !(params->pairwise_suite == WPA_CIPHER_NONE &&
 	    params->group_suite == WPA_CIPHER_NONE &&
@@ -1266,20 +1287,26 @@ wpa_driver_bsd_associate(void *priv, struct 
wpa_driver_associate_params *params)
 	    params->wpa_ie_len == 0);
 	wpa_printf(MSG_DEBUG, "%s: set PRIVACY %u", __func__, privacy);
 
-	if (set80211param(drv, IEEE80211_IOC_PRIVACY, privacy) < 0)
-		return -1;
+	if (set80211param(drv, IEEE80211_IOC_PRIVACY, privacy) < 0) {
+		ret = -1;
+		goto bsd_assoc_exit;
+	}
 
 	if (params->wpa_ie_len &&
 	    set80211param(drv, IEEE80211_IOC_WPA,
-			  params->wpa_ie[0] == WLAN_EID_RSN ? 2 : 1) < 0)
-		return -1;
+			  params->wpa_ie[0] == WLAN_EID_RSN ? 2 : 1) < 0) {
+		ret = -1;
+		goto bsd_assoc_exit;
+	}
 
 	/*
 	 * NB: interface must be marked UP for association
 	 * or scanning (ap_scan=2)
 	 */
-	if (bsd_get_iface_flags(drv) < 0)
-		return -1;
+	if (bsd_get_iface_flags(drv) < 0) {
+		ret = -1;
+		goto bsd_assoc_exit;
+	}
 
 	os_memset(&mlme, 0, sizeof(mlme));
 	mlme.im_op = IEEE80211_MLME_ASSOC;
@@ -1289,7 +1316,10 @@ wpa_driver_bsd_associate(void *priv, struct 
wpa_driver_associate_params *params)
 	if (params->bssid != NULL)
 		os_memcpy(mlme.im_macaddr, params->bssid, IEEE80211_ADDR_LEN);
 	if (set80211var(drv, IEEE80211_IOC_MLME, &mlme, sizeof(mlme)) < 0)
-		return -1;
+		ret = -1;
+bsd_assoc_exit:
+	params->wpa_ie = wpa_ie_save;
+	params->wpa_ie_len = wpa_ie_len_save;
 	return ret;
 }
 
However, the code this patch touches has been in driver_bsd.c since 2008 
so, obviously the code this patch addresses is not the cause of the 
regression from 2.9 to 2.10. The problem lies elsewhere and the above patch 
treats the symptom and not the cause. The problem is I don't have nearly 
enough experience with hostap internals to identify the hostap commit that 
likely caused the regression.

Where might I look to discover in hostap where the IE is received from the 
AP, and if this jogs someone's recollection of the patch I'd be grateful.

In summary, based on my testing this only occurs on a secondary open 
unencrypted VAP when the primary VAP is configured for WPA.

P.S. The setting of params->wpa_ie back to its original value at the end of 
the patch is in the one case I can find where this memory is obtained 
through os_malloc(), avoiding a memory leak.

This is a hackish workaround but I'd prefer finding a better solution.

Any help would be muchly appreciated.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy at nwtime.org>    Web:  https://nwtime.org

			e**(i*pi)+1=0