[PATCH 0/5] iwlwifi driver updates

[PATCH 0/5] iwlwifi driver updates

[Reinette Chatre]

This series provides support for HW encryption for 4965.
TKIP in iwlwifi requires that for TX rekeying is computed in
software and also phase1 rekeying for RX is computed by 
software. mac80211 encryption infrastracture is utilized for
this.

[PATCH 1/5] mac80211: allows driver to request a Phase 2 key
[PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key
[PATCH 3/5] iwlwifi-2.6: Cleans up set_key flow
[PATCH 4/5] iwlwifi-2.6: enables HW TKIP security
[PATCH 5/5] iwlwifi-2.6: RX status translation to old scheme

Thanks

Reinette

[PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Reinette Chatre]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This patch makes the mac80211 able to send a ready phase2 key to the low
level driver for TKIP encryption. Iwlwifi needs to get a phase2 key to
encrypt TX packets in HW.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 include/net/mac80211.h |    5 +++++
 net/mac80211/wpa.c     |    3 +++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5ab6a35..a0c7cd7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -287,6 +287,7 @@ struct ieee80211_tx_control {
 	u8 iv_len;		/* length of the IV field in octets */
 	u8 queue;		/* hardware queue to use for this frame;
 				 * 0 = highest, hw->queues-1 = lowest */
+	u8 tkip_key[16];	/* generated phase2/phase1 key for hw TKIP */
 	int type;	/* internal */
 };
 
@@ -586,11 +587,15 @@ enum ieee80211_key_alg {
  * @IEEE80211_KEY_FLAG_GENERATE_MMIC: This flag should be set by
  *	the driver for a TKIP key if it requires Michael MIC
  *	generation in software.
+ * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
+ *	the driver for a TKIP key if it requires a phase2 TX key generation
+ *	in SW. The key will be attached to each packet.
  */
 enum ieee80211_key_flags {
 	IEEE80211_KEY_FLAG_WMM_STA	= 1<<0,
 	IEEE80211_KEY_FLAG_GENERATE_IV	= 1<<1,
 	IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
+	IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY = 1<<3,
 };
 
 /**
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index db6b72b..ee9c5cf 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -224,6 +224,9 @@ static int tkip_encrypt_skb(struct ieee80211_tx_data *tx,
 		/* hwaccel - with preallocated room for IV */
 		ieee80211_tkip_add_iv(pos, key);
 
+		if (key->conf.flags & IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY)
+			ieee80211_tkip_gen_rc4key(key, hdr->addr2,
+						tx->control->tkip_key);
 		tx->control->key_idx = tx->key->conf.hw_key_idx;
 		return 0;
 	}
-- 
1.5.3.4

[PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Reinette Chatre]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This patch makes mac80211 able to send a phase1 key for TKIP decryption.
This is needed for drivers that don't do the rekeying by themselves
(i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 include/net/mac80211.h |   10 ++++++++++
 net/mac80211/tkip.c    |   19 +++++++++++++++++--
 net/mac80211/tkip.h    |    1 +
 net/mac80211/wpa.c     |   12 ++++++++++++
 4 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a0c7cd7..3b5d57c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -590,12 +590,20 @@ enum ieee80211_key_alg {
  * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
  *	the driver for a TKIP key if it requires a phase2 TX key generation
  *	in SW. The key will be attached to each packet.
+ * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
+ *	for a TKIP key if it requires phase 1 key generation in software.
+ *	The phase 1 key will be sent in the same context as Rx.
+ * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
+ *	IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
+ *	fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
  */
 enum ieee80211_key_flags {
 	IEEE80211_KEY_FLAG_WMM_STA	= 1<<0,
 	IEEE80211_KEY_FLAG_GENERATE_IV	= 1<<1,
 	IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
 	IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY = 1<<3,
+	IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY = 1<<4,
+	IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID = 1<<5,
 };
 
 /**
@@ -619,6 +627,8 @@ struct ieee80211_key_conf {
 	u8 flags;
 	s8 keyidx;
 	u8 keylen;
+	u16 tkip_p1k[5];
+	u8 tkip_iv32;
 	u8 key[0];
 };
 
diff --git a/net/mac80211/tkip.c b/net/mac80211/tkip.c
index 18a3fb0..f61f1dd 100644
--- a/net/mac80211/tkip.c
+++ b/net/mac80211/tkip.c
@@ -171,7 +171,7 @@ u8 *ieee80211_tkip_add_iv(u8 *pos, struct ieee80211_key *key)
 	return pos;
 }
 
-static void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta,
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta,
 			       u8 *rc4key)
 {
 	/* Calculate per-packet key */
@@ -263,7 +263,8 @@ int ieee80211_tkip_decrypt_data(struct crypto_blkcipher *tfm,
 		return TKIP_DECRYPT_REPLAY;
 	}
 
-	if (only_iv) {
+	if (only_iv &&
+		!(key->conf.flags & IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY)) {
 		res = TKIP_DECRYPT_OK;
 		key->u.tkip.rx_initialized[queue] = 1;
 		goto done;
@@ -275,6 +276,14 @@ int ieee80211_tkip_decrypt_data(struct crypto_blkcipher *tfm,
 		/* IV16 wrapped around - perform TKIP phase 1 */
 		tkip_mixing_phase1(ta, &key->conf.key[ALG_TKIP_TEMP_ENCR_KEY],
 				   iv32, key->u.tkip.p1k_rx[queue]);
+		if (key->conf.flags & IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY) {
+			/* The driver needs a phase 1 key, provide it */
+			memcpy(&key->conf.tkip_p1k,
+				&key->u.tkip.p1k_rx[queue],
+				sizeof(key->conf.tkip_p1k));
+			key->conf.tkip_iv32 = iv32;
+			key->conf.flags |= IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID;
+		}
 #ifdef CONFIG_TKIP_DEBUG
 		{
 			int i;
@@ -294,6 +303,12 @@ int ieee80211_tkip_decrypt_data(struct crypto_blkcipher *tfm,
 #endif /* CONFIG_TKIP_DEBUG */
 	}
 
+	if (only_iv) {
+		res = TKIP_DECRYPT_OK;
+		key->u.tkip.rx_initialized[queue] = 1;
+		goto done;
+	}
+
 	tkip_mixing_phase2(key->u.tkip.p1k_rx[queue],
 			   &key->conf.key[ALG_TKIP_TEMP_ENCR_KEY],
 			   iv16, rc4key);
diff --git a/net/mac80211/tkip.h b/net/mac80211/tkip.h
index 662354b..9a07102 100644
--- a/net/mac80211/tkip.h
+++ b/net/mac80211/tkip.h
@@ -14,6 +14,7 @@
 #include "ieee80211_key.h"
 
 u8 * ieee80211_tkip_add_iv(u8 *pos, struct ieee80211_key *key);
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta, u8 *rc4key);
 void ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
 				 struct ieee80211_key *key,
 				 u8 *pos, size_t payload_len, u8 *ta);
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index ee9c5cf..478251b 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -324,6 +324,18 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
 		return RX_DROP_UNUSABLE;
 	}
 
+	if (key->conf.flags & IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID) {
+		u8 bcast[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+		u8 *sta_addr = rx->sta->addr;
+
+		if (is_multicast_ether_addr(hdr->addr1))
+			sta_addr = bcast;
+
+		rx->local->ops->set_key(local_to_hw(rx->local),
+			SET_KEY, rx->dev->dev_addr, sta_addr, &key->conf);
+		key->conf.flags &= ~IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID;
+	}
+
 	/* Trim ICV */
 	skb_trim(skb, skb->len - TKIP_ICV_LEN);
 
-- 
1.5.3.4

[PATCH 3/5] iwlwifi-2.6: Cleans up set_key flow

[Reinette Chatre]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This patch cleans up the set_key flow. Rxon with hw encryption bit set is
not sent upon each call to set_key. Separation is made between global key
(WEP) and dynamic key (TKIP + CCMP and WEP in some cases).

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-4965-commands.h |    1 +
 drivers/net/wireless/iwlwifi/iwl4965-base.c      |  159 ++++++++++++++-------
 2 files changed, 107 insertions(+), 53 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
index 1025ffe..085d813 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
@@ -741,6 +741,7 @@ struct iwl4965_qosparam_cmd {
 /* wep key in STA: 5-bytes (0) or 13-bytes (1) */
 #define STA_KEY_FLG_KEY_SIZE_MSK     __constant_cpu_to_le16(0x1000)
 #define STA_KEY_MULTICAST_MSK        __constant_cpu_to_le16(0x4000)
+#define STA_KEY_MAX_NUM		8
 
 /* Flags indicate whether to modify vs. don't change various station params */
 #define	STA_MODIFY_KEY_MASK		0x01
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index 396940e..d47941d 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -815,6 +815,17 @@ out:
 	return ret;
 }
 
+static void iwl4965_set_rxon_hwcrypto(struct iwl_priv *priv, int hw_decrypt)
+{
+	struct iwl4965_rxon_cmd *rxon = &priv->staging_rxon;
+
+	if (hw_decrypt)
+		rxon->filter_flags &= ~RXON_FILTER_DIS_DECRYPT_MSK;
+	else
+		rxon->filter_flags |= RXON_FILTER_DIS_DECRYPT_MSK;
+
+}
+
 int iwl4965_send_cmd(struct iwl_priv *priv, struct iwl4965_host_cmd *cmd)
 {
 	if (cmd->meta.flags & CMD_ASYNC)
@@ -1180,6 +1191,7 @@ static int iwl4965_commit_rxon(struct iwl_priv *priv)
 		       le16_to_cpu(priv->staging_rxon.channel),
 		       print_mac(mac, priv->staging_rxon.bssid_addr));
 
+	iwl4965_set_rxon_hwcrypto(priv, iwl4965_param_hwcrypto);
 	/* Apply the new configuration */
 	rc = iwl4965_send_cmd_pdu(priv, REPLY_RXON,
 			      sizeof(struct iwl4965_rxon_cmd), &priv->staging_rxon);
@@ -1392,33 +1404,36 @@ int iwl4965_send_add_station(struct iwl_priv *priv,
 	return rc;
 }
 
-static int iwl4965_update_sta_key_info(struct iwl_priv *priv,
+static int iwl4965_set_ccmp_dynamic_key_info(struct iwl_priv *priv,
 				   struct ieee80211_key_conf *keyconf,
 				   u8 sta_id)
 {
 	unsigned long flags;
 	__le16 key_flags = 0;
 
-	switch (keyconf->alg) {
-	case ALG_CCMP:
-		key_flags |= STA_KEY_FLG_CCMP;
-		key_flags |= cpu_to_le16(
-				keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
-		key_flags &= ~STA_KEY_FLG_INVALID;
-		break;
-	case ALG_TKIP:
-	case ALG_WEP:
-	default:
-		return -EINVAL;
-	}
+	key_flags |= (STA_KEY_FLG_CCMP | STA_KEY_FLG_MAP_KEY_MSK);
+	key_flags |= cpu_to_le16(keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
+
+	if (sta_id == priv->hw_setting.bcast_sta_id)
+		key_flags |= STA_KEY_MULTICAST_MSK;
+
+	keyconf->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+	keyconf->hw_key_idx = sta_id;
+
+	key_flags &= ~STA_KEY_FLG_INVALID;
+
 	spin_lock_irqsave(&priv->sta_lock, flags);
 	priv->stations[sta_id].keyinfo.alg = keyconf->alg;
 	priv->stations[sta_id].keyinfo.keylen = keyconf->keylen;
+
 	memcpy(priv->stations[sta_id].keyinfo.key, keyconf->key,
 	       keyconf->keylen);
 
 	memcpy(priv->stations[sta_id].sta.key.key, keyconf->key,
 	       keyconf->keylen);
+
+	priv->stations[sta_id].sta.key.key_offset
+			= (sta_id % STA_KEY_MAX_NUM);/*FIXME*/
 	priv->stations[sta_id].sta.key.key_flags = key_flags;
 	priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
 	priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
@@ -1426,8 +1441,15 @@ static int iwl4965_update_sta_key_info(struct iwl_priv *priv,
 	spin_unlock_irqrestore(&priv->sta_lock, flags);
 
 	IWL_DEBUG_INFO("hwcrypto: modify ucode station key info\n");
-	iwl4965_send_add_station(priv, &priv->stations[sta_id].sta, 0);
-	return 0;
+	return iwl4965_send_add_station(priv,
+				&priv->stations[sta_id].sta, CMD_ASYNC);
+}
+
+static int iwl4965_set_tkip_dynamic_key_info(struct iwl_priv *priv,
+				   struct ieee80211_key_conf *keyconf,
+				   u8 sta_id)
+{
+	return -EOPNOTSUPP;
 }
 
 static int iwl4965_clear_sta_key_info(struct iwl_priv *priv, u8 sta_id)
@@ -1447,6 +1469,46 @@ static int iwl4965_clear_sta_key_info(struct iwl_priv *priv, u8 sta_id)
 	return 0;
 }
 
+static int iwl4965_set_dynamic_key(struct iwl_priv *priv,
+				struct ieee80211_key_conf *key, u8 sta_id)
+{
+	int ret;
+
+	switch (key->alg) {
+	case ALG_CCMP:
+		ret = iwl4965_set_ccmp_dynamic_key_info(priv, key, sta_id);
+		break;
+	case ALG_TKIP:
+		ret = iwl4965_set_tkip_dynamic_key_info(priv, key, sta_id);
+		break;
+	case ALG_WEP:
+		ret = -EOPNOTSUPP;
+		break;
+	default:
+		IWL_ERROR("Unknown alg: %s alg = %d\n", __func__, key->alg);
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+static int iwl4965_remove_static_key(struct iwl_priv *priv)
+{
+	int ret = -EOPNOTSUPP;
+
+	return ret;
+}
+
+static int iwl4965_set_static_key(struct iwl_priv *priv,
+				struct ieee80211_key_conf *key)
+{
+	if (key->alg == ALG_WEP)
+		return -EOPNOTSUPP;
+
+	IWL_ERROR("Static key invalid: alg %d\n", key->alg);
+	return -EINVAL;
+}
+
 static void iwl4965_clear_free_frames(struct iwl_priv *priv)
 {
 	struct list_head *element;
@@ -2265,17 +2327,6 @@ static int iwl4965_scan_initiate(struct iwl_priv *priv)
 	return 0;
 }
 
-static int iwl4965_set_rxon_hwcrypto(struct iwl_priv *priv, int hw_decrypt)
-{
-	struct iwl4965_rxon_cmd *rxon = &priv->staging_rxon;
-
-	if (hw_decrypt)
-		rxon->filter_flags &= ~RXON_FILTER_DIS_DECRYPT_MSK;
-	else
-		rxon->filter_flags |= RXON_FILTER_DIS_DECRYPT_MSK;
-
-	return 0;
-}
 
 static void iwl4965_set_flags_for_phymode(struct iwl_priv *priv,
 					  enum ieee80211_band band)
@@ -7566,8 +7617,9 @@ static int iwl4965_mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 {
 	struct iwl_priv *priv = hw->priv;
 	DECLARE_MAC_BUF(mac);
-	int rc = 0;
-	u8 sta_id;
+	int ret = 0;
+	u8 sta_id = IWL_INVALID_STATION;
+	u8 static_key;
 
 	IWL_DEBUG_MAC80211("enter\n");
 
@@ -7580,44 +7632,45 @@ static int iwl4965_mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 		/* only support pairwise keys */
 		return -EOPNOTSUPP;
 
-	sta_id = iwl4965_hw_find_station(priv, addr);
-	if (sta_id == IWL_INVALID_STATION) {
-		IWL_DEBUG_MAC80211("leave - %s not in station map.\n",
-				   print_mac(mac, addr));
-		return -EINVAL;
-	}
+	/* FIXME: need to differenciate between static and dynamic key
+	 * in the level of mac80211 */
+	static_key = !iwl4965_is_associated(priv);
 
-	mutex_lock(&priv->mutex);
+	if (!static_key) {
+		sta_id = iwl4965_hw_find_station(priv, addr);
+		if (sta_id == IWL_INVALID_STATION) {
+			IWL_DEBUG_MAC80211("leave - %s not in station map.\n",
+					   print_mac(mac, addr));
+			return -EINVAL;
+		}
+	}
 
 	iwl4965_scan_cancel_timeout(priv, 100);
 
 	switch (cmd) {
-	case  SET_KEY:
-		rc = iwl4965_update_sta_key_info(priv, key, sta_id);
-		if (!rc) {
-			iwl4965_set_rxon_hwcrypto(priv, 1);
-			iwl4965_commit_rxon(priv);
-			key->hw_key_idx = sta_id;
-			IWL_DEBUG_MAC80211("set_key success, using hwcrypto\n");
-			key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
-		}
+	case SET_KEY:
+		if (static_key)
+			ret = iwl4965_set_static_key(priv, key);
+		else
+			ret = iwl4965_set_dynamic_key(priv, key, sta_id);
+
+		IWL_DEBUG_MAC80211("enable hwcrypto key\n");
 		break;
 	case DISABLE_KEY:
-		rc = iwl4965_clear_sta_key_info(priv, sta_id);
-		if (!rc) {
-			iwl4965_set_rxon_hwcrypto(priv, 0);
-			iwl4965_commit_rxon(priv);
-			IWL_DEBUG_MAC80211("disable hwcrypto key\n");
-		}
+		if (static_key)
+			ret = iwl4965_remove_static_key(priv);
+		else
+			ret = iwl4965_clear_sta_key_info(priv, sta_id);
+
+		IWL_DEBUG_MAC80211("disable hwcrypto key\n");
 		break;
 	default:
-		rc = -EINVAL;
+		ret = -EINVAL;
 	}
 
 	IWL_DEBUG_MAC80211("leave\n");
-	mutex_unlock(&priv->mutex);
 
-	return rc;
+	return ret;
 }
 
 static int iwl4965_mac_conf_tx(struct ieee80211_hw *hw, int queue,
-- 
1.5.3.4

[PATCH 4/5] iwlwifi-2.6: enables HW TKIP security

[Reinette Chatre]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This patch add support for TKIP in HW.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl4965-base.c |   63 +++++++++++++++++++++++----
 1 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index d47941d..d9df2b0 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -1449,7 +1449,58 @@ static int iwl4965_set_tkip_dynamic_key_info(struct iwl_priv *priv,
 				   struct ieee80211_key_conf *keyconf,
 				   u8 sta_id)
 {
-	return -EOPNOTSUPP;
+	unsigned long flags;
+	__le16 key_flags = 0;
+	int i, ret = 0;
+
+	keyconf->flags |= IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY;
+	keyconf->flags |= IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY;
+	keyconf->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+	keyconf->flags |= IEEE80211_KEY_FLAG_GENERATE_MMIC;
+	keyconf->hw_key_idx = sta_id;
+
+	key_flags |= (STA_KEY_FLG_TKIP | STA_KEY_FLG_MAP_KEY_MSK);
+	key_flags |= cpu_to_le16(keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
+	key_flags &= ~STA_KEY_FLG_INVALID;
+
+	if (sta_id == priv->hw_setting.bcast_sta_id)
+		key_flags |= STA_KEY_MULTICAST_MSK;
+
+	spin_lock_irqsave(&priv->sta_lock, flags);
+
+	priv->stations[sta_id].keyinfo.alg = keyconf->alg;
+	priv->stations[sta_id].keyinfo.keylen = 16;
+
+	/* This copy is acutally not needed: we get the key with each TX */
+	memcpy(priv->stations[sta_id].keyinfo.key, keyconf->key, 16);
+
+	memcpy(priv->stations[sta_id].sta.key.key, keyconf->key, 16);
+
+	priv->stations[sta_id].sta.key.key_offset = (sta_id%8);/*FIXME!!!*/
+	priv->stations[sta_id].sta.key.key_flags = key_flags;
+	if (keyconf->flags & IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID) {
+		priv->stations[sta_id].sta.key.tkip_rx_tsc_byte2 =
+				(u8) keyconf->tkip_iv32;
+		for (i = 0; i < 5; i++)
+			priv->stations[sta_id].sta.key.tkip_rx_ttak[i] =
+				cpu_to_le16(keyconf->tkip_p1k[i]);
+	} else {
+		priv->stations[sta_id].sta.key.tkip_rx_tsc_byte2 = 0xff;
+	}
+
+	priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
+	priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
+
+	/* Don't send an incomplete key: a key w/o valid TTAK */
+	if (keyconf->flags & IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID) {
+		IWL_DEBUG_INFO("hwcrypto: modify ucode station key info\n");
+		ret = iwl4965_send_add_station(priv,
+				&priv->stations[sta_id].sta, CMD_ASYNC);
+	}
+
+	spin_unlock_irqrestore(&priv->sta_lock, flags);
+
+	return ret;
 }
 
 static int iwl4965_clear_sta_key_info(struct iwl_priv *priv, u8 sta_id)
@@ -2484,15 +2535,9 @@ static void iwl4965_build_tx_cmd_hwcrypto(struct iwl_priv *priv,
 		break;
 
 	case ALG_TKIP:
-#if 0
 		cmd->cmd.tx.sec_ctl = TX_CMD_SEC_TKIP;
-
-		if (last_frag)
-			memcpy(cmd->cmd.tx.tkip_mic.byte, skb_frag->tail - 8,
-			       8);
-		else
-			memset(cmd->cmd.tx.tkip_mic.byte, 0, 8);
-#endif
+		memcpy(cmd->cmd.tx.key, ctl->tkip_key, keyinfo->keylen);
+		IWL_DEBUG_TX("tx_cmd with tkip hwcrypto\n");
 		break;
 
 	case ALG_WEP:
-- 
1.5.3.4

[PATCH 5/5] iwlwifi-2.6: RX status translation to old scheme

[Reinette Chatre]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This patch adds translation for the RX status of an incoming packet.
The incoming status has to be translated to the old scheme in order to know
if the decryption has been done, MIC failure has occured, TTAK is valid etc...
This translation is mandatory for all RX packets when using 5300 and for
all HT packets using 4965.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-4965-commands.h |    9 +++
 drivers/net/wireless/iwlwifi/iwl-4965.c          |   66 ++++++++++++++++++++++
 drivers/net/wireless/iwlwifi/iwl4965-base.c      |    6 ++
 3 files changed, 81 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
index 085d813..5107100 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
@@ -890,6 +890,10 @@ struct iwl4965_rx_frame_hdr {
 #define RX_RES_STATUS_SEC_TYPE_WEP	(0x1 << 8)
 #define RX_RES_STATUS_SEC_TYPE_CCMP	(0x2 << 8)
 #define RX_RES_STATUS_SEC_TYPE_TKIP	(0x3 << 8)
+#define RX_RES_STATUS_SEC_TYPE_ERR	(0x7 << 8)
+
+#define RX_RES_STATUS_STATION_FOUND	(1<<6)
+#define RX_RES_STATUS_NO_STATION_INFO_MISMATCH	(1<<7)
 
 #define RX_RES_STATUS_DECRYPT_TYPE_MSK	(0x3 << 11)
 #define RX_RES_STATUS_NOT_DECRYPT	(0x0 << 11)
@@ -897,6 +901,11 @@ struct iwl4965_rx_frame_hdr {
 #define RX_RES_STATUS_BAD_ICV_MIC	(0x1 << 11)
 #define RX_RES_STATUS_BAD_KEY_TTAK	(0x2 << 11)
 
+#define RX_MPDU_RES_STATUS_ICV_OK	(0x20)
+#define RX_MPDU_RES_STATUS_MIC_OK	(0x40)
+#define RX_MPDU_RES_STATUS_TTAK_OK	(1 << 7)
+#define RX_MPDU_RES_STATUS_DEC_DONE_MSK	(0x800)
+
 struct iwl4965_rx_frame_end {
 	__le32 status;
 	__le64 timestamp;
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index b2ea4d4..1030f17 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -3345,6 +3345,65 @@ static void iwl_update_rx_stats(struct iwl_priv *priv, u16 fc, u16 len)
 	priv->rx_stats[idx].bytes += len;
 }
 
+static u32 iwl4965_translate_rx_status(u32 decrypt_in)
+{
+	u32 decrypt_out = 0;
+
+	if ((decrypt_in & RX_RES_STATUS_STATION_FOUND) ==
+					RX_RES_STATUS_STATION_FOUND)
+		decrypt_out |= (RX_RES_STATUS_STATION_FOUND |
+				RX_RES_STATUS_NO_STATION_INFO_MISMATCH);
+
+	decrypt_out |= (decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK);
+
+	/* packet was not encrypted */
+	if ((decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK) ==
+					RX_RES_STATUS_SEC_TYPE_NONE)
+		return decrypt_out;
+
+	/* packet was encrypted with unknown alg */
+	if ((decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK) ==
+					RX_RES_STATUS_SEC_TYPE_ERR)
+		return decrypt_out;
+
+	/* decryption was not done in HW */
+	if ((decrypt_in & RX_MPDU_RES_STATUS_DEC_DONE_MSK) !=
+					RX_MPDU_RES_STATUS_DEC_DONE_MSK)
+		return decrypt_out;
+
+	switch (decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK) {
+
+	case RX_RES_STATUS_SEC_TYPE_CCMP:
+		/* alg is CCM: check MIC only */
+		if (!(decrypt_in & RX_MPDU_RES_STATUS_MIC_OK))
+			/* Bad MIC */
+			decrypt_out |= RX_RES_STATUS_BAD_ICV_MIC;
+		else
+			decrypt_out |= RX_RES_STATUS_DECRYPT_OK;
+
+		break;
+
+	case RX_RES_STATUS_SEC_TYPE_TKIP:
+		if (!(decrypt_in & RX_MPDU_RES_STATUS_TTAK_OK)) {
+			/* Bad TTAK */
+			decrypt_out |= RX_RES_STATUS_BAD_KEY_TTAK;
+			break;
+		}
+		/* fall through if TTAK OK */
+	default:
+		if (!(decrypt_in & RX_MPDU_RES_STATUS_ICV_OK))
+			decrypt_out |= RX_RES_STATUS_BAD_ICV_MIC;
+		else
+			decrypt_out |= RX_RES_STATUS_DECRYPT_OK;
+		break;
+	};
+
+	IWL_DEBUG_RX("decrypt_in:0x%x  decrypt_out = 0x%x\n",
+					decrypt_in, decrypt_out);
+
+	return decrypt_out;
+}
+
 static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
 				       int include_phy,
 				       struct iwl4965_rx_mem_buffer *rxb,
@@ -3358,6 +3417,7 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
 	__le32 *rx_end;
 	unsigned int skblen;
 	u32 ampdu_status;
+	u32 ampdu_status_legacy;
 
 	if (!include_phy && priv->last_phy_res[0])
 		rx_start = (struct iwl4965_rx_phy_res *)&priv->last_phy_res[1];
@@ -3394,6 +3454,12 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
 	ampdu_status = le32_to_cpu(*rx_end);
 	skblen = ((u8 *) rx_end - (u8 *) & pkt->u.raw[0]) + sizeof(u32);
 
+	if (!include_phy) {
+		/* New status scheme, need to translate */
+		ampdu_status_legacy = ampdu_status;
+		ampdu_status = iwl4965_translate_rx_status(ampdu_status);
+	}
+
 	/* start from MAC */
 	skb_reserve(rxb->skb, (void *)hdr - (void *)pkt);
 	skb_put(rxb->skb, len);	/* end where data ends */
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index d9df2b0..5bd98f5 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -3044,6 +3044,12 @@ void iwl4965_set_decrypted_flag(struct iwl_priv *priv, struct sk_buff *skb,
 	IWL_DEBUG_RX("decrypt_res:0x%x\n", decrypt_res);
 	switch (decrypt_res & RX_RES_STATUS_SEC_TYPE_MSK) {
 	case RX_RES_STATUS_SEC_TYPE_TKIP:
+		/* The uCode has got a bad phase 1 Key, pushes the packet.
+		 * Decryption will be done in SW. */
+		if ((decrypt_res & RX_RES_STATUS_DECRYPT_TYPE_MSK) ==
+		    RX_RES_STATUS_BAD_KEY_TTAK)
+			break;
+
 		if ((decrypt_res & RX_RES_STATUS_DECRYPT_TYPE_MSK) ==
 		    RX_RES_STATUS_BAD_ICV_MIC)
 			stats->flag |= RX_FLAG_MMIC_ERROR;
-- 
1.5.3.4

Re: [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]


On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> 
> This patch makes mac80211 able to send a phase1 key for TKIP decryption.
> This is needed for drivers that don't do the rekeying by themselves
> (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
> decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.

> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -590,12 +590,20 @@ enum ieee80211_key_alg {
>   * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
>   *	the driver for a TKIP key if it requires a phase2 TX key generation
>   *	in SW. The key will be attached to each packet.
> + * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
> + *	for a TKIP key if it requires phase 1 key generation in software.
> + *	The phase 1 key will be sent in the same context as Rx.
> + * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
> + *	IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
> + *	fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.

This really breaks the set_key() model of having always one set_key()
call to add the key and another one to remove it again.

I think it would be much more appropriate to handle this in the driver
by exporting an appropriate phase1 mixing function that takes the
key_conf, iv16, RX vs. TX flag, and for RX the queue number as
arguments. The RX vs. TX flag could be used by the b43 driver since that
hardware can actually derive the phase2 key by itself.

I think for advanced features like crypto hardware acceleration or
similar we should deviate from the "push" model mac80211 has for most
things (and which you also implemented here) so we don't end up creating
special flags for all possible different hardware. A "pull" model is
much more scalable here.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Tomas Winkler]

On Sat, Mar 15, 2008 at 9:11 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
>  > From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>  >
>  > This patch makes mac80211 able to send a phase1 key for TKIP decryption.
>  > This is needed for drivers that don't do the rekeying by themselves
>  > (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
>  > decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.
>
>
> > --- a/include/net/mac80211.h
>  > +++ b/include/net/mac80211.h
>  > @@ -590,12 +590,20 @@ enum ieee80211_key_alg {
>  >   * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
>  >   *   the driver for a TKIP key if it requires a phase2 TX key generation
>  >   *   in SW. The key will be attached to each packet.
>  > + * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
>  > + *   for a TKIP key if it requires phase 1 key generation in software.
>  > + *   The phase 1 key will be sent in the same context as Rx.
>  > + * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
>  > + *   IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
>  > + *   fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
>
>  This really breaks the set_key() model of having always one set_key()
>  call to add the key and another one to remove it again.
>
>  I think it would be much more appropriate to handle this in the driver
>  by exporting an appropriate phase1 mixing function that takes the
>  key_conf, iv16, RX vs. TX flag, and for RX the queue number as
>  arguments. The RX vs. TX flag could be used by the b43 driver since that
>  hardware can actually derive the phase2 key by itself.

iwlwifi firmware also derive phase2 in RX path by itself since this is
not really possible to do in host level. However in case of non
matching iv32 such as wraparound it passes packet up unencrypted.  And
there are some more esoteric cases when packet when SW decryption is
more efficient such as very short packets. Therefore HW decryption
have to be always backed up by SW one.
Wraparound of Iv32 is reliable only if decryption of a the packet that
triggers it is correct. If this is not done and phase1 is advanced by
mistake it  breaks traffic till the next wraparound actually it will
effectively cause  disconnection. Your suggestion will requires to
move also decryption into driver levelm not only phase1 generation. So
it's rather no go solution


>  I think for advanced features like crypto hardware acceleration or
>  similar we should deviate from the "push" model mac80211 has for most
>  things (and which you also implemented here) so we don't end up creating
>  special flags for all possible different hardware. A "pull" model is
>  much more scalable here.

I agree in general but in this specific case this will cause much more
data movement than few flags.

Thanks
Tomas

>  johannes
>
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
>  Ipw3945-devel mailing list
>  Ipw3945-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
>

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]


> iwlwifi firmware also derive phase2 in RX path by itself since this is
> not really possible to do in host level. 

Right. I just wonder why then it needs the host to derive the phase 2
key for TX, that seems pretty strange. Seems to me a bit like a "what
can we do" design decision rather than "what makes sense".

> However in case of non
> matching iv32 such as wraparound it passes packet up unencrypted.  

That makes sense.

> Therefore HW decryption
> have to be always backed up by SW one.

Obviously, yes.

> Wraparound of Iv32 is reliable only if decryption of a the packet that
> triggers it is correct. If this is not done and phase1 is advanced by
> mistake it  breaks traffic till the next wraparound actually it will
> effectively cause  disconnection.

Good point. But let's not overload set_key() for it this way. This way,
the driver needs to look up the key etc. and the semantics get quite
mangled up. Also, your approach doesn't work for Broadcom hardware that
only needs phase 1 keys for both RX and TX.

How about instead we add a new "update_tkip_key()" callback that takes
exactly the required parameters? It should also give the
hardware-key-index so that the driver has less work to do.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Tomas Winkler]

On Mon, Mar 17, 2008 at 1:39 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  > iwlwifi firmware also derive phase2 in RX path by itself since this is
>  > not really possible to do in host level.
>
>  Right. I just wonder why then it needs the host to derive the phase 2
>  key for TX, that seems pretty strange. Seems to me a bit like a "what
>  can we do" design decision rather than "what makes sense".

The reason is solely engineering. It can be done safely in host so
it's done there.

>  > However in case of non
>  > matching iv32 such as wraparound it passes packet up unencrypted.
>
>  That makes sense.
>
>
>  > Therefore HW decryption
>  > have to be always backed up by SW one.
>
>  Obviously, yes.
>
>
>  > Wraparound of Iv32 is reliable only if decryption of a the packet that
>  > triggers it is correct. If this is not done and phase1 is advanced by
>  > mistake it  breaks traffic till the next wraparound actually it will
>  > effectively cause  disconnection.
>
>  Good point. But let's not overload set_key() for it this way. This way,
>  the driver needs to look up the key etc. and the semantics get quite
>  mangled up. Also, your approach doesn't work for Broadcom hardware that
>  only needs phase 1 keys for both RX and TX.

Can you elaborate why it doesn't cover bcom case?

>  How about instead we add a new "update_tkip_key()" callback that takes
>  exactly the required parameters? It should also give the
>  hardware-key-index so that the driver has less work to do.

It's viable but I actually prefer not opening too many interfaces.
Please give me some more detailed sketch how do you see that and we
sure get to some acceptable solution.

Thanks
Tomas

>  johannes
>

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]


> >  Good point. But let's not overload set_key() for it this way. This way,
> >  the driver needs to look up the key etc. and the semantics get quite
> >  mangled up. Also, your approach doesn't work for Broadcom hardware that
> >  only needs phase 1 keys for both RX and TX.
> 
> Can you elaborate why it doesn't cover bcom case?

I don't quite understand the phase 1 key derivation and why it is done
for each DMA queue, but I think this is not too important as
non-matching will just be done in software. However, bcom firmware wants
to have just the phase 1 key, and as far as I can tell the driver can't,
even with your patches, obtain a phase 1 key for TX.

> >  How about instead we add a new "update_tkip_key()" callback that takes
> >  exactly the required parameters? It should also give the
> >  hardware-key-index so that the driver has less work to do.
> 
> It's viable but I actually prefer not opening too many interfaces.
> Please give me some more detailed sketch how do you see that and we
> sure get to some acceptable solution.

Yes, I would prefer not having that many interfaces as well, but I don't
think shoehorning it into the set_key() callback is a good idea because
 (a) you add fields to the key conf structure that are only used for
     the tkip stuff and only valid in some calls
 (b) the patch breaks the set_key() interface's symmetry

A new callback update_tkip_key could look like this:

void update_tkip_phase1key(hw, keyconf, iv32, p1key)

The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the
new callback would be invoked right from where the phase1 key is
calculated.

I'm not exactly sure whether one needs a phase1 key for RX and one for
TX right now, but if so a direction flag should be added?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Tomas Winkler]

T24gTW9uLCBNYXIgMTcsIDIwMDggYXQgMzoxMyBQTSwgSm9oYW5uZXMgQmVyZwo8am9oYW5uZXNA
c2lwc29sdXRpb25zLm5ldD4gd3JvdGU6Cj4KPiAgPiA+ICBHb29kIHBvaW50LiBCdXQgbGV0J3Mg
bm90IG92ZXJsb2FkIHNldF9rZXkoKSBmb3IgaXQgdGhpcyB3YXkuIFRoaXMgd2F5LAo+ICA+ID4g
IHRoZSBkcml2ZXIgbmVlZHMgdG8gbG9vayB1cCB0aGUga2V5IGV0Yy4gYW5kIHRoZSBzZW1hbnRp
Y3MgZ2V0IHF1aXRlCj4gID4gPiAgbWFuZ2xlZCB1cC4gQWxzbywgeW91ciBhcHByb2FjaCBkb2Vz
bid0IHdvcmsgZm9yIEJyb2FkY29tIGhhcmR3YXJlIHRoYXQKPiAgPiA+ICBvbmx5IG5lZWRzIHBo
YXNlIDEga2V5cyBmb3IgYm90aCBSWCBhbmQgVFguCj4gID4KPiAgPiBDYW4geW91IGVsYWJvcmF0
ZSB3aHkgaXQgZG9lc24ndCBjb3ZlciBiY29tIGNhc2U/Cj4KPiAgSSBkb24ndCBxdWl0ZSB1bmRl
cnN0YW5kIHRoZSBwaGFzZSAxIGtleSBkZXJpdmF0aW9uIGFuZCB3aHkgaXQgaXMgZG9uZQo+ICBm
b3IgZWFjaCBETUEgcXVldWUsClRoaXMgaXMgb25seSBpbiBSWCBzaWRlLiBFYWNoIEFDIChhY2Nl
c3MgY2F0ZWdvcnkpIHF1ZXVlIHRyYW5zbWl0IGluCml0J3Mgb3duIHJhdGUuIEZvciBleGFtcGxl
IFZPIHRyYXNtaXR0cyBtb3JlIHBhY2tldHMgdGhlbiBCRS4gU28geW91Cm1pZ2h0IGdldCBpbnRv
IGNhc2UgaW4gcmVjZWl2ZSBzaXRlIHRoYXQgVk8gcGFja2V0cyBhcmUgYWxyZWFkeSBvbgp3cmFw
YXJvdW5kIHNpZGUgd2hpbGUgQkUgYXJlIHN0aWxsIHVzaW5nICdvbGQnIHBoYXNlMS4KQmVzdCBy
ZW1lZHkgaXMgdG8ga2VlcCBwaGFzZTEgcGVyIGVhY2ggQUMuCgpidXQgSSB0aGluayB0aGlzIGlz
IG5vdCB0b28gaW1wb3J0YW50IGFzCj4gIG5vbi1tYXRjaGluZyB3aWxsIGp1c3QgYmUgZG9uZSBp
biBzb2Z0d2FyZS4KCkNvcnJlY3QsIHRoaXMgc2hvdWxkIGhhcHBlbiBvbmx5IGZvciBzaG9ydCBw
ZXJpb2Qgb2YgdGltZSB0aGF0IHBoMQpkb2Vzbid0IG1hdGNoIGZvciBlYWNoIEFDIHF1ZXVlLgoK
IEhvd2V2ZXIsIGJjb20gZmlybXdhcmUgd2FudHMKPiAgdG8gaGF2ZSBqdXN0IHRoZSBwaGFzZSAx
IGtleSwgYW5kIGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBkcml2ZXIgY2FuJ3QsCj4gIGV2ZW4g
d2l0aCB5b3VyIHBhdGNoZXMsIG9idGFpbiBhIHBoYXNlIDEga2V5IGZvciBUWC4KCk5vdCBzdXJl
IHRoZXNlIGNhc2VzIGFyZSBzeW1tZXRyaWMuIFlvdSBoYXZlIHRvIGhhdmUgcGhhc2UxIHJlYWR5
IGluCkhXIGJlZm9yZSB5b3UgdHJhbnNtaXQgdGhlIHBhY2tldApQaGFzZTEgbmVlZCB0byBiZSBh
ZGhlcmVkIHRvIGEgcGFja2V0IHRoYXQgY2F1c2VzIHdyYXBhcm91bmQgdW5saWtlIFJYCnRoYXQg
eW91IGNhbiBmYWxsIGJhY2sgdG8gU1cgZGVjcnlwdGlvbgpJbiBUWCB0aGVyZSBpcyBubyB3YXkg
YmFjay4KCj4KPiAgPiA+ICBIb3cgYWJvdXQgaW5zdGVhZCB3ZSBhZGQgYSBuZXcgInVwZGF0ZV90
a2lwX2tleSgpIiBjYWxsYmFjayB0aGF0IHRha2VzCj4gID4gPiAgZXhhY3RseSB0aGUgcmVxdWly
ZWQgcGFyYW1ldGVycz8gSXQgc2hvdWxkIGFsc28gZ2l2ZSB0aGUKPiAgPiA+ICBoYXJkd2FyZS1r
ZXktaW5kZXggc28gdGhhdCB0aGUgZHJpdmVyIGhhcyBsZXNzIHdvcmsgdG8gZG8uCj4gID4KPiAg
PiBJdCdzIHZpYWJsZSBidXQgSSBhY3R1YWxseSBwcmVmZXIgbm90IG9wZW5pbmcgdG9vIG1hbnkg
aW50ZXJmYWNlcy4KPiAgPiBQbGVhc2UgZ2l2ZSBtZSBzb21lIG1vcmUgZGV0YWlsZWQgc2tldGNo
IGhvdyBkbyB5b3Ugc2VlIHRoYXQgYW5kIHdlCj4gID4gc3VyZSBnZXQgdG8gc29tZSBhY2NlcHRh
YmxlIHNvbHV0aW9uLgo+Cj4gIFllcywgSSB3b3VsZCBwcmVmZXIgbm90IGhhdmluZyB0aGF0IG1h
bnkgaW50ZXJmYWNlcyBhcyB3ZWxsLCBidXQgSSBkb24ndAo+ICB0aGluayBzaG9laG9ybmluZyBp
dCBpbnRvIHRoZSBzZXRfa2V5KCkgY2FsbGJhY2sgaXMgYSBnb29kIGlkZWEgYmVjYXVzZQo+ICAg
KGEpIHlvdSBhZGQgZmllbGRzIHRvIHRoZSBrZXkgY29uZiBzdHJ1Y3R1cmUgdGhhdCBhcmUgb25s
eSB1c2VkIGZvcgo+ICAgICAgdGhlIHRraXAgc3R1ZmYgYW5kIG9ubHkgdmFsaWQgaW4gc29tZSBj
YWxscwo+ICAgKGIpIHRoZSBwYXRjaCBicmVha3MgdGhlIHNldF9rZXkoKSBpbnRlcmZhY2UncyBz
eW1tZXRyeQo+Cj4gIEEgbmV3IGNhbGxiYWNrIHVwZGF0ZV90a2lwX2tleSBjb3VsZCBsb29rIGxp
a2UgdGhpczoKPgo+ICB2b2lkIHVwZGF0ZV90a2lwX3BoYXNlMWtleShodywga2V5Y29uZiwgaXYz
MiwgcDFrZXkpCgpXaGF0IGFib3V0CmVudW0gdGtpcF91cGRhdGVfZmxhZ3MgewogICBUS0lQX1BI
MV9UWF9LRVkKICAgVEtJUF9QSDFfUlhfS0VZCiAgIFRLSVBfUEgyX1RYX0tFWQogICBUS0lQX1BI
Ml9SWF9LRVkgLS0gYWN0dWFsbHkgbm8gbmVlZCBmb3IgYW55IGRyaXZlci4KfQogIHVwZGF0ZV90
a2lwX2tleShodywga2V5Y29uZiAsIGl2MzIsICBmbGFnLCBrZXkpCgpCdXQgSSdtIG5vdCBzdXJl
IGFib3V0IHRoaXMuLi4gc2VlIGFib3ZlL2JlbG92ZQoKPiAgVGhlIO+7v0lFRUU4MDIxMV9LRVlf
RkxBR19US0lQX1BIQVNFMV9WQUxJRCBmbGFnIHdvdWxkIGdvIGF3YXksIGFuZCB0aGUKPiAgbmV3
IGNhbGxiYWNrIHdvdWxkIGJlIGludm9rZWQgcmlnaHQgZnJvbSB3aGVyZSB0aGUgcGhhc2UxIGtl
eSBpcwo+ICBjYWxjdWxhdGVkLgoKU3VyZSBhZ2FpbiBJJ20gbm90IHN1cmUgdGhpcyBpcyBzeW1t
ZXRyaWMgLSBGb3IgVFggaXQgd291bGQgYmUgc2FmZXIKdG8gZG8gcHVsbCBtb2RlIG90aGVyd2lz
ZSBpdCBjYW4gZ2V0IG91dCBvZiBzeW5jLgoKPiAgSSdtIG5vdCBleGFjdGx5IHN1cmUgd2hldGhl
ciBvbmUgbmVlZHMgYSBwaGFzZTEga2V5IGZvciBSWCBhbmQgb25lIGZvcgo+ICBUWCByaWdodCBu
b3csIGJ1dCBpZiBzbyBhIGRpcmVjdGlvbiBmbGFnIHNob3VsZCBiZSBhZGRlZD8KClBoYXNlMSBm
b3IgVFggYW5kIFJYIGFyZSBub3QgdGhlIHNhbWUsIGFnYWluIGJlY2F1c2Ugb2YgdGhlIHNpbXBs
ZQpyZWFzb25lIHRoYXQgbnVtYmVyIG9mIHRyYW5zbWl0dGVkIGFuZCByZWNlaXZlZCBwYWNrZXQg
aXMgbm90IHRoZQpzYW1lLgoKPiAgam9oYW5uZXMKPgo=

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]


> This is only in RX side. Each AC (access category) queue transmit in
> it's own rate. For example VO trasmitts more packets then BE. So you
> might get into case in receive site that VO packets are already on
> wraparound side while BE are still using 'old' phase1.
> Best remedy is to keep phase1 per each AC.
> 
> >  but I think this is not too important as
> >  non-matching will just be done in software.
> 
> Correct, this should happen only for short period of time that ph1
> doesn't match for each AC queue.

Right, in software we can keep a phase1 per AC but we don't need to in
hardware since that's just the optimisation.

> >  However, bcom firmware wants
> >  to have just the phase 1 key, and as far as I can tell the driver can't,
> >  even with your patches, obtain a phase 1 key for TX.
> 
> Not sure these cases are symmetric. You have to have phase1 ready in
> HW before you transmit the packet
> Phase1 need to be adhered to a packet that causes wraparound unlike RX
> that you can fall back to SW decryption
> In TX there is no way back.

Good point. So then for Broadcom we actually need to update phase1 in
hardware when it changes on TX and not bother with RX at all, we'll fall
back to software in that case.

> >  > >  How about instead we add a new "update_tkip_key()" callback that takes
> >  > >  exactly the required parameters? It should also give the
> >  > >  hardware-key-index so that the driver has less work to do.
> >  >
> >  > It's viable but I actually prefer not opening too many interfaces.
> >  > Please give me some more detailed sketch how do you see that and we
> >  > sure get to some acceptable solution.
> >
> >  Yes, I would prefer not having that many interfaces as well, but I don't
> >  think shoehorning it into the set_key() callback is a good idea because
> >   (a) you add fields to the key conf structure that are only used for
> >      the tkip stuff and only valid in some calls
> >   (b) the patch breaks the set_key() interface's symmetry
> >
> >  A new callback update_tkip_key could look like this:
> >
> >  void update_tkip_phase1key(hw, keyconf, iv32, p1key)
> 
> What about
> enum tkip_update_flags {
>    TKIP_PH1_TX_KEY
>    TKIP_PH1_RX_KEY
>    TKIP_PH2_TX_KEY
>    TKIP_PH2_RX_KEY -- actually no need for any driver.
> }
>   update_tkip_key(hw, keyconf , iv32,  flag, key)
> 
> But I'm not sure about this... see above/belove
> 
> >  The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the
> >  new callback would be invoked right from where the phase1 key is
> >  calculated.
> 
> Sure again I'm not sure this is symmetric - For TX it would be safer
> to do pull mode otherwise it can get out of sync.

True. Hence, since phase2rx is not really useful, we don't actually need
any sort of update flags when we do the TX keys in pull mode, which I
prefer anyway.

> >  I'm not exactly sure whether one needs a phase1 key for RX and one for
> >  TX right now, but if so a direction flag should be added?
> 
> Phase1 for TX and RX are not the same, again because of the simple
> reasone that number of transmitted and received packet is not the
> same.

Hm, right. But if we go for pull mode for TX, we only need to have push
mode for the phase1 rx key when that changes, no?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Tomas Winkler]

T24gTW9uLCBNYXIgMTcsIDIwMDggYXQgNTowNCBQTSwgSm9oYW5uZXMgQmVyZwo8am9oYW5uZXNA
c2lwc29sdXRpb25zLm5ldD4gd3JvdGU6Cj4KPiAgPiBUaGlzIGlzIG9ubHkgaW4gUlggc2lkZS4g
RWFjaCBBQyAoYWNjZXNzIGNhdGVnb3J5KSBxdWV1ZSB0cmFuc21pdCBpbgo+ICA+IGl0J3Mgb3du
IHJhdGUuIEZvciBleGFtcGxlIFZPIHRyYXNtaXR0cyBtb3JlIHBhY2tldHMgdGhlbiBCRS4gU28g
eW91Cj4gID4gbWlnaHQgZ2V0IGludG8gY2FzZSBpbiByZWNlaXZlIHNpdGUgdGhhdCBWTyBwYWNr
ZXRzIGFyZSBhbHJlYWR5IG9uCj4gID4gd3JhcGFyb3VuZCBzaWRlIHdoaWxlIEJFIGFyZSBzdGls
bCB1c2luZyAnb2xkJyBwaGFzZTEuCj4gID4gQmVzdCByZW1lZHkgaXMgdG8ga2VlcCBwaGFzZTEg
cGVyIGVhY2ggQUMuCj4gID4KPiAgPiA+ICBidXQgSSB0aGluayB0aGlzIGlzIG5vdCB0b28gaW1w
b3J0YW50IGFzCj4gID4gPiAgbm9uLW1hdGNoaW5nIHdpbGwganVzdCBiZSBkb25lIGluIHNvZnR3
YXJlLgo+ICA+Cj4gID4gQ29ycmVjdCwgdGhpcyBzaG91bGQgaGFwcGVuIG9ubHkgZm9yIHNob3J0
IHBlcmlvZCBvZiB0aW1lIHRoYXQgcGgxCj4gID4gZG9lc24ndCBtYXRjaCBmb3IgZWFjaCBBQyBx
dWV1ZS4KPgo+ICBSaWdodCwgaW4gc29mdHdhcmUgd2UgY2FuIGtlZXAgYSBwaGFzZTEgcGVyIEFD
IGJ1dCB3ZSBkb24ndCBuZWVkIHRvIGluCj4gIGhhcmR3YXJlIHNpbmNlIHRoYXQncyBqdXN0IHRo
ZSBvcHRpbWlzYXRpb24uCgpDb3JyZWN0LCBJJ20ganVzdCBub3Qgc3VyZSBob3cgaXQncyBkb25l
IGZvciBiY29tIGNhcmRzLgo+Cj4gID4gPiAgSG93ZXZlciwgYmNvbSBmaXJtd2FyZSB3YW50cwo+
ICA+ID4gIHRvIGhhdmUganVzdCB0aGUgcGhhc2UgMSBrZXksIGFuZCBhcyBmYXIgYXMgSSBjYW4g
dGVsbCB0aGUgZHJpdmVyIGNhbid0LAo+ICA+ID4gIGV2ZW4gd2l0aCB5b3VyIHBhdGNoZXMsIG9i
dGFpbiBhIHBoYXNlIDEga2V5IGZvciBUWC4KPiAgPgo+ICA+IE5vdCBzdXJlIHRoZXNlIGNhc2Vz
IGFyZSBzeW1tZXRyaWMuIFlvdSBoYXZlIHRvIGhhdmUgcGhhc2UxIHJlYWR5IGluCj4gID4gSFcg
YmVmb3JlIHlvdSB0cmFuc21pdCB0aGUgcGFja2V0Cj4gID4gUGhhc2UxIG5lZWQgdG8gYmUgYWRo
ZXJlZCB0byBhIHBhY2tldCB0aGF0IGNhdXNlcyB3cmFwYXJvdW5kIHVubGlrZSBSWAo+ICA+IHRo
YXQgeW91IGNhbiBmYWxsIGJhY2sgdG8gU1cgZGVjcnlwdGlvbgo+ICA+IEluIFRYIHRoZXJlIGlz
IG5vIHdheSBiYWNrLgo+Cj4gIEdvb2QgcG9pbnQuIFNvIHRoZW4gZm9yIEJyb2FkY29tIHdlIGFj
dHVhbGx5IG5lZWQgdG8gdXBkYXRlIHBoYXNlMSBpbgo+ICBoYXJkd2FyZSB3aGVuIGl0IGNoYW5n
ZXMgb24gVFggYW5kIG5vdCBib3RoZXIgd2l0aCBSWCBhdCBhbGwsIHdlJ2xsIGZhbGwKPiAgYmFj
ayB0byBzb2Z0d2FyZSBpbiB0aGF0IGNhc2UuCgpFdmVudHVhbGx5IHlvdSB3YW50IHRvIHVwZGF0
ZSBSWCBwaGFzZTEga2V5IGludG8gSFcgc28geW91IGdldCB5b3VyCkNQVSB1dGlsaXphdGlvbiB3
aGVyZSBpdCBoYXZlIHRvIGJlLCByaWdodD8KCj4KPiAgPiA+ICA+ID4gIEhvdyBhYm91dCBpbnN0
ZWFkIHdlIGFkZCBhIG5ldyAidXBkYXRlX3RraXBfa2V5KCkiIGNhbGxiYWNrIHRoYXQgdGFrZXMK
PiAgPiA+ICA+ID4gIGV4YWN0bHkgdGhlIHJlcXVpcmVkIHBhcmFtZXRlcnM/IEl0IHNob3VsZCBh
bHNvIGdpdmUgdGhlCj4gID4gPiAgPiA+ICBoYXJkd2FyZS1rZXktaW5kZXggc28gdGhhdCB0aGUg
ZHJpdmVyIGhhcyBsZXNzIHdvcmsgdG8gZG8uCj4gID4gPiAgPgo+ICA+ID4gID4gSXQncyB2aWFi
bGUgYnV0IEkgYWN0dWFsbHkgcHJlZmVyIG5vdCBvcGVuaW5nIHRvbyBtYW55IGludGVyZmFjZXMu
Cj4gID4gPiAgPiBQbGVhc2UgZ2l2ZSBtZSBzb21lIG1vcmUgZGV0YWlsZWQgc2tldGNoIGhvdyBk
byB5b3Ugc2VlIHRoYXQgYW5kIHdlCj4gID4gPiAgPiBzdXJlIGdldCB0byBzb21lIGFjY2VwdGFi
bGUgc29sdXRpb24uCj4gID4gPgo+ICA+ID4gIFllcywgSSB3b3VsZCBwcmVmZXIgbm90IGhhdmlu
ZyB0aGF0IG1hbnkgaW50ZXJmYWNlcyBhcyB3ZWxsLCBidXQgSSBkb24ndAo+ICA+ID4gIHRoaW5r
IHNob2Vob3JuaW5nIGl0IGludG8gdGhlIHNldF9rZXkoKSBjYWxsYmFjayBpcyBhIGdvb2QgaWRl
YSBiZWNhdXNlCj4gID4gPiAgIChhKSB5b3UgYWRkIGZpZWxkcyB0byB0aGUga2V5IGNvbmYgc3Ry
dWN0dXJlIHRoYXQgYXJlIG9ubHkgdXNlZCBmb3IKPiAgPiA+ICAgICAgdGhlIHRraXAgc3R1ZmYg
YW5kIG9ubHkgdmFsaWQgaW4gc29tZSBjYWxscwo+ICA+ID4gICAoYikgdGhlIHBhdGNoIGJyZWFr
cyB0aGUgc2V0X2tleSgpIGludGVyZmFjZSdzIHN5bW1ldHJ5Cj4gID4gPgo+ICA+ID4gIEEgbmV3
IGNhbGxiYWNrIHVwZGF0ZV90a2lwX2tleSBjb3VsZCBsb29rIGxpa2UgdGhpczoKPiAgPiA+Cj4g
ID4gPiAgdm9pZCB1cGRhdGVfdGtpcF9waGFzZTFrZXkoaHcsIGtleWNvbmYsIGl2MzIsIHAxa2V5
KQo+ICA+Cj4gID4gV2hhdCBhYm91dAo+ICA+IGVudW0gdGtpcF91cGRhdGVfZmxhZ3Mgewo+ICA+
ICAgIFRLSVBfUEgxX1RYX0tFWQo+ICA+ICAgIFRLSVBfUEgxX1JYX0tFWQo+ICA+ICAgIFRLSVBf
UEgyX1RYX0tFWQo+ICA+ICAgIFRLSVBfUEgyX1JYX0tFWSAtLSBhY3R1YWxseSBubyBuZWVkIGZv
ciBhbnkgZHJpdmVyLgo+ICA+IH0KPiAgPiAgIHVwZGF0ZV90a2lwX2tleShodywga2V5Y29uZiAs
IGl2MzIsICBmbGFnLCBrZXkpCj4gID4KPiAgPiBCdXQgSSdtIG5vdCBzdXJlIGFib3V0IHRoaXMu
Li4gc2VlIGFib3ZlL2JlbG92ZQo+ICA+Cj4gID4gPiAgVGhlIO+7v0lFRUU4MDIxMV9LRVlfRkxB
R19US0lQX1BIQVNFMV9WQUxJRCBmbGFnIHdvdWxkIGdvIGF3YXksIGFuZCB0aGUKPiAgPiA+ICBu
ZXcgY2FsbGJhY2sgd291bGQgYmUgaW52b2tlZCByaWdodCBmcm9tIHdoZXJlIHRoZSBwaGFzZTEg
a2V5IGlzCj4gID4gPiAgY2FsY3VsYXRlZC4KPiAgPgo+ICA+IFN1cmUgYWdhaW4gSSdtIG5vdCBz
dXJlIHRoaXMgaXMgc3ltbWV0cmljIC0gRm9yIFRYIGl0IHdvdWxkIGJlIHNhZmVyCj4gID4gdG8g
ZG8gcHVsbCBtb2RlIG90aGVyd2lzZSBpdCBjYW4gZ2V0IG91dCBvZiBzeW5jLgo+Cj4gIFRydWUu
IEhlbmNlLCBzaW5jZSBwaGFzZTJyeCBpcyBub3QgcmVhbGx5IHVzZWZ1bCwgd2UgZG9uJ3QgYWN0
dWFsbHkgbmVlZAo+ICBhbnkgc29ydCBvZiB1cGRhdGUgZmxhZ3Mgd2hlbiB3ZSBkbyB0aGUgVFgg
a2V5cyBpbiBwdWxsIG1vZGUsIHdoaWNoIEkKPiAgcHJlZmVyIGFueXdheS4KPgo+Cj4gID4gPiAg
SSdtIG5vdCBleGFjdGx5IHN1cmUgd2hldGhlciBvbmUgbmVlZHMgYSBwaGFzZTEga2V5IGZvciBS
WCBhbmQgb25lIGZvcgo+ICA+ID4gIFRYIHJpZ2h0IG5vdywgYnV0IGlmIHNvIGEgZGlyZWN0aW9u
IGZsYWcgc2hvdWxkIGJlIGFkZGVkPwo+ICA+Cj4gID4gUGhhc2UxIGZvciBUWCBhbmQgUlggYXJl
IG5vdCB0aGUgc2FtZSwgYWdhaW4gYmVjYXVzZSBvZiB0aGUgc2ltcGxlCj4gID4gcmVhc29uZSB0
aGF0IG51bWJlciBvZiB0cmFuc21pdHRlZCBhbmQgcmVjZWl2ZWQgcGFja2V0IGlzIG5vdCB0aGUK
PiAgPiBzYW1lLgo+Cj4gIEhtLCByaWdodC4gQnV0IGlmIHdlIGdvIGZvciBwdWxsIG1vZGUgZm9y
IFRYLCB3ZSBvbmx5IG5lZWQgdG8gaGF2ZSBwdXNoCj4gIG1vZGUgZm9yIHRoZSBwaGFzZTEgcngg
a2V5IHdoZW4gdGhhdCBjaGFuZ2VzLCBubz8KCkVtbWFudWVsIGhhcyBwcmVwYXJlZCBwYXRjaGVz
IGZvciBUWCBwdWxsIG1vZGUgIChwaGFzZTIgb25seSBmb3Igbm93KSAuCklmIHRoaXMgT0sgd2lp
dGggSSB3aWxsIHJlc2VuZCB0aGUgd2hvbGUgVEtJUCBzZXJpZXMgd2l0aCB0aGlzIGNoYW5nZSwK
bGVhdmluZyBSWCBpbiBwdWxsIG1vZGUuCldlIGNhbiBkbyBsaXR0bGUgZWZmb3J0IHRvIGFkZCBw
dWxsaW5nIHBoYXNlMSBvbmx5IGJ1dCB3ZSBjYW5ub3QgcmVhbGx5IHRlc3QgaXQuCgpUaGFua3MK
VG9tYXMK

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]


> >  Right, in software we can keep a phase1 per AC but we don't need to in
> >  hardware since that's just the optimisation.
> 
> Correct, I'm just not sure how it's done for bcom cards.

I'm not entirely sure right now either.

> Eventually you want to update RX phase1 key into HW so you get your
> CPU utilization where it have to be, right?

Yeah, you would :) But that's something we're addressing anyway since
iwlwifi needs it too.

> >  > Phase1 for TX and RX are not the same, again because of the simple
> >  > reasone that number of transmitted and received packet is not the
> >  > same.
> >
> >  Hm, right. But if we go for pull mode for TX, we only need to have push
> >  mode for the phase1 rx key when that changes, no?
> 
> Emmanuel has prepared patches for TX pull mode  (phase2 only for now) .
> If this OK wiith I will resend the whole TKIP series with this change,
> leaving RX in pull mode.

You mean "RX in push mode" I think. Could you change that to a new
callback or so then as we discussed?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key

[Tomas Winkler]

>
>  You mean "RX in push mode" I think. Could you change that to a new
>  callback or so then as we discussed?

Yes

>  johannes
>

Re: [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]


On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> 
> This patch makes the mac80211 able to send a ready phase2 key to the low
> level driver for TKIP encryption. Iwlwifi needs to get a phase2 key to
> encrypt TX packets in HW.

> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -287,6 +287,7 @@ struct ieee80211_tx_control {
>  	u8 iv_len;		/* length of the IV field in octets */
>  	u8 queue;		/* hardware queue to use for this frame;
>  				 * 0 = highest, hw->queues-1 = lowest */
> +	u8 tkip_key[16];	/* generated phase2/phase1 key for hw TKIP */

I have to admit that I'm rather uncomfortable with adding this code to
the stack. Not only because that is a rather large field that most other
drivers will not use, but also because it doesn't cover the use case the
Broadcom driver needs (only phase 1 key generated). Also, I don't think
we should take the "push" model to the extreme, that will just
complicate things in the future.

As for the transmit path here, we can trivially export
ieee80211_tkip_gen_rc4key() and, because key_conf is embedded in struct
ieee80211_key, give it a key_conf parameter that the driver knows about
from set_key(). That way, the driver can call that function for each
packet instead of having the stack do that, it only has to keep track of
the keys which it will most likely anyway.

Also, looking at what you do here, I found this comment:
        /* FIXME: need to differenciate between static and dynamic key
         * in the level of mac80211 */
        static_key = !iwl4965_is_associated(priv);

I think that is pretty bogus because there isn't really a distinction
between dynamic and static keys, what's the reason for differentiating
in the driver? Also, the driver will do rather odd things when
 * associate
 * set a key
 * disassociate
 * delete the key

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Sat, Mar 15, 2008 at 4:38 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
>  > From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>  >
>  > This patch makes the mac80211 able to send a ready phase2 key to the low
>  > level driver for TKIP encryption. Iwlwifi needs to get a phase2 key to
>  > encrypt TX packets in HW.
>
>
> > --- a/include/net/mac80211.h
>  > +++ b/include/net/mac80211.h
>  > @@ -287,6 +287,7 @@ struct ieee80211_tx_control {
>  >       u8 iv_len;              /* length of the IV field in octets */
>  >       u8 queue;               /* hardware queue to use for this frame;
>  >                                * 0 = highest, hw->queues-1 = lowest */
>  > +     u8 tkip_key[16];        /* generated phase2/phase1 key for hw TKIP */
>
>  I have to admit that I'm rather uncomfortable with adding this code to
>  the stack. Not only because that is a rather large field that most other
>  drivers will not use, but also because it doesn't cover the use case the
>  Broadcom driver needs (only phase 1 key generated). Also, I don't think
>  we should take the "push" model to the extreme, that will just
>  complicate things in the future.
>
>  As for the transmit path here, we can trivially export
>  ieee80211_tkip_gen_rc4key() and, because key_conf is embedded in struct
>  ieee80211_key, give it a key_conf parameter that the driver knows about
>  from set_key(). That way, the driver can call that function for each
>  packet instead of having the stack do that, it only has to keep track of
>  the keys which it will most likely anyway.

You might be right here we are investigating whether there are no
holes in this.

>  Also, looking at what you do here, I found this comment:
>         /* FIXME: need to differenciate between static and dynamic key
>          * in the level of mac80211 */
>         static_key = !iwl4965_is_associated(priv);
>
>  I think that is pretty bogus because there isn't really a distinction
>  between dynamic and static keys, what's the reason for differentiating
>  in the driver? Also, the driver will do rather odd things when
>   * associate
>   * set a key
>   * disassociate
>   * delete the key
>

This is actually quite a bug in mac80211. There is substantial
difference between dynamic and static key.
While static key  is used for crypto of all stations in BSS. Dynamic
key is also called pairwise key and is generated for 'pair'
Currently mac80211 set static key with broadcast address which iis
wrong cause driver cannot distinguish whether this key is
multicast/broadcast dynamic key or a static key. Shell it use it for
all traffic or only for mcast/bcast? Who can tell?
Other difference while there can be 4 static key installed that the
same time possible switching between indexes  There can be only one
dynamic key per station if you also consider mcast/bcast station to be
an entity. (TKIP actally uses different  key index for bcast but
that's just little execption)
The terminology which is used is also wrong and I guess this is just
wrong interpretation of  old implementation - 'default key' is used
for static key. Key mapping key is used for dynamic keys.

Thanks
Tomas
>  johannes
>
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
>  Ipw3945-devel mailing list
>  Ipw3945-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]


> >  Also, looking at what you do here, I found this comment:
> >         /* FIXME: need to differenciate between static and dynamic key
> >          * in the level of mac80211 */
> >         static_key = !iwl4965_is_associated(priv);
> >
> >  I think that is pretty bogus because there isn't really a distinction
> >  between dynamic and static keys, what's the reason for differentiating
> >  in the driver? Also, the driver will do rather odd things when
> >   * associate
> >   * set a key
> >   * disassociate
> >   * delete the key
> >
> 
> This is actually quite a bug in mac80211. There is substantial
> difference between dynamic and static key.
> While static key  is used for crypto of all stations in BSS. Dynamic
> key is also called pairwise key and is generated for 'pair'

Gee, can you then please stick to terminology used in the spec so other
people can understand it?

> Currently mac80211 set static key with broadcast address which iis
> wrong cause driver cannot distinguish whether this key is
> multicast/broadcast dynamic key or a static key. Shell it use it for
> all traffic or only for mcast/bcast? Who can tell?

Actually, you're making it look like a much larger problem than it is.
If you assume anything WEP is a "static key" and everything else is a
"dynamic key" (using your terminology), the only problem will be with
dynamic WEP, and even then it's not really a problem because as far as I
understand even dynamic WEP doesn't distinguish between group and
pairwise keys.

> Other difference while there can be 4 static key installed that the
> same time possible switching between indexes  There can be only one
> dynamic key per station if you also consider mcast/bcast station to be
> an entity. (TKIP actally uses different  key index for bcast but
> that's just little execption)
> The terminology which is used is also wrong and I guess this is just
> wrong interpretation of  old implementation - 'default key' is used
> for static key. Key mapping key is used for dynamic keys.

I don't think I understand the last paragraph?

In any case, actual TX key selection is done by mac80211 anyway, so
you're never interested in that. Only RX key selection is interesting to
the driver, and as far as I can tell it ought to work if you simply
always use the broadcast address key when it's WEP, and otherwise the
pairwise keys and/or the broadcast key for bc/mc frames.

Note that there's another case in AP mode where bc/mc keys are TX-only,
those are added with a zeroed MAC address.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Mon, Mar 17, 2008 at 11:58 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  > >  Also, looking at what you do here, I found this comment:
>  > >         /* FIXME: need to differenciate between static and dynamic key
>  > >          * in the level of mac80211 */
>  > >         static_key = !iwl4965_is_associated(priv);
>  > >
>  > >  I think that is pretty bogus because there isn't really a distinction
>  > >  between dynamic and static keys, what's the reason for differentiating
>  > >  in the driver? Also, the driver will do rather odd things when
>  > >   * associate
>  > >   * set a key
>  > >   * disassociate
>  > >   * delete the key
>  > >
>  >
>  > This is actually quite a bug in mac80211. There is substantial
>  > difference between dynamic and static key.
>  > While static key  is used for crypto of all stations in BSS. Dynamic
>  > key is also called pairwise key and is generated for 'pair'
>
>  Gee, can you then please stick to terminology used in the spec so other
>  people can understand it?

What spec. ieee80211i. WPA, WPA2? .

>
>  > Currently mac80211 set static key with broadcast address which iis
>  > wrong cause driver cannot distinguish whether this key is
>  > multicast/broadcast dynamic key or a static key. Shell it use it for
>  > all traffic or only for mcast/bcast? Who can tell?
>
>  Actually, you're making it look like a much larger problem than it is.
>  If you assume anything WEP is a "static key" and everything else is a
>  "dynamic key" (using your terminology), the only problem will be with
>  dynamic WEP, and even then it's not really a problem because as far as I
>  understand even dynamic WEP doesn't distinguish between group and
>  pairwise keys.

This is incorrect.  WPA enable using WEP as dynamic key and this
setting is very common.
WEP key is enabled for legacy stations this force also broadcast to be
WEP.  This setup is still quite common.


>
>  > Other difference while there can be 4 static key installed that the
>  > same time possible switching between indexes  There can be only one
>  > dynamic key per station if you also consider mcast/bcast station to be
>  > an entity. (TKIP actally uses different  key index for bcast but
>  > that's just little execption)
>  > The terminology which is used is also wrong and I guess this is just
>  > wrong interpretation of  old implementation - 'default key' is used
>  > for static key. Key mapping key is used for dynamic keys.
>
>  I don't think I understand the last paragraph?

Nothing imporatant just that term 'default key' is used usually on in
context of static/legacy WEP key
while term 'key mapping key' is used for what I call dynamic key.

>
>  In any case, actual TX key selection is done by mac80211 anyway, so
>  you're never interested in that. Only RX key selection is interesting to
>  the driver, and as far as I can tell it ought to work if you simply
>  always use the broadcast address key when it's WEP, and otherwise the
>  pairwise keys and/or the broadcast key for bc/mc frames.

Nothing to add to just that the assumption about WEP and broadcast is wrong.

>  Note that there's another case in AP mode where bc/mc keys are TX-only,
>  those are added with a zeroed MAC address.

I would prefer also in this case a clear flag rather then playing with
ambiguity of destination address.

>  johannes
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]


> >  > This is actually quite a bug in mac80211. There is substantial
> >  > difference between dynamic and static key.
> >  > While static key  is used for crypto of all stations in BSS. Dynamic
> >  > key is also called pairwise key and is generated for 'pair'
> >
> >  Gee, can you then please stick to terminology used in the spec so other
> >  people can understand it?
> 
> What spec. ieee80211i. WPA, WPA2? .

Preferably one that is actually readable to mere mortals (unlike WPA...)

> >  Actually, you're making it look like a much larger problem than it is.
> >  If you assume anything WEP is a "static key" and everything else is a
> >  "dynamic key" (using your terminology), the only problem will be with
> >  dynamic WEP, and even then it's not really a problem because as far as I
> >  understand even dynamic WEP doesn't distinguish between group and
> >  pairwise keys.
> 
> This is incorrect.  WPA enable using WEP as dynamic key and this
> setting is very common.
> WEP key is enabled for legacy stations this force also broadcast to be
> WEP.  This setup is still quite common.

I have no idea about WPA's non-IEEE modes. I don't seem to be able to
find such a thing in the IEEE spec so you'll have to actually elaborate
on this.

> >  In any case, actual TX key selection is done by mac80211 anyway, so
> >  you're never interested in that. Only RX key selection is interesting to
> >  the driver, and as far as I can tell it ought to work if you simply
> >  always use the broadcast address key when it's WEP, and otherwise the
> >  pairwise keys and/or the broadcast key for bc/mc frames.
> 
> Nothing to add to just that the assumption about WEP and broadcast is wrong.

> >  Note that there's another case in AP mode where bc/mc keys are TX-only,
> >  those are added with a zeroed MAC address.
> 
> I would prefer also in this case a clear flag rather then playing with
> ambiguity of destination address.

Yes, that would indeed help. Except that WEXT can't actually give you
the distinction so discussing these points right now is pretty moot when
we can't even do it properly as far as I can tell. Might be possible to
infer the information with the key management enabled flag thing...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Mon, Mar 17, 2008 at 12:57 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>  > >  Actually, you're making it look like a much larger problem than it is.
>  > >  If you assume anything WEP is a "static key" and everything else is a
>  > >  "dynamic key" (using your terminology), the only problem will be with
>  > >  dynamic WEP, and even then it's not really a problem because as far as I
>  > >  understand even dynamic WEP doesn't distinguish between group and
>  > >  pairwise keys.
>  >
>  > This is incorrect.  WPA enable using WEP as dynamic key and this
>  > setting is very common.
>  > WEP key is enabled for legacy stations this force also broadcast to be
>  > WEP.  This setup is still quite common.

>  I have no idea about WPA's non-IEEE modes. I don't seem to be able to
>  find such a thing in the IEEE spec so you'll have to actually elaborate
>  on this.

Actually I've misled you a bit. This is defined by IEEE 802.11i in
section TSN Transition Security Network. Where legacy WEP-only STA and
RSN-enabled station can coexists.  In this case Legacy stations use
static WEP key and RSN enabled station uses more advanced security
setting. RSN enabled station will be configured with WEP as a group
cipher  (spec name)

Here is a quote from the spec.. there is much more about it it's a bit
spread in the spec.

3.123 Transition Security Network (TSN): A Security Network which
allows the creation of Pre-Robust
Security Network Associations as well as Robust Security Network
Associations. A TSN can be identified
by the indication in the RSN IE of Beacons that the group cipher suite
in use is WEP.

>

>  > >  Note that there's another case in AP mode where bc/mc keys are TX-only,
>  > >  those are added with a zeroed MAC address.

>  > I would prefer also in this case a clear flag rather then playing with
>  > ambiguity of destination address.

On second thought is that AP has only TX group key while STA has only
RX group key so I
m not seeing here any need for flag.

>
>  Yes, that would indeed help. Except that WEXT can't actually give you
>  the distinction so discussing these points right now is pretty moot when
>  we can't even do it properly as far as I can tell. Might be possible to
>  infer the information with the key management enabled flag thing...

You have encode ioctl which is called only for static/legacy WEP or
you use CIPHER_NONE  for when using encodeext
For WEP in Pairwise and Group Key you use WEP40/104

/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
#define IW_AUTH_CIPHER_NONE	0x00000001
#define IW_AUTH_CIPHER_WEP40	0x00000002
#define IW_AUTH_CIPHER_TKIP	0x00000004
#define IW_AUTH_CIPHER_CCMP	0x00000008
#define IW_AUTH_CIPHER_WEP104	0x00000010

It's not well defined in wext but we can at least define the interface
from mac80211 point of view.


Thanks
Tomas

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]


> Actually I've misled you a bit. This is defined by IEEE 802.11i in
> section TSN Transition Security Network. Where legacy WEP-only STA and
> RSN-enabled station can coexists.  In this case Legacy stations use
> static WEP key and RSN enabled station uses more advanced security
> setting. RSN enabled station will be configured with WEP as a group
> cipher  (spec name)
> 
> Here is a quote from the spec.. there is much more about it it's a bit
> spread in the spec.
> 
> 3.123 Transition Security Network (TSN): A Security Network which
> allows the creation of Pre-Robust
> Security Network Associations as well as Robust Security Network
> Associations. A TSN can be identified
> by the indication in the RSN IE of Beacons that the group cipher suite
> in use is WEP.

Huh ok. But how would the WEP legacy station be able to determine that?
Or does it just try to use WEP and succeed? TBH, I was unaware that this
existed, this does make it a bit more of a problem than I thought then.

> >  > >  Note that there's another case in AP mode where bc/mc keys are TX-only,
> >  > >  those are added with a zeroed MAC address.
> 
> >  > I would prefer also in this case a clear flag rather then playing with
> >  > ambiguity of destination address.
> 
> On second thought is that AP has only TX group key while STA has only
> RX group key so I
> m not seeing here any need for flag.

Hm, well, I didn't really want to require the driver to keep track of
the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
for the group keys.

> >  Yes, that would indeed help. Except that WEXT can't actually give you
> >  the distinction so discussing these points right now is pretty moot when
> >  we can't even do it properly as far as I can tell. Might be possible to
> >  infer the information with the key management enabled flag thing...
> 
> You have encode ioctl which is called only for static/legacy WEP or
> you use CIPHER_NONE  for when using encodeext
> For WEP in Pairwise and Group Key you use WEP40/104

Is that really done though? I mean, does wpa_supplicant not also use
encodeext for WEP keys?

> /* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
> #define IW_AUTH_CIPHER_NONE	0x00000001
> #define IW_AUTH_CIPHER_WEP40	0x00000002
> #define IW_AUTH_CIPHER_TKIP	0x00000004
> #define IW_AUTH_CIPHER_CCMP	0x00000008
> #define IW_AUTH_CIPHER_WEP104	0x00000010
> 
> It's not well defined in wext but we can at least define the interface
> from mac80211 point of view.

True. So what change do we need?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

>
>  Huh ok. But how would the WEP legacy station be able to determine that?

Legacy user get the key written on 'positit' yellow paper :).

>  Or does it just try to use WEP and succeed? TBH, I was unaware that this
>  existed, this does make it a bit more of a problem than I thought then.
>

>  >
>  > On second thought is that AP has only TX group key while STA has only
>  > RX group key so I
>  > m not seeing here any need for flag.
>
>  Hm, well, I didn't really want to require the driver to keep track of
>  the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
>  for the group keys.

Isn't if on integer faster then comparing 6 bytes?

>
>  Is that really done though? I mean, does wpa_supplicant not also use
>  encodeext for WEP keys?
>
Unfortunately yes.
>
>  > /* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
>  > #define IW_AUTH_CIPHER_NONE   0x00000001
>  > #define IW_AUTH_CIPHER_WEP40  0x00000002
>  > #define IW_AUTH_CIPHER_TKIP   0x00000004
>  > #define IW_AUTH_CIPHER_CCMP   0x00000008
>  > #define IW_AUTH_CIPHER_WEP104 0x00000010
>  >
>  > It's not well defined in wext but we can at least define the interface
>  > from mac80211 point of view.
>
>  True. So what change do we need?
>
First of all we don't need 4 keys per station but for the whole
system. Even in AP mode with multiple SSID meaning multiple security
setting you cannot distinguish between networks in static WEP key
setting so 4 is enough.
Beside that you need place holder for group key. They might be
multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
doesn't support it in HW but in general it is possible.

We need a flag in set_key which says whether the WEP key is static or not.


Actually second items is currently the show stopper for me the first
Item is just a cleanup.

Thanks
Tomas

>  johannes
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]


> >  Huh ok. But how would the WEP legacy station be able to determine that?
> 
> Legacy user get the key written on 'positit' yellow paper :).

Heh yeah.

> >  Or does it just try to use WEP and succeed? TBH, I was unaware that this
> >  existed, this does make it a bit more of a problem than I thought then.
> >
> 
> >  >
> >  > On second thought is that AP has only TX group key while STA has only
> >  > RX group key so I
> >  > m not seeing here any need for flag.
> >
> >  Hm, well, I didn't really want to require the driver to keep track of
> >  the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
> >  for the group keys.
> 
> Isn't if on integer faster then comparing 6 bytes?

Probably. Does it matter though? Setting keys isn't going to be
performance critical in any way.

> >  Is that really done though? I mean, does wpa_supplicant not also use
> >  encodeext for WEP keys?
> >
> Unfortunately yes.

So that doesn't really help us either way, no?

> First of all we don't need 4 keys per station but for the whole
> system. 

Not sure I understand this. You need pairwise (per-station) keys as well
as four default keys, no?

> Even in AP mode with multiple SSID meaning multiple security
> setting you cannot distinguish between networks in static WEP key
> setting so 4 is enough.

Not sure I get what you're thinking here.

> Beside that you need place holder for group key. They might be
> multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
> doesn't support it in HW but in general it is possible.

Well, no, because we can add multiple keys with a zeroed MAC address,
since we have the local MAC address in there as well. Also, in an AP,
these are only used for TX so it doesn't matter since mac80211 does the
key selection completely on its own.

> We need a flag in set_key which says whether the WEP key is static or not.

Let's actually try to gather all the cases first.

Is this it?

 * TKIP/CCMP/WEP group or pairwise key
 * WEP legacy ('static') key

where the first is completely covered by what we have now and the
assumption is that if only WEP keys are present then it'll be a legacy
WEP key?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

>  >
>  > Isn't if on integer faster then comparing 6 bytes?
>
>  Probably. Does it matter though? Setting keys isn't going to be
>  performance critical in any way.

Yes but at least you do IF on something that is real not hacking with address.
>
>  > >  Is that really done though? I mean, does wpa_supplicant not also use
>  > >  encodeext for WEP keys?
>  > >
>  > Unfortunately yes.
>
>  So that doesn't really help us either way, no?

What is happening in case of static WEP is that IW_AUTH_CIPHER_NONE
IW_ENCODE_ALG_WEP are set.
Which is enough.

>
>  > First of all we don't need 4 keys per station but for the whole
>  > system.
>
>  Not sure I understand this. You need pairwise (per-station) keys as well
>  as four default keys, no?

You need only one unicast key for pairwise key.  4 keys are used only
for static WEP key.
For pairwise/dynamic WEP and TKIP you use key index in the packet but
it changes only when supplicant change the key it self. You don't have
the key alive in driver.



>
>  > Even in AP mode with multiple SSID meaning multiple security
>  > setting you cannot distinguish between networks in static WEP key
>  > setting so 4 is enough.
>
>  Not sure I get what you're thinking here.

BSS defines security setting which  defined by key management for
pairwise and group key + cipher method for both .
You can run multiple SSIDs over single single BSSID. This is done
using VLANs So you can maintain multiple security settings in for one
AP.  However this is not possible when using static WEP since the key
is global and the key is not attached to any address.

There are more details into it I'm sorry if I'm not 100 clear here.
The bottom line is that you don't need more 4 WEP keys both in AP and
station mod. Same you need to maintain only one pairwise key for
station both in AP and STA mode. In AP mode you need to maintain also
one group key for each station because of the case of multiple SSIDs.

>
>  > Beside that you need place holder for group key. They might be
>  > multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
>  > doesn't support it in HW but in general it is possible.
>
>  Well, no, because we can add multiple keys with a zeroed MAC address,
>  since we have the local MAC address in there as well. Also, in an AP,
>  these are only used for TX so it doesn't matter since mac80211 does the
>  key selection completely on its own.

See above. anyhow still don't like the trick with invalid address.

>
>  > We need a flag in set_key which says whether the WEP key is static or not.
>
>  Let's actually try to gather all the cases first.
>
>  Is this it?
>
>   * TKIP/CCMP/WEP group or pairwise key
>   * WEP legacy ('static') key

That's correct

>  where the first is completely covered by what we have now
Yes
and the
>  assumption is that if only WEP keys are present then it'll be a legacy
>  WEP key?
Nop. Still you  can have <WEP, WEP>  for <pairwise,group key> valid
setting - This is not static key. The two keys may differ. Under your
assumption the group key will override pairwise key

Tomas




>  johannes
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]


On Mon, 2008-03-17 at 21:12 +0200, Tomas Winkler wrote:
> >  >
> >  > Isn't if on integer faster then comparing 6 bytes?
> >
> >  Probably. Does it matter though? Setting keys isn't going to be
> >  performance critical in any way.
> 
> Yes but at least you do IF on something that is real not hacking with address.

True. Does it matter much though? I'm open to changing it but don't
think it matters too much.

> >  > >  Is that really done though? I mean, does wpa_supplicant not also use
> >  > >  encodeext for WEP keys?
> >  > >
> >  > Unfortunately yes.
> >
> >  So that doesn't really help us either way, no?
> 
> What is happening in case of static WEP is that IW_AUTH_CIPHER_NONE
> IW_ENCODE_ALG_WEP are set.
> Which is enough.

Indeed, that should be enough.

> You need only one unicast key for pairwise key.  4 keys are used only
> for static WEP key.
> For pairwise/dynamic WEP and TKIP you use key index in the packet but
> it changes only when supplicant change the key it self. You don't have
> the key alive in driver.

No, that's not true, due to rekeying concerns you actually can have more
than one group key at the same time in the driver/hardware.

> BSS defines security setting which  defined by key management for
> pairwise and group key + cipher method for both .
> You can run multiple SSIDs over single single BSSID. This is done
> using VLANs

Actually, we don't support that in mac80211. And the way I understand
VLANs they are simply done by negotiating different group keys with
different groups of stations each forming a VLAN.

> So you can maintain multiple security settings in for one
> AP.  However this is not possible when using static WEP since the key
> is global and the key is not attached to any address.
> 
> There are more details into it I'm sorry if I'm not 100 clear here.
> The bottom line is that you don't need more 4 WEP keys both in AP and
> station mod. Same you need to maintain only one pairwise key for
> station both in AP and STA mode. In AP mode you need to maintain also
> one group key for each station because of the case of multiple SSIDs.

Except the group keys don't really matter for an AP since they're TX
only, which is why we add them with a zeroed MAC address and can only
select them for TX.

> Nop. Still you  can have <WEP, WEP>  for <pairwise,group key> valid
> setting - This is not static key. The two keys may differ. Under your
> assumption the group key will override pairwise key

Hm, ok. So I suppose the only way to determine "static" right now would
be to check that no pairwise keys are configured at all.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

>  > You need only one unicast key for pairwise key.  4 keys are used only
>  > for static WEP key.
>  > For pairwise/dynamic WEP and TKIP you use key index in the packet but
>  > it changes only when supplicant change the key it self. You don't have
>  > the key alive in driver.
>
>  No, that's not true, due to rekeying concerns you actually can have more
>  than one group key at the same time in the driver/hardware.

I wasn't aware of this race in rekeying. I will investigate this.
Anyhow rekeying can also happing also for unicast keys.

>
>  > BSS defines security setting which  defined by key management for
>  > pairwise and group key + cipher method for both .
>  > You can run multiple SSIDs over single single BSSID. This is done
>  > using VLANs
>
>  Actually, we don't support that in mac80211.
Last time I worked on AP project it worked. It was older mac hopefully
it's not totally broken

 And the way I understand
>  VLANs they are simply done by negotiating different group keys with
>  different groups of stations each forming a VLAN.

We are saying the same. That's okay.

>
>  > So you can maintain multiple security settings in for one
>  > AP.  However this is not possible when using static WEP since the key
>  > is global and the key is not attached to any address.
>  >
>  > There are more details into it I'm sorry if I'm not 100 clear here.
>  > The bottom line is that you don't need more 4 WEP keys both in AP and
>  > station mod. Same you need to maintain only one pairwise key for
>  > station both in AP and STA mode. In AP mode you need to maintain also
>  > one group key for each station because of the case of multiple SSIDs.
>
>  Except the group keys don't really matter for an AP since they're TX
>  only, which is why we add them with a zeroed MAC address and can only
>  select them for TX
.
Zero address again :)

>
>
>  > Nop. Still you  can have <WEP, WEP>  for <pairwise,group key> valid
>  > setting - This is not static key. The two keys may differ. Under your
>  > assumption the group key will override pairwise key
>
>  Hm, ok. So I suppose the only way to determine "static" right now would
>  be to check that no pairwise keys are configured at all.

I'm not sure if I follow here but I think the simples way to determine
if static key is set is to set static_key flag to 1. I don't see any
reason this can be directly detected from the configuration.

Tomas

>  johannes
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]


> >
> >  > BSS defines security setting which  defined by key management for
> >  > pairwise and group key + cipher method for both .
> >  > You can run multiple SSIDs over single single BSSID. This is done
> >  > using VLANs
> >
> >  Actually, we don't support that in mac80211.
> Last time I worked on AP project it worked. It was older mac hopefully
> it's not totally broken
> 
>  And the way I understand
> >  VLANs they are simply done by negotiating different group keys with
> >  different groups of stations each forming a VLAN.
> 
> We are saying the same. That's okay.

Well, you were suggesting the use of multiple SSIDs, which we don't
support, we only support VLANs within a BSS/single SSID. Not that I've
been able to test it, hostapd needs radius stuff set up for VLANs...

> >  > So you can maintain multiple security settings in for one
> >  > AP.  However this is not possible when using static WEP since the key
> >  > is global and the key is not attached to any address.
> >  >
> >  > There are more details into it I'm sorry if I'm not 100 clear here.
> >  > The bottom line is that you don't need more 4 WEP keys both in AP and
> >  > station mod. Same you need to maintain only one pairwise key for
> >  > station both in AP and STA mode. In AP mode you need to maintain also
> >  > one group key for each station because of the case of multiple SSIDs.
> >
> >  Except the group keys don't really matter for an AP since they're TX
> >  only, which is why we add them with a zeroed MAC address and can only
> >  select them for TX
> .
> Zero address again :)
> 
> >
> >
> >  > Nop. Still you  can have <WEP, WEP>  for <pairwise,group key> valid
> >  > setting - This is not static key. The two keys may differ. Under your
> >  > assumption the group key will override pairwise key
> >
> >  Hm, ok. So I suppose the only way to determine "static" right now would
> >  be to check that no pairwise keys are configured at all.
> 
> I'm not sure if I follow here but I think the simples way to determine
> if static key is set is to set static_key flag to 1. I don't see any
> reason this can be directly detected from the configuration.

Right. I was just saying that the way it currently is I think you could
detect it that way. b43 simply assumes WEP keys are always 'static'
which seems to mostly work well in practice.

I suppose then set_key needs a new argument key_type:

enum ieee80211_key_type {
	KEY_TYPE_PAIRWISE,
	KEY_TYPE_GROUP,
	KEY_TYPE_TXONLY,	/* group key in an AP */
	KEY_TYPE_STATIC,
}

where the MAC address pointer would only be non-NULL when the key type
is PAIRWISE, and STATIC can only be used for WEP keys.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Mon, Mar 17, 2008 at 10:04 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  > >
>  > >  > BSS defines security setting which  defined by key management for
>  > >  > pairwise and group key + cipher method for both .
>  > >  > You can run multiple SSIDs over single single BSSID. This is done
>  > >  > using VLANs
>  > >
>  > >  Actually, we don't support that in mac80211.
>  > Last time I worked on AP project it worked. It was older mac hopefully
>  > it's not totally broken
>  >
>  >  And the way I understand
>  > >  VLANs they are simply done by negotiating different group keys with
>  > >  different groups of stations each forming a VLAN.
>  >
>  > We are saying the same. That's okay.
>
>  Well, you were suggesting the use of multiple SSIDs, which we don't
>  support, we only support VLANs within a BSS/single SSID. Not that I've
>  been able to test it, hostapd needs radius stuff set up for VLANs...

I think it's transparent since it's handled by MLME in hostapd so
multiple SSID is supported
Maybe we did some minor changes in mac to support that.. Will check again.
I think it's always done by means of VLANs


>  Right. I was just saying that the way it currently is I think you could
>  detect it that way. b43 simply assumes WEP keys are always 'static'
>  which seems to mostly work well in practice.
>  I suppose then set_key needs a new argument key_type:
>
>  enum ieee80211_key_type {
>         KEY_TYPE_PAIRWISE,
>         KEY_TYPE_GROUP,
>         KEY_TYPE_TXONLY,        /* group key in an AP */

Can we drop it? Hm still not sure why you like it so much.

>         KEY_TYPE_STATIC,
>  }
>
>  where the MAC address pointer would only be non-NULL when the key type
>  is PAIRWISE, and STATIC can only be used for WEP keys.
>


Do you know anything about mesh security are we breaking here anything?

Thanks
Tomas
>  johannes
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]


> >  Well, you were suggesting the use of multiple SSIDs, which we don't
> >  support, we only support VLANs within a BSS/single SSID. Not that I've
> >  been able to test it, hostapd needs radius stuff set up for VLANs...
> 
> I think it's transparent since it's handled by MLME in hostapd so
> multiple SSID is supported
> Maybe we did some minor changes in mac to support that.. Will check again.
> I think it's always done by means of VLANs

Oh, hm, could be true.

> >  Right. I was just saying that the way it currently is I think you could
> >  detect it that way. b43 simply assumes WEP keys are always 'static'
> >  which seems to mostly work well in practice.
> >  I suppose then set_key needs a new argument key_type:
> >
> >  enum ieee80211_key_type {
> >         KEY_TYPE_PAIRWISE,
> >         KEY_TYPE_GROUP,
> >         KEY_TYPE_TXONLY,        /* group key in an AP */
> 
> Can we drop it? Hm still not sure why you like it so much.

Well, we don't want an AP to actually decrypt things, so we need to
distinguish between these things so that the driver doesn't somehow try
to use that key for decryption.

> >         KEY_TYPE_STATIC,
> >  }
> >
> >  where the MAC address pointer would only be non-NULL when the key type
> >  is PAIRWISE, and STATIC can only be used for WEP keys.
> >
> 
> 
> Do you know anything about mesh security are we breaking here anything?

No, Javier, any comments? I think basically you have peer links that are
encrypted, which is just pairwise keys.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Jouni Malinen]

On Mon, Mar 17, 2008 at 10:27:53PM +0200, Tomas Winkler wrote:
> On Mon, Mar 17, 2008 at 10:04 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> >  Well, you were suggesting the use of multiple SSIDs, which we don't
> >  support, we only support VLANs within a BSS/single SSID. Not that I've
> >  been able to test it, hostapd needs radius stuff set up for VLANs...
> 
> I think it's transparent since it's handled by MLME in hostapd so
> multiple SSID is supported
> Maybe we did some minor changes in mac to support that.. Will check again.
> I think it's always done by means of VLANs

At least the original d80211 design supported multiple SSIDs per BSS and
yes, as far as kernel code is concerned, this was done in the identical
way for both multi-SSID and dynamic-VLAN (RADIUS assigned). A new
virtual interface is added for both cases and STAs are bound to the
specific virtual interface based on MLME/RADIUS results.

However, I do not think I ever merged multi-SSID support into the open
source version of hostapd, so it is quite possible that only the
RADIUS-based VLAN assignment is currently used since multi-SSID support
is inferior to multi-BSS support for number of reasons. Anyway, that
does not change what mac80211 would support should one ever really want
to enable multi-SSID support with a single BSS. I don't see much need
for that, though, if one can use virtual BSSes.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]


> At least the original d80211 design supported multiple SSIDs per BSS and
> yes, as far as kernel code is concerned, this was done in the identical
> way for both multi-SSID and dynamic-VLAN (RADIUS assigned). A new
> virtual interface is added for both cases and STAs are bound to the
> specific virtual interface based on MLME/RADIUS results.
> 
> However, I do not think I ever merged multi-SSID support into the open
> source version of hostapd, so it is quite possible that only the
> RADIUS-based VLAN assignment is currently used since multi-SSID support
> is inferior to multi-BSS support for number of reasons. Anyway, that
> does not change what mac80211 would support should one ever really want
> to enable multi-SSID support with a single BSS. I don't see much need
> for that, though, if one can use virtual BSSes.

Ah. I guess that requires hiding the SSID though?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Jouni Malinen]

On Tue, Mar 18, 2008 at 10:18:00AM +0100, Johannes Berg wrote:

> > At least the original d80211 design supported multiple SSIDs per BSS and
> > yes, as far as kernel code is concerned, this was done in the identical
> > way for both multi-SSID and dynamic-VLAN (RADIUS assigned). A new
> > virtual interface is added for both cases and STAs are bound to the
> > specific virtual interface based on MLME/RADIUS results.

> Ah. I guess that requires hiding the SSID though?

Not necessarily. The AP can advertise one SSID in Beacon frames and then
reply with Probe Response to multiple SSIDs (well, these other SSIDs
would of course be "hidden" in the sense that they are not broadcast in
Beacon frames). This works relatively well with most clients as long as
the security policy with the main SSID (the one advertised in the Beacon
frames) and the secondary ones (the ones that are only visible in Probe
Response frames) are identical. If they are different (e.g., open vs.
WPA), problems are to be expected with many client implementations since
this does not exactly match with the standard..

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Jouni Malinen]

On Wed, Mar 19, 2008 at 06:42:43PM +0200, Emmanuel Grumbach wrote:

> I ran some tests with the following configuration of wpa_supplicant:
>         key_mgmt=NONE
>         group=WEP104
>         wep_key0=123456789A123456789A12345A
>         wep_key1=123456789A123456789A12345B
>         wep_key2=123456789A123456789A12345C
>         wep_key3=123456789A123456789A12345D
>         wep_tx_keyidx=2

> From what I saw, the driver got ioctl SIOCSIWAUTH several times, once at the
> very beginning (even before wpa_supplicant read its config file). The value
> was 1, which means 1X in wext language.

I think there may be some misunderstanding here on how SIOCSIWAUTH is
used.. That call for setting IW_AUTH_WPA_ENABLED to 1 (WPA enabled), not
to set key management (IW_AUTH_KEY_MGMT).

> Then I got SIOCSIWENCODEEXT with the keys, right after that.
> There were other SIOCSIWAUTH calls but after SIOCSIWENCODEEXT, they didn't
> help much.

Help with what?

> From include/linux/wireless.h I saw that there are only two "legal" options:
> 
> /* IW_AUTH_KEY_MGMT values (bit field) */
> #define IW_AUTH_KEY_MGMT_802_1X 1
> #define IW_AUTH_KEY_MGMT_PSK    2
> 
> which is a bit poor... I would need something like
> #define IW_AUTH_KEY_MGMT_NONE 0

Well, there is not an explicit define for that, but zero is indeed used
to indicate that none of the listed key management options are used..

> In any case, this configuration (SIWAUTH with value = 1) seems quite odd
> since I am not running 1X, this value looks like a default value.

That's not what happened here as far as I can tell.. When starting to
associate, wpa_supplicant would end up setting IW_AUTH_KEY_MGMT to 0 in
this particular case.

> I would need to get configured with SIWAUTH value = 0, before
> SIOCSIWENCODEEXT, this would mean for me that the key that will be sent in
> the future are static keys.

The concept of "static keys" is a bit misleading.. And use of
IW_AUTH_KEY_MGMT to distinguish the key type does not sound like the
best thing to do here.

> The value 0 is chosen on purpose: iwconfig doesn't send any SIWAUTH ioctl
> and configures static WEP key. I would like IW_AUTH_KEY_MGMT_NONE to be the
> default in a zeroed struct.

I don't follow this.. IW_AUTH_KEY_MGMT is set to zero if 802.1X or WPA
is not used.

> Jouni, do you aggree that a change is needed in wpa_supplicant / wext to
> support WEP static key and allow mac80211 to differentiate between the
> config I copy pasted before and WEP keys coming from an AP through 1X ?

No, I don't see why something in wpa_supplicant or WEXT would need to be
changed. If the goal is to figure out whether the key that is being
configured is a broadcast/default/group key, the ext_flags field for
SIOCSIWENCODEEXT is has IW_ENCODE_EXT_GROUP_KEY flag. If the key is a
unicast/individual/key-mapping key, this flag is not set. In addition,
the addr.sa_data value is set to ff:ff:ff:ff:ff:ff for
broadcast/default/group keys and to a unicast address for
unicast/individual/key-mapping keys.

Calling the keys "static" or "dynamic" is just going to cause
confusion.. It does not matter whether the keys are statically
configured (e.g., IEEE 802.1X "dynamic keys" for broadcast could be
configured "statically" to support non-IEEE 802.1X STAs). The main
difference is in whether they are broadcast/default/group keys or
individual/unicast/key-mapping keys. As far as I know, this is already
distinguished in the current interface. If not, please let me know exact
details on the case that does not have such information.

The driver will just need to know which key to use in the corner case if
someone were to configure broadcast/default/group key with key index 0
and a unicast/individual key (always key index 0 if one were to follow
the standard) and both could match an incoming frame (the
broadcast/default/group key would be used if the addr1 field is
broadcast/multicast; otherwise, the unicast/individual/key-mapping key
would be used).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Wed, Mar 19, 2008 at 7:39 PM, Jouni Malinen <j@w1.fi> wrote:
> On Wed, Mar 19, 2008 at 06:42:43PM +0200, Emmanuel Grumbach wrote:
>
>  > I ran some tests with the following configuration of wpa_supplicant:
>
> >         key_mgmt=NONE
>  >         group=WEP104
>  >         wep_key0=123456789A123456789A12345A
>  >         wep_key1=123456789A123456789A12345B
>  >         wep_key2=123456789A123456789A12345C
>  >         wep_key3=123456789A123456789A12345D
>  >         wep_tx_keyidx=2
>
>  > From what I saw, the driver got ioctl SIOCSIWAUTH several times, once at the
>  > very beginning (even before wpa_supplicant read its config file). The value
>  > was 1, which means 1X in wext language.
>
>  I think there may be some misunderstanding here on how SIOCSIWAUTH is
>  used.. That call for setting IW_AUTH_WPA_ENABLED to 1 (WPA enabled), not
>  to set key management (IW_AUTH_KEY_MGMT).
>
>
>  > Then I got SIOCSIWENCODEEXT with the keys, right after that.
>  > There were other SIOCSIWAUTH calls but after SIOCSIWENCODEEXT, they didn't
>  > help much.
>
>  Help with what?

As keys were already applied consequent  calls SIOCSIWAUTH are not
helpful. Unfortunately the  order mattes. As in some cases SIOCSIWAUTH
might not come so the actual setting is triggered by SIOCSIWENCODEEXT.

>
>  > From include/linux/wireless.h I saw that there are only two "legal" options:
>  >
>  > /* IW_AUTH_KEY_MGMT values (bit field) */
>  > #define IW_AUTH_KEY_MGMT_802_1X 1
>  > #define IW_AUTH_KEY_MGMT_PSK    2
>  >
>  > which is a bit poor... I would need something like
>  > #define IW_AUTH_KEY_MGMT_NONE 0
>
>  Well, there is not an explicit define for that, but zero is indeed used
>  to indicate that none of the listed key management options are used..
>
>
>  > In any case, this configuration (SIWAUTH with value = 1) seems quite odd
>  > since I am not running 1X, this value looks like a default value.
>
>  That's not what happened here as far as I can tell.. When starting to
>  associate, wpa_supplicant would end up setting IW_AUTH_KEY_MGMT to 0 in
>  this particular case.

Will try to verify that again

>
>  > I would need to get configured with SIWAUTH value = 0, before
>  > SIOCSIWENCODEEXT, this would mean for me that the key that will be sent in
>  > the future are static keys.
>
>  The concept of "static keys" is a bit misleading.. And use of
>  IW_AUTH_KEY_MGMT to distinguish the key type does not sound like the
>  best thing to do here.
>
>
>  > The value 0 is chosen on purpose: iwconfig doesn't send any SIWAUTH ioctl
>  > and configures static WEP key. I would like IW_AUTH_KEY_MGMT_NONE to be the
>  > default in a zeroed struct.
>
>  I don't follow this.. IW_AUTH_KEY_MGMT is set to zero if 802.1X or WPA
>  is not used.
>
>
>  > Jouni, do you aggree that a change is needed in wpa_supplicant / wext to
>  > support WEP static key and allow mac80211 to differentiate between the
>  > config I copy pasted before and WEP keys coming from an AP through 1X ?
>
>  No, I don't see why something in wpa_supplicant or WEXT would need to be
>  changed. If the goal is to figure out whether the key that is being
>  configured is a broadcast/default/group key, the ext_flags field for
>  SIOCSIWENCODEEXT is has IW_ENCODE_EXT_GROUP_KEY flag. If the key is a
>  unicast/individual/key-mapping key, this flag is not set. In addition,
>  the addr.sa_data value is set to ff:ff:ff:ff:ff:ff for
>  broadcast/default/group keys and to a unicast address for
>  unicast/individual/key-mapping keys.



  >  Calling the keys "static" or "dynamic" is just going to cause
>  confusion.. It does not matter whether the keys are statically
>  configured (e.g., IEEE 802.1X "dynamic keys" for broadcast could be
>  configured "statically" to support non-IEEE 802.1X STAs). The main
>  difference is in whether they are broadcast/default/group keys or
>  individual/unicast/key-mapping keys. As far as I know, this is already
>  distinguished in the current interface. If not, please let me know exact
>  details on the case that does not have such information.

>  The driver will just need to know which key to use in the corner case if
>  someone were to configure broadcast/default/group key with key index 0
>  and a unicast/individual key (always key index 0 if one were to follow
>  the standard) and both could match an incoming frame (the
>  broadcast/default/group key would be used if the addr1 field is
>  broadcast/multicast; otherwise, the unicast/individual/key-mapping key
>  would be used).
>
>

So how do you call WEP key that is used for both unicast and broadcast
i.e the old WEP key.
It's not attached to any particular address it's global BSS key. The
true is that you don't need
a supplicant to configure it yet wpa_supplicant has this option so
people do that.

What mac80211 currently does it's attach it to broadcast address. If
there is a group key re keying you don't know whether also unicast key
have to be overridden or not since you don't know if this is a
'static/global; key or  dynamic group key


Thanks
Tomas

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Jouni Malinen]

On Wed, Mar 19, 2008 at 08:41:22PM +0200, Tomas Winkler wrote:

> So how do you call WEP key that is used for both unicast and broadcast
> i.e the old WEP key.

The IEEE 802.11 name for this would be "default key". IEEE 802.1X (or
well, RFC 3580 is the authoritative specification for this) calls it
"broadcast (default key)". Please note that this is not really a key
that is always used both for unicast and broadcast. If there is a
key-mapping key (unicast/individual) for the matching
transmitter/receiver addresses, that key will be used instead. The "old
WEP key" way of using only statically configured default keys just does
not set the key-mapping key and because of that, the default key ends up
being used for all frames (or well, one of the possible four default
keys).

> What mac80211 currently does it's attach it to broadcast address. If
> there is a group key re keying you don't know whether also unicast key
> have to be overridden or not since you don't know if this is a
> 'static/global; key or  dynamic group key

I haven't looked at what the current implementation does, but as far as
WEXT and SIOCSIWENCODEEXT is concerned, IW_ENCODE_EXT_GROUP_KEY flag
should be used to select which key is being configured. There is no
difference between "static/global" and "dynamic group" keys. The only
difference is between default and key-mapping (individual) keys.

Sure, the terminology here can be quite confusing, but as far as I can
tell, that IW_ENCODE_EXT_GROUP_KEY flag is all that is needed to
distinguish which key is being configured and configuring a single key
should not automatically change another one (even if the key index is
same which could, at least in theory, happen with key index 0 that can
be used both with default and key-mapping keys).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]


> The IEEE 802.11 name for this would be "default key". IEEE 802.1X (or
> well, RFC 3580 is the authoritative specification for this) calls it
> "broadcast (default key)". Please note that this is not really a key
> that is always used both for unicast and broadcast. If there is a
> key-mapping key (unicast/individual) for the matching
> transmitter/receiver addresses, that key will be used instead. The "old
> WEP key" way of using only statically configured default keys just does
> not set the key-mapping key and because of that, the default key ends up
> being used for all frames (or well, one of the possible four default
> keys).

That agrees with what I did in mac80211, but not with Intel's hardware.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Wed, Mar 19, 2008 at 10:15 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>  > The IEEE 802.11 name for this would be "default key". IEEE 802.1X (or
>  > well, RFC 3580 is the authoritative specification for this) calls it
>  > "broadcast (default key)". Please note that this is not really a key
>  > that is always used both for unicast and broadcast. If there is a
>  > key-mapping key (unicast/individual) for the matching
>  > transmitter/receiver addresses, that key will be used instead. The "old
>  > WEP key" way of using only statically configured default keys just does
>  > not set the key-mapping key and because of that, the default key ends up
>  > being used for all frames (or well, one of the possible four default
>  > keys).
>
>  That agrees with what I did in mac80211, but not with Intel's hardware.

You wish, you didn't have clue yourself :)

>  johannes
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]


On Thu, 2008-03-20 at 00:04 +0200, Tomas Winkler wrote:
> On Wed, Mar 19, 2008 at 10:15 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> >
> >  > The IEEE 802.11 name for this would be "default key". IEEE 802.1X (or
> >  > well, RFC 3580 is the authoritative specification for this) calls it
> >  > "broadcast (default key)". Please note that this is not really a key
> >  > that is always used both for unicast and broadcast. If there is a
> >  > key-mapping key (unicast/individual) for the matching
> >  > transmitter/receiver addresses, that key will be used instead. The "old
> >  > WEP key" way of using only statically configured default keys just does
> >  > not set the key-mapping key and because of that, the default key ends up
> >  > being used for all frames (or well, one of the possible four default
> >  > keys).
> >
> >  That agrees with what I did in mac80211, but not with Intel's hardware.
> 
> You wish, you didn't have clue yourself :)

I know :P
I actually just cleaned up the original code (and added the distinction
for TX-only keys.)

Actually, it makes things quite complicated for the driver because it
has to keep track of whether pairwise keys are enabled even if they are
for an encryption algorithm that it doesn't handle. I suppose making
mac80211 track that would be nicer.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

On Wed, Mar 19, 2008 at 10:10 PM, Jouni Malinen <j@w1.fi> wrote:
> On Wed, Mar 19, 2008 at 08:41:22PM +0200, Tomas Winkler wrote:
>
>  > So how do you call WEP key that is used for both unicast and broadcast
>  > i.e the old WEP key.
>
>  The IEEE 802.11 name for this would be "default key". IEEE 802.1X (or
>  well, RFC 3580 is the authoritative specification for this) calls it
>  "broadcast (default key)". Please note that this is not really a key
>  that is always used both for unicast and broadcast. If there is a
>  key-mapping key (unicast/individual) for the matching
>  transmitter/receiver addresses, that key will be used instead. The "old
>  WEP key" way of using only statically configured default keys just does
>  not set the key-mapping key and because of that, the default key ends up
>  being used for all frames (or well, one of the possible four default
>  keys).
>
>
>  > What mac80211 currently does it's attach it to broadcast address. If
>  > there is a group key re keying you don't know whether also unicast key
>  > have to be overridden or not since you don't know if this is a
>  > 'static/global; key or  dynamic group key
>
>  I haven't looked at what the current implementation does, but as far as
>  WEXT and SIOCSIWENCODEEXT is concerned, IW_ENCODE_EXT_GROUP_KEY flag
>  should be used to select which key is being configured. There is no
>  difference between "static/global" and "dynamic group" keys. The only
>  difference is between default and key-mapping (individual) keys.
>
>  Sure, the terminology here can be quite confusing, but as far as I can
>  tell, that IW_ENCODE_EXT_GROUP_KEY flag is all that is needed to
>  distinguish which key is being configured and configuring a single key
>  should not automatically change another one (even if the key index is
>  same which could, at least in theory, happen with key index 0 that can
>  be used both with default and key-mapping keys).
>

Just trying to translate it to configuration flow: To determine if the
key is old-WEP would be
Use group key as default key for all traffic unless and key-mapping key was set
Is that correct?

I will check how difficult is to do that implementation wise

Thanks
Tomas

>
>  --
>  Jouni Malinen                                            PGP id EFC895FA
>

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Emmanuel Grumbach]

>  I haven't looked at what the current implementation does, but as far as
>  WEXT and SIOCSIWENCODEEXT is concerned, IW_ENCODE_EXT_GROUP_KEY flag
>  should be used to select which key is being configured. There is no
>  difference between "static/global" and "dynamic group" keys. The only
>  difference is between default and key-mapping (individual) keys.
>
>  Sure, the terminology here can be quite confusing, but as far as I can
>  tell, that IW_ENCODE_EXT_GROUP_KEY flag is all that is needed to
>  distinguish which key is being configured and configuring a single key
>  should not automatically change another one (even if the key index is
>  same which could, at least in theory, happen with key index 0 that can
>  be used both with default and key-mapping keys).
>

Ok, I tested this flag, this will be enough (AFAIK for the moment) to
distinguish
which key is being configured.
Regarding SIOCSIWENCODE, I understand that there is no need to support it
(at least wrt wpa_supplicant) since mac80211 supports SIOCSIWENCODEEXT
and wpa_supplicant won't send SIOCSIWENCODE if SIOCSIWENCODEEXT
call succeeds right ?

iwconfig sends SIOCSIWENCODE but AFAIK, iwconfig configs only default keys (or
broadcast (default key) as RFC 3580 calls it), so no possibility to be
mistaken here...

Thanks for you help !

>
>
>  --
>  Jouni Malinen                                            PGP id EFC895FA
>



-- 
Emmanuel Grumbach
egrumbach@gmail.com

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Jouni Malinen]

On Thu, Mar 20, 2008 at 09:09:16AM +0200, Emmanuel Grumbach wrote:

> Regarding SIOCSIWENCODE, I understand that there is no need to support it
> (at least wrt wpa_supplicant) since mac80211 supports SIOCSIWENCODEEXT
> and wpa_supplicant won't send SIOCSIWENCODE if SIOCSIWENCODEEXT
> call succeeds right ?

Yes. It would probably be enough to just assume the SIOCSIWENCODE is
being used only for default keys. wpa_supplicant will always try to use
SIOCSIWENCODEEXT first and in case of mac80211, SIOCSIWENCODE won't be
used for setting keys.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Dan Williams]

On Mon, 2008-03-17 at 14:49 +0100, Johannes Berg wrote:
> > >  Huh ok. But how would the WEP legacy station be able to determine that?
> > 
> > Legacy user get the key written on 'positit' yellow paper :).
> 
> Heh yeah.
> 
> > >  Or does it just try to use WEP and succeed? TBH, I was unaware that this
> > >  existed, this does make it a bit more of a problem than I thought then.
> > >
> > 
> > >  >
> > >  > On second thought is that AP has only TX group key while STA has only
> > >  > RX group key so I
> > >  > m not seeing here any need for flag.
> > >
> > >  Hm, well, I didn't really want to require the driver to keep track of
> > >  the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
> > >  for the group keys.
> > 
> > Isn't if on integer faster then comparing 6 bytes?
> 
> Probably. Does it matter though? Setting keys isn't going to be
> performance critical in any way.
> 
> > >  Is that really done though? I mean, does wpa_supplicant not also use
> > >  encodeext for WEP keys?
> > >
> > Unfortunately yes.
> 
> So that doesn't really help us either way, no?
> 
> > First of all we don't need 4 keys per station but for the whole
> > system. 
> 
> Not sure I understand this. You need pairwise (per-station) keys as well
> as four default keys, no?
> 
> > Even in AP mode with multiple SSID meaning multiple security
> > setting you cannot distinguish between networks in static WEP key
> > setting so 4 is enough.
> 
> Not sure I get what you're thinking here.
> 
> > Beside that you need place holder for group key. They might be
> > multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
> > doesn't support it in HW but in general it is possible.
> 
> Well, no, because we can add multiple keys with a zeroed MAC address,
> since we have the local MAC address in there as well. Also, in an AP,
> these are only used for TX so it doesn't matter since mac80211 does the
> key selection completely on its own.
> 
> > We need a flag in set_key which says whether the WEP key is static or not.
> 
> Let's actually try to gather all the cases first.
> 
> Is this it?
> 
>  * TKIP/CCMP/WEP group or pairwise key
>  * WEP legacy ('static') key

So the problem with this is, how does Dynamic WEP work here?  Dynamic
WEP uses 802.1x/EAP to rekey stations periodically just like
WPA[2]-Enterprise, but of courses uses WEP only.  It's not "static" WEP
as you guys have been talking about it (you could call static WEP
"WEP-PSK" if you like).

The problem here is that with WEXT, there's not a good way to
distinguish between the two.  Both static & dynamic WEP might look the
same to the driver when the call comes through SIWENCODE/SIWENCODEEXT.
So you've got to be careful here classifying all WEP key requests as
static.

Dan

> where the first is completely covered by what we have now and the
> assumption is that if only WEP keys are present then it'll be a legacy
> WEP key?
> 
> johannes

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

>
>  So the problem with this is, how does Dynamic WEP work here?  Dynamic
>  WEP uses 802.1x/EAP to rekey stations periodically just like
>  WPA[2]-Enterprise, but of courses uses WEP only.  It's not "static" WEP
>  as you guys have been talking about it (you could call static WEP
>  "WEP-PSK" if you like).
>
>  The problem here is that with WEXT, there's not a good way to
>  distinguish between the two.  Both static & dynamic WEP might look the
>  same to the driver when the call comes through SIWENCODE/SIWENCODEEXT.
>  So you've got to be careful here classifying all WEP key requests as
>  static.

Yes this two are not enough you need also specify the the key management method
via SIWEAUTH .

Tomas

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Dan Williams]

On Mon, 2008-03-17 at 12:20 +0200, Tomas Winkler wrote:
> On Mon, Mar 17, 2008 at 11:58 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> >
> >  > >  Also, looking at what you do here, I found this comment:
> >  > >         /* FIXME: need to differenciate between static and dynamic key
> >  > >          * in the level of mac80211 */
> >  > >         static_key = !iwl4965_is_associated(priv);
> >  > >
> >  > >  I think that is pretty bogus because there isn't really a distinction
> >  > >  between dynamic and static keys, what's the reason for differentiating
> >  > >  in the driver? Also, the driver will do rather odd things when
> >  > >   * associate
> >  > >   * set a key
> >  > >   * disassociate
> >  > >   * delete the key
> >  > >
> >  >
> >  > This is actually quite a bug in mac80211. There is substantial
> >  > difference between dynamic and static key.
> >  > While static key  is used for crypto of all stations in BSS. Dynamic
> >  > key is also called pairwise key and is generated for 'pair'
> >
> >  Gee, can you then please stick to terminology used in the spec so other
> >  people can understand it?
> 
> What spec. ieee80211i. WPA, WPA2? .
> 
> >
> >  > Currently mac80211 set static key with broadcast address which iis
> >  > wrong cause driver cannot distinguish whether this key is
> >  > multicast/broadcast dynamic key or a static key. Shell it use it for
> >  > all traffic or only for mcast/bcast? Who can tell?
> >
> >  Actually, you're making it look like a much larger problem than it is.
> >  If you assume anything WEP is a "static key" and everything else is a
> >  "dynamic key" (using your terminology), the only problem will be with
> >  dynamic WEP, and even then it's not really a problem because as far as I
> >  understand even dynamic WEP doesn't distinguish between group and
> >  pairwise keys.
> 
> This is incorrect.  WPA enable using WEP as dynamic key and this
> setting is very common.
> WEP key is enabled for legacy stations this force also broadcast to be
> WEP.  This setup is still quite common.

Also sort of wrong; there are plenty of situations where the AP can be
put into essentially Dynamic WEP mode (I actually test this quite often
since there are a lot of people who use it) where it is still backed by
RADIUS but uses only WEP as the cipher and does _NOT_ broadcast WPA/RSN
information elements at all.

The _only_ guarantee you have for Dynamic WEP is that the privacy bit is
set to 1.  Here's an iwlist dump for such a configuration, taken with an
ipw2200, so it would be reporting WPA/RSN IEs if there were any, but
there aren't:

          Cell 30 - Address: 00:1A:xx:xx:xx:xx
                    ESSID:"foobar"
                    Protocol:IEEE 802.11bg
                    Mode:Master
                    Frequency:2.422 GHz (Channel 3)
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Quality=82/100  Signal level=-16 dBm  
                    Extra: Last beacon: 35ms ago

Looks like static WEP, but it's actually a Cisco AIR-AP1131AG backed by
RADIUS using EAP-TLS.

Unfortunately for dynamic WEP, as a user you simply have to _know_ that
the AP is using one of:

- Open System auth
- Shared Key auth
- WEP 104
- WEP 40
- LEAP
- Dynamic WEP

since it doesn't beacon, you're just fucked unless your sysadmin tells
you what the AP is doing.  Yay for WEP.

Dan

> 
> >
> >  > Other difference while there can be 4 static key installed that the
> >  > same time possible switching between indexes  There can be only one
> >  > dynamic key per station if you also consider mcast/bcast station to be
> >  > an entity. (TKIP actally uses different  key index for bcast but
> >  > that's just little execption)
> >  > The terminology which is used is also wrong and I guess this is just
> >  > wrong interpretation of  old implementation - 'default key' is used
> >  > for static key. Key mapping key is used for dynamic keys.
> >
> >  I don't think I understand the last paragraph?
> 
> Nothing imporatant just that term 'default key' is used usually on in
> context of static/legacy WEP key
> while term 'key mapping key' is used for what I call dynamic key.
> 
> >
> >  In any case, actual TX key selection is done by mac80211 anyway, so
> >  you're never interested in that. Only RX key selection is interesting to
> >  the driver, and as far as I can tell it ought to work if you simply
> >  always use the broadcast address key when it's WEP, and otherwise the
> >  pairwise keys and/or the broadcast key for bc/mc frames.
> 
> Nothing to add to just that the assumption about WEP and broadcast is wrong.
> 
> >  Note that there's another case in AP mode where bc/mc keys are TX-only,
> >  those are added with a zeroed MAC address.
> 
> I would prefer also in this case a clear flag rather then playing with
> ambiguity of destination address.
> 
> >  johannes
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Tomas Winkler]

>  Also sort of wrong; there are plenty of situations where the AP can be
>  put into essentially Dynamic WEP mode (I actually test this quite often
>  since there are a lot of people who use it) where it is still backed by
>  RADIUS but uses only WEP as the cipher and does _NOT_ broadcast WPA/RSN
>  information elements at all.
>
>  The _only_ guarantee you have for Dynamic WEP is that the privacy bit is
>  set to 1.  Here's an iwlist dump for such a configuration, taken with an
>  ipw2200, so it would be reporting WPA/RSN IEs if there were any, but
>  there aren't:
>
>           Cell 30 - Address: 00:1A:xx:xx:xx:xx
>                     ESSID:"foobar"
>                     Protocol:IEEE 802.11bg
>                     Mode:Master
>                     Frequency:2.422 GHz (Channel 3)
>                     Encryption key:on
>                     Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
>                               11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
>                               48 Mb/s; 54 Mb/s
>                     Quality=82/100  Signal level=-16 dBm
>                     Extra: Last beacon: 35ms ago
>
>  Looks like static WEP, but it's actually a Cisco AIR-AP1131AG backed by
>  RADIUS using EAP-TLS.
>
>  Unfortunately for dynamic WEP, as a user you simply have to _know_ that
>  the AP is using one of:
>
>  - Open System auth
>  - Shared Key auth
>  - WEP 104
>  - WEP 40
>  - LEAP
>  - Dynamic WEP
>
>  since it doesn't beacon, you're just fucked unless your sysadmin tells
>  you what the AP is doing.  Yay for WEP.
>

I think we are addressing different problems. First of all our focus
is on mac80211 interpretation of WEP setting through WEXT rather then
how use know what security setting to chose.  Currently even when user
now how to configure the security setting a driver under mac80211 was
not able to distinguish what is static and what is dynamic WEP it was
blurred by mac80211.

The problem of distributing and guessing wireless profiles is a
different problem.  Unfortunately the whole wireleess stack is burden
by coexistence with legacy systems.

Tomas


>  Dan
>
>
>  >
>  > >
>  > >  > Other difference while there can be 4 static key installed that the
>  > >  > same time possible switching between indexes  There can be only one
>  > >  > dynamic key per station if you also consider mcast/bcast station to be
>  > >  > an entity. (TKIP actally uses different  key index for bcast but
>  > >  > that's just little execption)
>  > >  > The terminology which is used is also wrong and I guess this is just
>  > >  > wrong interpretation of  old implementation - 'default key' is used
>  > >  > for static key. Key mapping key is used for dynamic keys.
>  > >
>  > >  I don't think I understand the last paragraph?
>  >
>  > Nothing imporatant just that term 'default key' is used usually on in
>  > context of static/legacy WEP key
>  > while term 'key mapping key' is used for what I call dynamic key.
>  >
>  > >
>  > >  In any case, actual TX key selection is done by mac80211 anyway, so
>  > >  you're never interested in that. Only RX key selection is interesting to
>  > >  the driver, and as far as I can tell it ought to work if you simply
>  > >  always use the broadcast address key when it's WEP, and otherwise the
>  > >  pairwise keys and/or the broadcast key for bc/mc frames.
>  >
>  > Nothing to add to just that the assumption about WEP and broadcast is wrong.
>  >
>  > >  Note that there's another case in AP mode where bc/mc keys are TX-only,
>  > >  those are added with a zeroed MAC address.
>  >
>  > I would prefer also in this case a clear flag rather then playing with
>  > ambiguity of destination address.
>  >
>  > >  johannes
>  > >
>  > --
>  > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>  > the body of a message to majordomo@vger.kernel.org
>  > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>