Please comment on these patches to hostapd-0.7.3

[B. J.]

Hello All,

While updating my company's hostapd from 0.6.9 to 0.7.3, I found that some
custom changes were applied to 0.6.9 that, as far as I can tell, were not
submitted here for RFC.  Please let me know what you think of these
patches, and whether or not they are appropriate for inclusion in hostapd:


Patch 1:

Problems using NT-hash passwords for EPA-TTLS and EAP-PEAP authentications
- hostapd was not copying password_hash element while creating dynamic EAP
user object for each supplicant state machine. Though the configured object
has correct value set (password_hash=1), if we do not copy this value,
dynamic eap_user object in supplicant state machine will loose this value
and will treat the password as clear text password and can not authenticate
the client due to password mismatch.

--- vendor-drop/src/src/ap/ieee802_1x.c	2010-09-07 08:43:39.000000000 -0700
+++ mainline/src/src/ap/ieee802_1x.c	2011-10-13 11:50:25.426100260 -0700
@@ -1536,10 +1536,11 @@ static int ieee802_1x_get_eap_user(void 
		if (user->password == NULL)
			return -1;
		os_memcpy(user->password, eap_user->password,
			  eap_user->password_len);
		user->password_len = eap_user->password_len;
+		user->password_hash = eap_user->password_hash;
	}
	user->force_version = eap_user->force_version;
	user->ttls_auth = eap_user->ttls_auth;

	return 0;


Patch 2:

Wireless clients being disconnected "due to inactivity" - When WPA & WPA2
are enabled simultaneously, the key information for both WPA2 & WPA is sent
to the client even after they have made the decision that WPA2 will be
used. It confuses the client. As a result, the client thinks the
authentication is not ended and waits for further GTK negotiation, while
the AP thinks it is done. So the client will keep authenticating status and
is disconnected after timeout.


--- vendor-drop/src/src/ap/wpa_auth.c	2010-09-07 08:43:39.000000000 -0700
+++ mainline/src/src/ap/wpa_auth.c	2011-10-13 12:00:25.536104199 -0700
@@ -1707,10 +1707,16 @@ SM_STATE(WPA_PTK, PTKINITNEGOTIATING)
	    wpa_ie_len > wpa_ie[1] + 2 && wpa_ie[0] == WLAN_EID_RSN) {
		/* WPA-only STA, remove RSN IE */
		wpa_ie = wpa_ie + wpa_ie[1] + 2;
		wpa_ie_len = wpa_ie[1] + 2;
	}
+	if (sm->wpa == WPA_VERSION_WPA2 && 
+			(sm->wpa_auth->conf.wpa & WPA_PROTO_WPA) &&
+			wpa_ie[0] == WLAN_EID_RSN) {
+		/* WPA2 STA, remove WPA IE */
+		wpa_ie_len = wpa_ie[1] + 2;
+	}
	wpa_auth_logger(sm->wpa_auth, sm->addr, LOGGER_DEBUG,
			"sending 3/4 msg of 4-Way Handshake");
	if (sm->wpa == WPA_VERSION_WPA2) {
		/* WPA2 send GTK in the 4-way handshake */
		secure = 1;


Patch 3:

Each AP has its own group key, but ath9k driver (which is what we're using)
only uses one. So the last AP setting the group key will be able to send
out multicast/broadcast packets, and other APs' multicast/broadcast will
fail.  I've updated the ath9k driver we're using since this change was
made; I'll check into what's going on with the later ath9k driver, and in
any case this looks like an obvious kludge, but for now I'll just throw it
out there.


--- vendor-drop/src/src/ap/wpa_auth.c	2010-09-07 08:43:39.000000000 -0700
+++ mainline/src/src/ap/wpa_auth.c	2011-10-13 12:00:25.536104199 -0700
@@ -2098,10 +2104,12 @@ static int wpa_gtk_update(struct wpa_aut
	os_memcpy(group->GNonce, group->Counter, WPA_NONCE_LEN);
	inc_byte_array(group->Counter, WPA_NONCE_LEN);
	wpa_gmk_to_gtk(group->GMK, wpa_auth->addr, group->GNonce,
		       group->GTK[group->GN - 1], group->GTK_len);

+	memset(group->GTK[group->GN - 1], 1, group->GTK_len);
+
#ifdef CONFIG_IEEE80211W
	if (wpa_auth->conf.ieee80211w != NO_MGMT_FRAME_PROTECTION) {
		if (os_get_random(group->IGTK[group->GN_igtk - 4],
				  WPA_IGTK_LEN) < 0) {
			wpa_printf(MSG_INFO, "RSN: Failed to get new random "



Patch 4:

There used to be a control that allowed wireless client-to-client traffic
to be prevented.  This was supposed to be supported through
i802_set_internal_bridge().  However, that hook was removed in April of
2009.  We were using a patch that implemented that capability (AFAICT, it
was always just a NOOP before).  So wondering what the thinking is on this,
and whether or not it should still be possible to prevent wireless
client-to-client traffic.

TIA,
-bp