Skip to contentSkip to conversation

WPA_NONE support in mac80211/ath9k

RFC In review Sven Eckelmann 2 participants 6 messages Jan 28, 2013 – Jan 29, 2013

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover WPA_NONE support in mac80211/ath9k

Hi,

I've tried to use WPA_NONE together with ath9k (other people reported problems, but said it would be batman-adv related [1]). I ran into three smaller problems and worked around them. I am not sure what kind of support mac80211 should have for WPA_NONE, but maybe also someone else is trying it and could use this as a reference. Nevertheless, IBSS/RSN should be preferred.

I've used a wpa_supplicant with fixed-ibss support [2,3] on an vif configured as adhoc device.

ap_scan=2
fast_reauth=1

	network={
	ssid="ESSID"
	mode=1
	proto=WPA
	frequency=2422
	key_mgmt=WPA-NONE
	pairwise=NONE
	group=CCMP
	psk="abcd1234"
	bssid=02:00:de:ad:be:fe
}

First problem was related in the way the decryption is done. No unicast frames could be decrypted because the group key (the only one set for WPA_NONE) wasn't allowed to be used for unicast decryption.

The second problem was the replay detection. Replay detection doesn't work with WPA_NONE and therefore has to be disabled.

The third problem was the inability to set the key when no link was established. This lead to unencrypted broadcast packets sent over the air... not really nice. Therefore, I've just disabled the check [4] for now.

I was informed by Antonio Quartulli about the controversy to use
!sta->sdata->u.ibss.control_port to check for for non-IBSS/RSN mode. Just
think about it is a placeholder for the imaginary function "ieee80211_ibss_is_wpanone(...)".

Is the inability to use WPA_NONE with ath9k/mac80211 intended or just a regression nobody noticed? In the latter case, any things which should be changed to make the patches upstream ready?

Kind regards,
Sven

[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2013-January/008895.html
[2] http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=913e3cf794cccf19d551d936a16c7d91acb5e834
[3] http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=9e2af29f9bf065099b9a2abceaf40ac0e1bf86fa
[4] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=fffd0934b9390f34bec45762192b7edd3b12b4b5

#1 lore raw

RFC 1/3 mac80211: Allow group key for IBSS WPA_NONE

WPA_NONE uses the shared group key to encrypt the protected frames. Therefore, it must also be allowed for non-multicast frames to use the group key for decryption.

---
 net/mac80211/rx.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
net/mac80211/rx.c +3 -1
index a190895..d412fd0 100644
@@ -1160,7 +1160,9 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
 			if (rx->key &&
 			    rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP40 &&
 			    rx->key->conf.cipher != WLAN_CIPHER_SUITE_WEP104 &&
-			    !is_multicast_ether_addr(hdr->addr1))
+			    !is_multicast_ether_addr(hdr->addr1) &&
+			    (rx->sdata->vif.type != NL80211_IFTYPE_ADHOC ||
+			     rx->sdata->u.ibss.control_port))
 				rx->key = NULL;
 		}
 	}
Signature · 1 line
1.7.10.4
#2 lore raw

RFC 2/3 mac80211: Ignore CCMP replays for IBSS WPA_NONE

WPA_NONE has no support to avoid CCMP replays and therefore we have to disable it in this situation to allow rejoining stations.

---
 net/mac80211/wpa.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
net/mac80211/wpa.c +3 -1
index c175ee8..f961d9a 100644
@@ -517,7 +517,9 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx)
 
 	queue = rx->security_idx;
 
-	if (memcmp(pn, key->u.ccmp.rx_pn[queue], CCMP_PN_LEN) <= 0) {
+	if (memcmp(pn, key->u.ccmp.rx_pn[queue], CCMP_PN_LEN) <= 0 &&
+	    (rx->sdata->vif.type != NL80211_IFTYPE_ADHOC ||
+	     rx->sdata->u.ibss.control_port)) {
 		key->u.ccmp.replays++;
 		return RX_DROP_UNUSABLE;
 	}
Signature · 1 line
1.7.10.4
#3 lore raw

PATCH 3/3 nl80211: Allow to set IBSS key even before IBSS_JOIN

In reply to Sven Eckelmann

WPA_NONE will use a shared group key for unicast and multicast. It is therefore better to allow early setting of keys to prevent any leakage of information through multicast frames.

---
 net/wireless/nl80211.c |    3 ---
 1 file changed, 3 deletions(-)
net/wireless/nl80211.c +0 -3
index 33de803..3fb3491 100644
@@ -766,10 +766,7 @@ static int nl80211_key_allowed(struct wireless_dev *wdev)
 	case NL80211_IFTYPE_AP_VLAN:
 	case NL80211_IFTYPE_P2P_GO:
 	case NL80211_IFTYPE_MESH_POINT:
-		break;
 	case NL80211_IFTYPE_ADHOC:
-		if (!wdev->current_bss)
-			return -ENOLINK;
 		break;
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_P2P_CLIENT:
Signature · 1 line
1.7.10.4
maintainer
#4 lore raw
In reply to Sven Eckelmann
Quoted 8 lines · Sven Eckelmann

Hi,

I've tried to use WPA_NONE together with ath9k (other people reported problems, but said it would be batman-adv related [1]). I ran into three smaller problems and worked around them. I am not sure what kind of support mac80211 should have for WPA_NONE, but maybe also someone else is trying it and could use this as a reference. Nevertheless, IBSS/RSN should be preferred.

All of this seems really hacky. For example, instead of installing the keys earlier, you should manage the authorized flag like in RSN IBSS. Similarly, why not just install the same key for all stations? That way, you probably don't even need the replay detection.

johannes

#5 lore raw
Quoted 1 line · On Tuesday 29 January 2013 20:23:03 Johannes Berg wrote:

All of this seems really hacky.

Because they are only hacks :D

But they are giving a good starting point for a discussion.

Kind regards,
Sven