IEEE 802.11w / management frame protection
Subsystems (2)
cover IEEE 802.11w / management frame protection
This is the first and still quite preliminary version of changes to introduce IEEE 802.11w (management frame protection) support into mac80211. As such, I'm mainly looking for comments on the current design to help me in finalizing and cleaning up the patches.
Please note that couple of small additions to hostapd and wpa_supplicant are required to actually configure MFP and those are not yet included in the hostap git repository. Consequently, this is not yet available for real testing. Or well, if you really want to test this now, I can send an experimental patch to hostapd/wpa_supplicant to enable MFP support.
The current version is relatively complete for mac80211, but there are still couple of known missing functions and I've done only very limited testing so far. I was able to send and receive both CCMP and BIP protected deauthentication frames and based on a sniffer log, the frames looked correct. All this is with mac80211_hwsim and software crypto. It is unclear whether this can be used as-is with devices that use hwaccel for crypto at least before the low-level drivers and/or firmware have been modified to cope with the possibility of CCMP being used with management frames.
This patch set does not address the issues found in configuring default keys for monitor interfaces, i.e., this still needs a workaround in hostapd to set IGTK for both wlan# and mon.wlan#. In addition, the debugfs directory is left behind when the monitor interface is removed.
Since IEEE 802.11w draft is still in progress and open to changes, it is also unclear whether we would actually like to introduce IEEE 802.11w support as-is into mac80211 in main line kernels at this point. Then again, IEEE 802.11w draft is quite a bit further in the standardization process than IEEE 802.11s draft and we already have some pre-standard mesh support in mac80211 at least in wireless-testing.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
RFC PATCH 1/7 802.11w: STA flag for MFP
Add flags for setting STA entries and struct ieee80211_if_sta to indicate whether management frame protection (MFP) is used.
net/mac80211/ieee80211_i.h +1 -0
@@ -300,6 +300,7 @@ struct mesh_config {#define IEEE80211_STA_AUTO_BSSID_SEL BIT(11)#define IEEE80211_STA_AUTO_CHANNEL_SEL BIT(12)#define IEEE80211_STA_PRIVACY_INVOKED BIT(13) +#define IEEE80211_STA_MFP_ENABLED BIT(14)struct ieee80211_if_sta {struct timer_list timer;struct work_struct work;
net/mac80211/mlme.c +6 -3
@@ -1,6 +1,6 @@/* * BSS client mode implementation -* Copyright 2003, Jouni Malinen <[email protected]> +* Copyright 2003-2008, Jouni Malinen <[email protected]> * Copyright 2004, Instant802 Networks, Inc. * Copyright 2005, Devicescape Software, Inc. * Copyright 2006-2007 Jiri Benc <[email protected]>
@@ -885,7 +885,7 @@ static void ieee80211_send_deauth(structskb_put (skb,2 ); mgmt->u.deauth.reason_code =cpu_to_le16 (reason); -ieee80211_sta_tx (dev, skb,0 ); +ieee80211_sta_tx (dev, skb, ifsta->flags &IEEE80211_STA_MFP_ENABLED ); }
@@ -914,7 +914,7 @@ static void ieee80211_send_disassoc(struskb_put (skb,2 ); mgmt->u.disassoc.reason_code =cpu_to_le16 (reason); -ieee80211_sta_tx (dev, skb,0 ); +ieee80211_sta_tx (dev, skb, ifsta->flags &IEEE80211_STA_MFP_ENABLED ); }
@@ -2107,6 +2107,9 @@ static void ieee80211_rx_mgmt_assoc_resprate_control_rate_init (sta, local); +if (ifsta->flags &IEEE80211_STA_MFP_ENABLED ) +set_sta_flags (sta,WLAN_STA_MFP ); +if (elems.wmm_param) {set_sta_flags (sta,WLAN_STA_WME );rcu_read_unlock ();
include/linux/nl80211.h +2 -0
@@ -286,12 +286,14 @@ enum nl80211_iftype {* @NL80211_STA_FLAG_SHORT_PREAMBLE: station is capable of receiving frames * with short barker preamble * @NL80211_STA_FLAG_WME: station is WME/QoS capable +* @NL80211_STA_FLAG_MFP: station uses management frame protection */ enum nl80211_sta_flags { __NL80211_STA_FLAG_INVALID,NL80211_STA_FLAG_AUTHORIZED ,NL80211_STA_FLAG_SHORT_PREAMBLE ,NL80211_STA_FLAG_WME , +NL80211_STA_FLAG_MFP ,/* keep last */ __NL80211_STA_FLAG_AFTER_LAST,
include/net/cfg80211.h +2 -0
@@ -110,12 +110,14 @@ struct beacon_parameters {* @STATION_FLAG_SHORT_PREAMBLE: station is capable of receiving frames * with short preambles * @STATION_FLAG_WME: station is WME/QoS capable +* @STATION_FLAG_MFP: station uses management frame protection */ enum station_flags {STATION_FLAG_CHANGED =1 <<0 ,STATION_FLAG_AUTHORIZED =1 <<NL80211_STA_FLAG_AUTHORIZED ,STATION_FLAG_SHORT_PREAMBLE =1 <<NL80211_STA_FLAG_SHORT_PREAMBLE ,STATION_FLAG_WME =1 <<NL80211_STA_FLAG_WME , +STATION_FLAG_MFP =1 <<NL80211_STA_FLAG_MFP , };/**
net/mac80211/cfg.c +4 -0
@@ -618,6 +618,10 @@ static void sta_apply_parameters(struct sta->flags &= ~WLAN_STA_WME ;if (params->station_flags &STATION_FLAG_WME ) sta->flags |=WLAN_STA_WME ; + + sta->flags &= ~WLAN_STA_MFP ; +if (params->station_flags &STATION_FLAG_MFP ) + sta->flags |=WLAN_STA_MFP ;spin_unlock_bh (&sta->lock); }
net/mac80211/debugfs_sta.c +3 -2
@@ -74,14 +74,15 @@ static ssize_t sta_flags_read(struct filchar buf[100 ];struct sta_info *sta = file->private_data;u32 staflags =get_sta_flags (sta); -int res =scnprintf (buf,sizeof (buf),"%s%s%s%s%s%s%s" , +int res =scnprintf (buf,sizeof (buf),"%s%s%s%s%s%s%s%s" , staflags &WLAN_STA_AUTH ?"AUTH\n" :"" , staflags &WLAN_STA_ASSOC ?"ASSOC\n" :"" , staflags &WLAN_STA_PS ?"PS\n" :"" , staflags &WLAN_STA_AUTHORIZED ?"AUTHORIZED\n" :"" , staflags &WLAN_STA_SHORT_PREAMBLE ?"SHORT PREAMBLE\n" :"" , staflags &WLAN_STA_WME ?"WME\n" :"" , - staflags &WLAN_STA_WDS ?"WDS\n" :"" ); + staflags &WLAN_STA_WDS ?"WDS\n" :"" , + staflags &WLAN_STA_MFP ?"MFP\n" :"" );return simple_read_from_buffer (userbuf, count, ppos, buf, res); }STA_OPS (flags);
net/mac80211/sta_info.h +2 -0
@@ -34,6 +34,7 @@* @WLAN_STA_CLEAR_PS_FILT: Clear PS filter in hardware (using the * IEEE80211_TX_CTL_CLEAR_PS_FILT control flag) when the next * frame to this station is transmitted. +* @WLAN_STA_MFP: Management frame protection is used with this STA. */ enum ieee80211_sta_info_flags {WLAN_STA_AUTH =1 <<0 ,
@@ -46,6 +47,7 @@ enum ieee80211_sta_info_flags {WLAN_STA_WDS =1 <<7 ,WLAN_STA_PSPOLL =1 <<8 ,WLAN_STA_CLEAR_PS_FILT =1 <<9 , + WLAN_STA_MFP = 1<<10, };#define STA_TID_NUM 16
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
RFC PATCH 2/7 802.11w: CCMP for management frames
In reply to Jouni MalinenExtend CCMP to support encryption and decryption of unicast management frames.
net/mac80211/wpa.c +11 -5
@@ -299,7 +299,7 @@ static void ccmp_special_blocks(struct s int encrypted) {u16 fc; -int a4_included, qos_included; +int a4_included, qos_included, mgmt;u8 qos_tid, *fc_pos, *data, *sa, *da;int len_a;size_t data_len;
@@ -309,6 +309,7 @@ static void ccmp_special_blocks(struct s fc = fc_pos[0 ] ^ (fc_pos[1 ] <<8 ); a4_included = (fc & (IEEE80211_FCTL_TODS |IEEE80211_FCTL_FROMDS )) == (IEEE80211_FCTL_TODS |IEEE80211_FCTL_FROMDS ); + mgmt = (fc &IEEE80211_FCTL_FTYPE ) ==IEEE80211_FTYPE_MGMT ;ieee80211_get_hdr_info (skb, &sa, &da, &qos_tid, &data, &data_len); data_len -=CCMP_HDR_LEN + (encrypted ?CCMP_MIC_LEN :0 );
@@ -320,8 +321,10 @@ static void ccmp_special_blocks(struct s/* First block, b_0 */ b_0[0 ] =0x59 ;/* flags: Adata: 1, M: 011, L: 001 */ -/* Nonce: QoS Priority | A2 | PN */ - b_0[1 ] = qos_tid; +/* Nonce: Nonce Flags | A2 | PN +* Nonce Flags: Priority (b0..b3) | Management (b4) | Reserved (b5..b7) +*/ + b_0[1 ] = qos_tid | (mgmt <<4 );memcpy (&b_0[2 ], hdr->addr2,6 );memcpy (&b_0[8 ], pn,CCMP_PN_LEN );/* l(m) */
@@ -338,8 +341,11 @@ static void ccmp_special_blocks(struct s aad[0 ] =0 ;/* (len_a >> 8) & 0xff; */ aad[1 ] = len_a &0xff ; -/* Mask FC: zero subtype b4 b5 b6 */ - aad[2 ] = fc_pos[0 ] & ~(BIT (4 ) |BIT (5 ) |BIT (6 )); + aad[2 ] = fc_pos[0 ];/* FC type/subtype */ +if (!mgmt) { +/* Mask FC: zero subtype b4 b5 b6 */ + aad[2 ] &=BIT (4 ) |BIT (5 ) |BIT (6 ); + }/* Retry, PwrMgt, MoreData; set Protected */ aad[3 ] = (fc_pos[1 ] & ~(BIT (3 ) |BIT (4 ) |BIT (5 ))) |BIT (6 );memcpy (&aad[4 ], &hdr->addr1,18 );
net/mac80211/tx.c +25 -1
@@ -446,6 +446,26 @@ ieee80211_tx_h_ps_buf(struct ieee80211_treturn ieee80211_tx_h_multicast_ps_buf (tx); } +static int ieee80211_use_mfp (u16 fc,struct sta_info *sta,struct sk_buff *skb) +{ +u16 stype; + +if ((fc &IEEE80211_FCTL_FTYPE ) !=IEEE80211_FTYPE_MGMT ) +return 0 ; + +if (sta ==NULL || !test_sta_flags (sta,WLAN_STA_MFP )) +return 0 ; + + stype = fc &IEEE80211_FCTL_STYPE ; +if (stype !=IEEE80211_STYPE_DEAUTH && + stype !=IEEE80211_STYPE_DISASSOC && + stype !=IEEE80211_STYPE_ACTION ) +return 0 ; + +return 1 ; +} + +static ieee80211_tx_result ieee80211_tx_h_select_key (struct ieee80211_tx_data *tx) {
@@ -482,10 +502,14 @@ ieee80211_tx_h_select_key(struct ieee802 stype == IEEE80211_STYPE_AUTH)break ;case ALG_TKIP : -case ALG_CCMP :if (!WLAN_FC_DATA_PRESENT (fc)) tx->key =NULL ;break ; +case ALG_CCMP : +if (!WLAN_FC_DATA_PRESENT (fc) && + !ieee80211_use_mfp (fc, tx->sta, tx->skb)) + tx->key =NULL ; +break ; } }
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
RFC PATCH 3/7 802.11w: Add BIP (AES-128-CMAC)
In reply to Jouni MalinenImplement Broadcast/Multicast Integrity Protocol for management frame protection. This patch adds the needed definitions for the new information element (MMIE) and implementation for the new "encryption" type (though, BIP is actually not encrypting data, it provides only integrity protection). These routines will be used by a follow-on patch that enables BIP for multicast/broadcast robust management frames.
include/linux/ieee80211.h +10 -0
@@ -590,6 +590,15 @@ struct ieee80211_mgmt { } __attribute__ ((packed)); +/* Management MIC information element (IEEE 802.11w) */ +struct ieee80211_mmie { +u8 element_id; +u8 length; +u8 key_id[2 ];/* little endian, but may be unaligned */ +u8 sequence_number[6 ]; +u8 mic[8 ]; +} __attribute__ ((packed)); +/* Control frames */ struct ieee80211_rts {__le16 frame_control;
@@ -860,6 +869,7 @@ enum ieee80211_eid {WLAN_EID_HT_EXTRA_INFO =61 ,/* 802.11i */ WLAN_EID_RSN =48 , +WLAN_EID_MMIE =76 /* 802.11w */ ,WLAN_EID_WPA =221 ,WLAN_EID_GENERIC =221 , WLAN_EID_VENDOR_SPECIFIC = 221,
net/mac80211/key.h +10 -0
@@ -109,6 +109,16 @@ struct ieee80211_key {u8 tx_crypto_buf[6 *AES_BLOCK_LEN ];u8 rx_crypto_buf[6 *AES_BLOCK_LEN ]; } ccmp; +struct { +u8 tx_pn[6 ]; +u8 rx_pn[6 ]; +struct crypto_cipher *tfm; +u32 replays;/* dot11RSNAStatsCMACReplays */ +u32 icverrors;/* dot11RSNAStatsCMACICVErrors */ +/* scratch buffers for virt_to_page() (crypto API) */ +u8 tx_crypto_buf[2 *AES_BLOCK_LEN ]; +u8 rx_crypto_buf[2 *AES_BLOCK_LEN ]; + } aes_cmac; } u;/* number of times this key has been used */
net/mac80211/wpa.c +129 -0
149 lines not on this page · raw message
net/mac80211/wpa.h +5 -0
@@ -28,4 +28,9 @@ ieee80211_crypto_ccmp_encrypt(struct ieeieee80211_rx_result ieee80211_crypto_ccmp_decrypt (struct ieee80211_rx_data *rx); +ieee80211_tx_result +ieee80211_crypto_aes_cmac_encrypt (struct ieee80211_tx_data *tx); +ieee80211_rx_result +ieee80211_crypto_aes_cmac_decrypt (struct ieee80211_rx_data *rx); +#endif /* WPA_H */
net/mac80211/aes_cmac.c new file +135 -0
135 lines not on this page · raw message
net/mac80211/aes_cmac.h new file +19 -0
@@ -0,0 +1,19 @@ +/* +* Copyright 2008, Jouni Malinen <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License version 2 as +* published by the Free Software Foundation. +*/ + +#ifndef AES_CMAC_H +#define AES_CMAC_H + +#include <linux/crypto.h> + +struct crypto_cipher *ieee80211_aes_cmac_key_setup (const u8 key[]); +void ieee80211_aes_cmac (struct crypto_cipher *tfm,u8 *scratch,const u8 *aad, +const u8 *data,size_t data_len,u8 *mic); +void ieee80211_aes_cmac_key_free (struct crypto_cipher *tfm); + +#endif /* AES_CMAC_H */
net/mac80211/Makefile +1 -0
@@ -21,6 +21,7 @@ mac80211-y := \ michael.o \ tkip.o \ aes_ccm.o \ + aes_cmac.o \ cfg.o \ rx.o \ tx.o \
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
include/linux/ieee80211.h struct ieee80211_mgmt { · line 597
Quoted 6 lines
include/linux/ieee80211.h +5
-0+/* Management MIC information element (IEEE 802.11w) */ +struct ieee80211_mmie { +u8 element_id; +u8 length; +u8 key_id[2 ];/* little endian, but may be unaligned */
Since you say the struct is packed you should be able to use __le16 just fine.
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 600
Quoted 1 line
net/mac80211/wpa.c +1
-0+if ((tx->key->flags &KEY_FLAG_UPLOADED_TO_HARDWARE )) {
I think one set of parentheses suffices ;)
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 611
Quoted 6 lines
net/mac80211/wpa.c +6
-0+if (skb_tailroom (skb) <sizeof (*mmie)) { +if (pskb_expand_head (skb,skb_headroom (skb), +skb_tailroom (skb) +sizeof ((*mmie)), +GFP_ATOMIC ) <0 ) +return TX_DROP ; + }
I tried ensure pskb_expand_head is only called at most once when the frame is handed to master_start_xmit to avoid problems with skb truesize and such. Could you add the necessary space at that point already, possibly simply reserving max(mmic-len, mmie-len) or so instead of the current mmic-len (I think)? I'd hate to add back calls to pskb_expand_head at other places, and it's only 18 bytes so not really huge.
Review
Quoted 2 lines
(quoted diff) +2
-0+ if ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT) + return RX_CONTINUE;
Harvey just added a bunch of helper inlines to include/linux/ieee80211.h for stuff like that, I think you could use one of them here.
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 662
Quoted 5 lines
net/mac80211/wpa.c +5
-0+ mmie = (struct ieee80211_mmie *) + (skb->data + skb->len -sizeof (*mmie)); +if (mmie->element_id !=WLAN_EID_MMIE || + mmie->length !=sizeof (*mmie) -2 ) +return RX_DROP_UNUSABLE ;/* Invalid MMIE */
Is that what the draft says? Because iterating the IEs would be different, this means you could potentially have something like a vendor IE last that encapsulates the MMIE including type/len fields, which should probably not be used?
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 686
Quoted 2 lines
net/mac80211/wpa.c +2
-0+/* Remove MMIE */ +skb_trim (skb, skb->len -sizeof (*mmie));
Is that actually necessary? Since it's an IE, it should be ignored by all other code, no? Not that it matters though.
johannes
Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
Quoted 5 lines · Johannes Berg
Review
Quoted 2 lines
(quoted diff) +2
-0+ if ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT) + return RX_CONTINUE;Harvey just added a bunch of helper inlines to
include/linux/ieee80211.hfor stuff like that, I think you could use one of them here.
Afraid not, rx->fc is a u16. The helpers are all for __le16.
Harvey
Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
In reply to Johannes BergQuoted 8 lines · Johannes Berg
include/linux/ieee80211.h struct ieee80211_mgmt { · line 597
Quoted 5 lines
include/linux/ieee80211.h +5
-0+/* Management MIC information element (IEEE 802.11w) */ +struct ieee80211_mmie { +u8 element_id; +u8 length; +u8 key_id[2 ];/* little endian, but may be unaligned */ Since you say the struct is packed you should be able to use
__le16just fine.
Is that guaranteed to force all accesses of the field to not use 16-bit read/write?
Quoted 3 lines
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 600
Quoted 1 line
net/mac80211/wpa.c +1
-0+if ((tx->key->flags &KEY_FLAG_UPLOADED_TO_HARDWARE )) {I think one set of parentheses suffices ;)
Aah.. That's a copy-paste from something old.. I think I removed the IEEE80211_KEY_FLAG_GENERATE_IV flag from here for BIP.. I'm not completely sure yet, how we should have this, i.e., whether that flag should be used here or not. It is unclear what type of hwaccel, if any, vendors are going to implement for BIP.
Quoted 7 lines
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 611
Quoted 6 lines
net/mac80211/wpa.c +6
-0+if (skb_tailroom (skb) <sizeof (*mmie)) { +if (pskb_expand_head (skb,skb_headroom (skb), +skb_tailroom (skb) +sizeof ((*mmie)), +GFP_ATOMIC ) <0 ) +return TX_DROP ; + }
Quoted 7 lines
I tried ensure
pskb_expand_headis only called at most once when the frame is handed tomaster_start_xmitto avoid problems with skb truesize and such. Could you add the necessary space at that point already, possibly simply reservingmax(mmic-len, mmie-len)or so instead of the current mmic-len (I think)? I'd hate to add back calls topskb_expand_headat other places, and it's only 18 bytes so not really huge.
I thought about that for a moment, but then decided that it would be okay to just do this here since MMIE is larger than any other tailroom we have and there is next to no real use for multicast/broadcast management frames, so there is no need to optimize this. I don't see how this would require any other place to use pskb_expand_head.
Anyway, I would assume it would be possible to do this by changing IEEE80211_ENCRYPT_TAILROOM from 12 to 22 which would waste 10 bytes extra for every frame (well, not waste for BIP-protected frames but there are next to none of them).
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ if ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_MGMT) + return RX_CONTINUE;Harvey just added a bunch of helper inlines to
include/linux/ieee80211.hfor stuff like that, I think you could use one of them here.
I converted some of the places to use the new helpers, but did not go through all places. I would assume there is still places that can be made to use them, but as long as FC is available in host byte order, it is easier and faster to use it. Sure, if rx->fc were to disappear, that may make it more likely that these get changed ;-).
Quoted 10 lines
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 662
Quoted 5 lines
net/mac80211/wpa.c +5
-0+ mmie = (struct ieee80211_mmie *) + (skb->data + skb->len -sizeof (*mmie)); +if (mmie->element_id !=WLAN_EID_MMIE || + mmie->length !=sizeof (*mmie) -2 ) +return RX_DROP_UNUSABLE ;/* Invalid MMIE */ Is that what the draft says? Because iterating the IEs would be different, this means you could potentially have something like a vendor IE last that encapsulates the MMIE including type/len fields, which should probably not be used?
MMIE has to be the last "IE" in the frame. Sure, it would, in theory, be possible to receive a frame that does not have MMIE, but has "MMIE like" data in another IE. As long as we can make sure that this is reached only for frames that are received from MFP enabled AP, the simple solution of pointing to the end of the frame is enough. Otherwise, we would need to parse all the IEs and know about the start of IEs in all different types of Action frames.. That's not really something I would like to do.
Quoted 5 lines
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 686
Quoted 2 lines
net/mac80211/wpa.c +2
-0+/* Remove MMIE */ +skb_trim (skb, skb->len -sizeof (*mmie));Is that actually necessary? Since it's an IE, it should be ignored by all other code, no? Not that it matters though.
I don't think it is necessary in the sense that leaving the "IE" in would break anything. However, I do think this is the correct thing to do here and matches with what we do with TKIP/CCMP. MMIE is not really an IE, it is just a frame component that is made to look like one. The current IEEE 802.11w draft is bit confused about what MMIE is at places, but anyway, I would compare it to TKIP ICV and CCMP MIC in the end of the frames.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
Quoted 5 lines · On Tuesday 17 June 2008 20:06:10 Jouni Malinen wrote:
Quoted 2 lines
Since you say the struct is packed you should be able to use
__le16just fine.Is that guaranteed to force all accesses of the field to not use 16-bit read/write?
Yes.
Signature · 1 line
Greetings Michael.
Johannes Berg
maintainerRe: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
In reply to Jouni MalinenQuoted 6 lines
Aah.. That's a copy-paste from something old.. I think I removed the
IEEE80211_KEY_FLAG_GENERATE_IVflag from here for BIP.. I'm not completely sure yet, how we should have this, i.e., whether that flag should be used here or not. It is unclear what type of hwaccel, if any, vendors are going to implement for BIP.
Yeah, good point, I guess we should just not implement hwaccel until we find hardware that can handle it.
Quoted 8 lines
Quoted 7 lines
I tried ensure
pskb_expand_headis only called at most once when the frame is handed tomaster_start_xmitto avoid problems with skb truesize and such. Could you add the necessary space at that point already, possibly simply reservingmax(mmic-len, mmie-len)or so instead of the current mmic-len (I think)? I'd hate to add back calls topskb_expand_headat other places, and it's only 18 bytes so not really huge.
Quoted 5 lines
I thought about that for a moment, but then decided that it would be okay to just do this here since MMIE is larger than any other tailroom we have and there is next to no real use for multicast/broadcast management frames, so there is no need to optimize this. I don't see how this would require any other place to use
pskb_expand_head.
Well the thing is that you can't just call pskb_expand_head without orphaning the SKB first and all that truesize adjusting, because of truesize accounting, because it might now or later belong to a userspace socket.
Quoted 4 lines
Anyway, I would assume it would be possible to do this by changing
IEEE80211_ENCRYPT_TAILROOMfrom 12 to 22 which would waste 10 bytes extra for every frame (well, not waste for BIP-protected frames but there are next to none of them).
22? Is there something else on the frame in addition to the MMIE?
Quoted 5 lines
I converted some of the places to use the new helpers, but did not go through all places. I would assume there is still places that can be made to use them, but as long as FC is available in host byte order, it is easier and faster to use it. Sure, if
rx->fcwere to disappear, that may make it more likely that these get changed ;-).
Heh, ok, that's fine, I didn't realise that it was using the CPU order FC.
Quoted 5 lines
Quoted 4 lines
Is that what the draft says? Because iterating the IEs would be different, this means you could potentially have something like a vendor IE last that encapsulates the MMIE including type/len fields, which should probably not be used?
Quoted 8 lines
MMIE has to be the last "IE" in the frame. Sure, it would, in theory, be possible to receive a frame that does not have MMIE, but has "MMIE like" data in another IE. As long as we can make sure that this is reached only for frames that are received from MFP enabled AP, the simple solution of pointing to the end of the frame is enough. Otherwise, we would need to parse all the IEs and know about the start of IEs in all different types of Action frames.. That's not really something I would like to do.
Yeah, true, and we actually have that in another place too. If we then remove the MMIE, the IE sanity checks should catch the bad frame anyway, when/if it is parsed. Except we removed those because APs were sending bogus information. I'm fine with this, but we should be aware of the consequence.
Quoted 6 lines
Quoted 5 lines
net/mac80211/wpa.c ieee80211_crypto_ccmp_decrypt(struct iee · line 686
Quoted 2 lines
net/mac80211/wpa.c +2
-0+/* Remove MMIE */ +skb_trim (skb, skb->len -sizeof (*mmie));Is that actually necessary? Since it's an IE, it should be ignored by all other code, no? Not that it matters though.
Quoted 7 lines
I don't think it is necessary in the sense that leaving the "IE" in would break anything. However, I do think this is the correct thing to do here and matches with what we do with TKIP/CCMP. MMIE is not really an IE, it is just a frame component that is made to look like one. The current IEEE 802.11w draft is bit confused about what MMIE is at places, but anyway, I would compare it to TKIP ICV and CCMP MIC in the end of the frames.
Works for me.
johannes
Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
Quoted 4 lines · Johannes Berg
Well the thing is that you can't just call
pskb_expand_headwithout orphaning the SKB first and all that truesize adjusting, because of truesize accounting, because it might now or later belong to a userspace socket.
OK. I don't want to do that here, so I'll see what can be done with IEEE80211_ENCRYPT_TAILROOM.
Quoted 6 lines
Quoted 4 lines
Anyway, I would assume it would be possible to do this by changing
IEEE80211_ENCRYPT_TAILROOMfrom 12 to 22 which would waste 10 bytes extra for every frame (well, not waste for BIP-protected frames but there are next to none of them).22? Is there something else on the frame in addition to the MMIE?
Uhm.. Maybe I just cannot count anymore.. Or well, I did not remember where the 12 comes from and decided to add 4 because of that. Anyway, yes, now that I see that 12 is 8(MIC)+4(ICV) for TKIP, this 12 would indeed change to 18.
Quoted 5 lines
Yeah, true, and we actually have that in another place too. If we then remove the MMIE, the IE sanity checks should catch the bad frame anyway, when/if it is parsed. Except we removed those because APs were sending bogus information. I'm fine with this, but we should be aware of the consequence.
As long as we get the RX path implemented properly, this will only hit if there is a bug in an MFP-enabled AP or someone is trying to attack the network and both cases are very good candidates for dropping the frame anyway. The key selection is supposed to pick BIP key only if the sender (AP) has negotiated MFP and as such, all valid broadcast robust management frames are guaranteed to have MMIE in the end.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)
Quoted 7 lines
Quoted 6 lines
Yeah, true, and we actually have that in another place too. If we then remove the MMIE, the IE sanity checks should catch the bad frame anyway, when/if it is parsed. Except we removed those because APs were sending bogus information. I'm fine with this, but we should be aware of the consequence.
Quoted 6 lines
As long as we get the RX path implemented properly, this will only hit if there is a bug in an MFP-enabled AP or someone is trying to attack the network and both cases are very good candidates for dropping the frame anyway. The key selection is supposed to pick BIP key only if the sender (AP) has negotiated MFP and as such, all valid broadcast robust management frames are guaranteed to have MMIE in the end.
True. I was more thinking of somebody intentionally doing it in the AP to implement "802.11w in vendor IEs" or something like that but I guess that's unlikely to happen. And yeah, an attack won't work anyway since those frames would be rejected based on the wrong MIC.
johannes
RFC PATCH 4/7 802.11w: Use BIP (AES-128-CMAC)
In reply to Jouni MalinenAdd mechanism for managing BIP keys (IGTK) and integrate BIP into the TX/RX paths.
include/linux/ieee80211.h +1 -0
@@ -909,6 +909,7 @@ enum ieee80211_back_parties {/* reserved: 0x000FAC03 */ #define WLAN_CIPHER_SUITE_CCMP 0x000FAC04#define WLAN_CIPHER_SUITE_WEP104 0x000FAC05 +#define WLAN_CIPHER_SUITE_AES_CMAC 0x000FAC06#define WLAN_MAX_KEY_LEN 32
include/net/mac80211.h +2 -0
@@ -550,11 +550,13 @@ struct ieee80211_if_conf {* @ALG_WEP: WEP40 or WEP104 * @ALG_TKIP: TKIP * @ALG_CCMP: CCMP (AES) +* @ALG_AES_CMAC: AES-128-CMAC */ enum ieee80211_key_alg {ALG_WEP ,ALG_TKIP ,ALG_CCMP , +ALG_AES_CMAC , };
net/mac80211/cfg.c +31 -0
@@ -156,6 +156,9 @@ static int ieee80211_add_key(struct wiphcase WLAN_CIPHER_SUITE_CCMP : alg =ALG_CCMP ;break ; +case WLAN_CIPHER_SUITE_AES_CMAC : + alg =ALG_AES_CMAC ; +break ;default :return -EINVAL ; }
@@ -296,6 +299,17 @@ static int ieee80211_get_key(struct wiphelse params.cipher =WLAN_CIPHER_SUITE_WEP104 ;break ; +case ALG_AES_CMAC : + params.cipher =WLAN_CIPHER_SUITE_AES_CMAC ; + seq[0 ] = key->u.aes_cmac.tx_pn[5 ]; + seq[1 ] = key->u.aes_cmac.tx_pn[4 ]; + seq[2 ] = key->u.aes_cmac.tx_pn[3 ]; + seq[3 ] = key->u.aes_cmac.tx_pn[2 ]; + seq[4 ] = key->u.aes_cmac.tx_pn[1 ]; + seq[5 ] = key->u.aes_cmac.tx_pn[0 ]; + params.seq = seq; + params.seq_len =6 ; +break ; } params.key = key->conf.key;
@@ -325,6 +339,22 @@ static int ieee80211_config_default_key(return 0 ; } +static int ieee80211_config_default_mgmt_key (struct wiphy *wiphy, +struct net_device *dev, +u8 key_idx) +{ +struct ieee80211_sub_if_data *sdata; + +rcu_read_lock (); + + sdata =IEEE80211_DEV_TO_SUB_IF (dev); +ieee80211_set_default_mgmt_key (sdata, key_idx); + +rcu_read_unlock (); + +return 0 ; +} +static void sta_set_sinfo (struct sta_info *sta,struct station_info *sinfo) {struct ieee80211_sub_if_data *sdata = sta->sdata;
@@ -964,6 +994,7 @@ struct cfg80211_ops mac80211_config_ops .del_key = ieee80211_del_key, .get_key = ieee80211_get_key, .set_default_key = ieee80211_config_default_key, + .set_default_mgmt_key = ieee80211_config_default_mgmt_key, .add_beacon = ieee80211_add_beacon, .set_beacon = ieee80211_set_beacon, .del_beacon = ieee80211_del_beacon,
net/mac80211/debugfs_key.c +77 -2
126 lines not on this page · raw message
net/mac80211/key.h +6 -0
@@ -59,6 +59,8 @@ struct sta_info;* acceleration. * @KEY_FLAG_TODO_DEFKEY: Key is default key and debugfs needs to be updated. * @KEY_FLAG_TODO_ADD_DEBUGFS: Key needs to be added to debugfs. +* @KEY_FLAG_TODO_DEFMGMTKEY: Key is default management key and debugfs needs +* to be updated. */ enum ieee80211_internal_key_flags {KEY_FLAG_UPLOADED_TO_HARDWARE =BIT (0 ),
@@ -67,6 +69,7 @@ enum ieee80211_internal_key_flags {KEY_FLAG_TODO_HWACCEL_REMOVE =BIT (3 ),KEY_FLAG_TODO_DEFKEY =BIT (4 ),KEY_FLAG_TODO_ADD_DEBUGFS =BIT (5 ), + KEY_FLAG_TODO_DEFMGMTKEY = BIT(6), }; struct tkip_ctx {
@@ -137,6 +140,7 @@ struct ieee80211_key {struct dentry *tx_spec;struct dentry *rx_spec;struct dentry *replays; +struct dentry *icverrors;struct dentry *key;struct dentry *ifindex;int cnt;
@@ -163,6 +167,8 @@ void ieee80211_key_link(struct ieee80211 struct sta_info *sta);void ieee80211_key_free (struct ieee80211_key *key);void ieee80211_set_default_key (struct ieee80211_sub_if_data *sdata,int idx); +void ieee80211_set_default_mgmt_key (struct ieee80211_sub_if_data *sdata, +int idx);void ieee80211_free_keys (struct ieee80211_sub_if_data *sdata);void ieee80211_enable_keys (struct ieee80211_sub_if_data *sdata);void ieee80211_disable_keys (struct ieee80211_sub_if_data *sdata);
net/mac80211/rx.c +94 -9
155 lines not on this page · raw message
net/mac80211/tx.c +10 -0
@@ -477,6 +477,9 @@ ieee80211_tx_h_select_key(struct ieee802 tx->key =NULL ; else if (tx->sta && (key = rcu_dereference(tx->sta->key))) tx->key = key; + else if ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT && + (key = rcu_dereference(tx->sdata->default_mgmt_key))) + tx->key = key; else if ((key = rcu_dereference(tx->sdata->default_key))) tx->key = key; else if (tx->sdata->drop_unencrypted &&
@@ -510,6 +513,11 @@ ieee80211_tx_h_select_key(struct ieee802 !ieee80211_use_mfp(fc, tx->sta, tx->skb)) tx->key = NULL;break ; +case ALG_AES_CMAC : +if ((fc &IEEE80211_FCTL_FTYPE ) != +IEEE80211_FTYPE_MGMT ) + tx->key =NULL ; +break ; } }
@@ -771,6 +779,8 @@ ieee80211_tx_h_encrypt(struct ieee80211_return ieee80211_crypto_tkip_encrypt (tx);case ALG_CCMP :return ieee80211_crypto_ccmp_encrypt (tx); +case ALG_AES_CMAC : +return ieee80211_crypto_aes_cmac_encrypt (tx); }/* not reached */
net/mac80211/key.c +56 -2
125 lines not on this page · raw message
net/mac80211/ieee80211_i.h +4 -1
@@ -429,8 +429,10 @@ struct ieee80211_sub_if_data {unsigned int fragment_next;#define NUM_DEFAULT_KEYS 4 -struct ieee80211_key *keys[NUM_DEFAULT_KEYS ]; +#define NUM_DEFAULT_MGMT_KEYS 2 +struct ieee80211_key *keys[NUM_DEFAULT_KEYS +NUM_DEFAULT_MGMT_KEYS ];struct ieee80211_key *default_key; +struct ieee80211_key *default_mgmt_key;/* * BSS configuration for this interface.
@@ -492,6 +494,7 @@ struct ieee80211_sub_if_data {struct dentry *mode; } monitor;struct dentry *default_key; +struct dentry *default_mgmt_key; } debugfs;#ifdef CONFIG_MAC80211_MESH
include/net/cfg80211.h +5 -0
@@ -306,6 +306,8 @@ struct wiphy;* * @set_default_key: set the default key on an interface * +* @set_default_mgmt_key: set the default management frame key on an interface +* * @add_beacon: Add a beacon with given parameters, @head, @interval * and @dtim_period will be valid, @tail is optional. * @set_beacon: Change the beacon parameters for an access point mode
@@ -341,6 +343,9 @@ struct cfg80211_ops {int (*set_default_key)(struct wiphy *wiphy,struct net_device *netdev,u8 key_index); +int (*set_default_mgmt_key)(struct wiphy *wiphy, +struct net_device *netdev, +u8 key_index);int (*add_beacon)(struct wiphy *wiphy,struct net_device *dev,struct beacon_parameters *info);
net/mac80211/debugfs_key.h +10 -0
@@ -6,6 +6,10 @@ void ieee80211_debugfs_key_add(struct ievoid ieee80211_debugfs_key_remove (struct ieee80211_key *key);void ieee80211_debugfs_key_add_default (struct ieee80211_sub_if_data *sdata);void ieee80211_debugfs_key_remove_default (struct ieee80211_sub_if_data *sdata); +void ieee80211_debugfs_key_add_mgmt_default ( +struct ieee80211_sub_if_data *sdata); +void ieee80211_debugfs_key_remove_mgmt_default ( +struct ieee80211_sub_if_data *sdata);void ieee80211_debugfs_key_sta_del (struct ieee80211_key *key,struct sta_info *sta);#else
@@ -19,6 +23,12 @@ static inline void ieee80211_debugfs_keystatic inline void ieee80211_debugfs_key_remove_default (struct ieee80211_sub_if_data *sdata) {} +static inline void ieee80211_debugfs_key_add_mgmt_default ( +struct ieee80211_sub_if_data *sdata) +{} +static inline void ieee80211_debugfs_key_remove_mgmt_default ( +struct ieee80211_sub_if_data *sdata) +{}static inline void ieee80211_debugfs_key_sta_del (struct ieee80211_key *key,struct sta_info *sta) {}
net/wireless/nl80211.c +21 -7
@@ -87,6 +87,8 @@ static struct nla_policy nl80211_policy[ [NL80211_ATTR_MESH_ID ] = { .type =NLA_BINARY , .len = IEEE80211_MAX_MESH_ID_LEN }, [NL80211_ATTR_MPATH_NEXT_HOP] = { .type = NLA_U32 }, + + [NL80211_ATTR_KEY_DEFAULT_MGMT] = { .type = NLA_FLAG }, };/* message building helper */
@@ -537,7 +539,7 @@ static int nl80211_get_key(struct sk_bufif (info->attrs[NL80211_ATTR_KEY_IDX ]) key_idx =nla_get_u8 (info->attrs[NL80211_ATTR_KEY_IDX ]); -if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ;if (info->attrs[NL80211_ATTR_MAC ])
@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_bufint err;struct net_device *dev;u8 key_idx; +int (*func)(struct wiphy *wiphy,struct net_device *netdev, +u8 key_index);if (!info->attrs[NL80211_ATTR_KEY_IDX ])return -EINVAL ; key_idx =nla_get_u8 (info->attrs[NL80211_ATTR_KEY_IDX ]); -if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ;/* currently only support setting default key */ -if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ]) +if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ] && + !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT ])return -EINVAL ; err =get_drv_dev_by_info_ifindex (info, &drv, &dev);if (err)return err; -if (!drv->ops->set_default_key) { +if (info->attrs[NL80211_ATTR_KEY_DEFAULT ]) + func = drv->ops->set_default_key; +else + func = drv->ops->set_default_mgmt_key; + +if (!func) { err = -EOPNOTSUPP ; goto out; }rtnl_lock (); - err = drv->ops->set_default_key (&drv->wiphy, dev, key_idx); + err =func (&drv->wiphy, dev, key_idx);rtnl_unlock (); out:
@@ -662,7 +672,7 @@ static int nl80211_new_key(struct sk_bufif (info->attrs[NL80211_ATTR_MAC ]) mac_addr =nla_data (info->attrs[NL80211_ATTR_MAC ]); -if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ;/*
@@ -693,6 +703,10 @@ static int nl80211_new_key(struct sk_bufif (params.key_len !=13 )return -EINVAL ;break ; +case WLAN_CIPHER_SUITE_AES_CMAC : +if (params.key_len !=16 ) +return -EINVAL ; +break ;default :return -EINVAL ; }
@@ -727,7 +741,7 @@ static int nl80211_del_key(struct sk_bufif (info->attrs[NL80211_ATTR_KEY_IDX ]) key_idx =nla_get_u8 (info->attrs[NL80211_ATTR_KEY_IDX ]); -if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ;if (info->attrs[NL80211_ATTR_MAC ])
include/linux/nl80211.h +4 -2
@@ -51,8 +51,8 @@* * @NL80211_CMD_GET_KEY: Get sequence counter information for a key specified * by %NL80211_ATTR_KEY_IDX and/or %NL80211_ATTR_MAC. -* @NL80211_CMD_SET_KEY: Set key attributes %NL80211_ATTR_KEY_DEFAULT or -* %NL80211_ATTR_KEY_THRESHOLD. +* @NL80211_CMD_SET_KEY: Set key attributes %NL80211_ATTR_KEY_DEFAULT, +* %NL80211_ATTR_KEY_DEFAULT_MGMT, or %NL80211_ATTR_KEY_THRESHOLD. * @NL80211_CMD_NEW_KEY: add a key with given %NL80211_ATTR_KEY_DATA, * %NL80211_ATTR_KEY_IDX, %NL80211_ATTR_MAC and %NL80211_ATTR_KEY_CIPHER * attributes.
@@ -235,6 +235,8 @@ enum nl80211_attrs {NL80211_ATTR_MPATH_NEXT_HOP ,NL80211_ATTR_MPATH_INFO , +NL80211_ATTR_KEY_DEFAULT_MGMT , +/* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST,
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)
Quoted 12 lines
net/wireless/nl80211.c +2
-0@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_bufint err;struct net_device *dev;u8 key_idx; +int (*func)(struct wiphy *wiphy,struct net_device *netdev, +u8 key_index);if (!info->attrs[NL80211_ATTR_KEY_IDX ])return -EINVAL ; key_idx =nla_get_u8 (info->attrs[NL80211_ATTR_KEY_IDX ]);
net/wireless/nl80211.c static int nl80211_set_key(struct sk_buf · line 622
Quoted 10 lines
net/wireless/nl80211.c +3
-2-if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ;/* currently only support setting default key */ -if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ]) +if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ] && + !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT ])return -EINVAL ;
I think this should probably check the key index depending on the type, i.e. only permit 4 and 5 for mgmt and 0-3 for data keys.
johannes
Re: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)
Quoted 11 lines · Johannes Berg
net/wireless/nl80211.c static int nl80211_set_key(struct sk_buf · line 609
Quoted 8 lines
net/wireless/nl80211.c +3
-2@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_buf -if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ; -if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ]) +if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ] && + !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT ])I think this should probably check the key index depending on the type, i.e. only permit 4 and 5 for mgmt and 0-3 for data keys.
Yes, I started doing that, but did not cover all places yet. It's somewhat unclear to me where this type of validation should live, i.e., what piece of code should know that key indexes 4 and 5 are used for IGTK at this point taken into account that the index could actually be 0..65535.. Anyway, it may be safer to do it here than to trust on other places being able to handle odd indexes for data frame TX key index.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)
Quoted 14 lines · Jouni Malinen
Quoted 11 lines · Johannes Berg
net/wireless/nl80211.c static int nl80211_set_key(struct sk_buf · line 609
Quoted 8 lines
net/wireless/nl80211.c +3
-2@@ -603,30 +605,38 @@ static int nl80211_set_key(struct sk_buf -if (key_idx >3 ) +if (key_idx >5 )return -EINVAL ; -if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ]) +if (!info->attrs[NL80211_ATTR_KEY_DEFAULT ] && + !info->attrs[NL80211_ATTR_KEY_DEFAULT_MGMT ])I think this should probably check the key index depending on the type, i.e. only permit 4 and 5 for mgmt and 0-3 for data keys.
Quoted 6 lines
Yes, I started doing that, but did not cover all places yet. It's somewhat unclear to me where this type of validation should live, i.e., what piece of code should know that key indexes 4 and 5 are used for IGTK at this point taken into account that the index could actually be 0..65535.. Anyway, it may be safer to do it here than to trust on other places being able to handle odd indexes for data frame TX key index.
I tend to think cfg80211 should do it since I don't see a reasonable use for it when the specs/drafts don't specify anything else. I think this is part of the mistake WEXT made with requiring the drivers to check the input sanity everywhere and duplicating that code into all drivers etc.
johannes
Johannes Berg
maintainerRe: [RFC PATCH 4/7] 802.11w: Use BIP (AES-128-CMAC)
In reply to Jouni MalinenOne more thing:
Quoted 4 lines
net/mac80211/rx.c +4
-0+/* Get the BIP key index from MMIE; return -1 if this is not a BIP frame */ +static int ieee80211_get_mmie_keyidx (struct sk_buff *skb) +{ +struct ieee80211_mgmt *hdr = (struct ieee80211_mgmt *) skb->data;
net/mac80211/rx.c ieee80211_rx_h_check(struct ieee80211_rx · line 538
Quoted 10 lines
net/mac80211/rx.c +10
-0+struct ieee80211_mmie *mmie; + +if (skb->len <24 +sizeof (*mmie) || + !is_multicast_ether_addr (hdr->da)) +return -1 ; + +if (!ieee80211_is_disassoc (hdr->frame_control) && + !ieee80211_is_deauth (hdr->frame_control) && + !ieee80211_is_action (hdr->frame_control)) +return -1 ;/* not a robust management frame */
If you reorder the code a bit, you can use the helper below here as well.
net/mac80211/rx.c ieee80211_802_1x_port_control(struct iee · line 1140
Quoted 6 lines
net/mac80211/rx.c +6
-0+static int ieee80211_is_robust_mgmt_frame (__le16 fc) +{ +return ieee80211_is_disassoc (fc) || +ieee80211_is_deauth (fc) || +ieee80211_is_action (fc); +}
johannes
RFC PATCH 5/7 802.11w: WEXT parameter for setting mgmt cipher
In reply to Jouni MalinenAdd a new IW_AUTH parameter for setting cipher suite for multicast/broadcast management frames. This is for full-mac drivers that take care of RSN IE generation for (re)association request frames.
include/linux/wireless.h +4 -1
@@ -577,18 +577,21 @@#define IW_AUTH_RX_UNENCRYPTED_EAPOL 8#define IW_AUTH_ROAMING_CONTROL 9#define IW_AUTH_PRIVACY_INVOKED 10 +#define IW_AUTH_CIPHER_GROUP_MGMT 11/* IW_AUTH_WPA_VERSION values (bit field) */ #define IW_AUTH_WPA_VERSION_DISABLED 0x00000001#define IW_AUTH_WPA_VERSION_WPA 0x00000002#define IW_AUTH_WPA_VERSION_WPA2 0x00000004 -/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */ +/* IW_AUTH_PAIRWISE_CIPHER, IW_AUTH_GROUP_CIPHER, and IW_AUTH_CIPHER_GROUP_MGMT +* 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 +#define IW_AUTH_CIPHER_AES_CMAC 0x00000020/* IW_AUTH_KEY_MGMT values (bit field) */ #define IW_AUTH_KEY_MGMT_802_1X 1
net/mac80211/wext.c +1 -0
@@ -966,6 +966,7 @@ static int ieee80211_ioctl_siwauth(struccase IW_AUTH_WPA_ENABLED :case IW_AUTH_RX_UNENCRYPTED_EAPOL :case IW_AUTH_KEY_MGMT : +case IW_AUTH_CIPHER_GROUP_MGMT :break ;case IW_AUTH_DROP_UNENCRYPTED : sdata->drop_unencrypted = !!data->value;
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
RFC PATCH 6/7 802.11w: WEXT configuration for IGTK
In reply to Jouni MalinenAdded new SIOCSIWENCODEEXT algorithm for configuring BIP (AES-CMAC) keys (IGTK).
include/linux/wireless.h +1 -0
@@ -615,6 +615,7 @@#define IW_ENCODE_ALG_TKIP 2#define IW_ENCODE_ALG_CCMP 3#define IW_ENCODE_ALG_PMK 4 +#define IW_ENCODE_ALG_AES_CMAC 5/* struct iw_encode_ext ->ext_flags */ #define IW_ENCODE_EXT_TX_SEQ_VALID 0x00000001#define IW_ENCODE_EXT_RX_SEQ_VALID 0x00000002
net/mac80211/wext.c +48 -14
87 lines not on this page · raw message
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
RFC PATCH 7/7 802.11w: Configuration of MFP disabled/optional/required
In reply to Jouni MalinenAdd new WEXT IW_AUTH_* parameter for setting MFP
disabled/optional/required.
include/linux/wireless.h +6 -0
@@ -578,6 +578,7 @@#define IW_AUTH_ROAMING_CONTROL 9#define IW_AUTH_PRIVACY_INVOKED 10#define IW_AUTH_CIPHER_GROUP_MGMT 11 +#define IW_AUTH_MFP 12/* IW_AUTH_WPA_VERSION values (bit field) */ #define IW_AUTH_WPA_VERSION_DISABLED 0x00000001
@@ -607,6 +608,11 @@#define IW_AUTH_ROAMING_DISABLE 1/* user space program used for roaming * control */ +/* IW_AUTH_MFP (management frame protection) values */ +#define IW_AUTH_MFP_DISABLED 0/* MFP disabled */ +#define IW_AUTH_MFP_OPTIONAL 1/* MFP optional */ +#define IW_AUTH_MFP_REQUIRED 2/* MFP required */ +/* SIOCSIWENCODEEXT definitions */ #define IW_ENCODE_SEQ_MAX_SIZE 8/* struct iw_encode_ext ->alg */
net/mac80211/ieee80211_i.h +5 -0
@@ -372,6 +372,11 @@ struct ieee80211_if_sta {int auth_alg;/* currently used IEEE 802.11 authentication algorithm */ int auth_transaction; +#define IEEE80211_MFP_DISABLED 0 +#define IEEE80211_MFP_OPTIONAL 1 +#define IEEE80211_MFP_REQUIRED 2 +int mfp;/* management frame protection */ +unsigned long ibss_join_req;struct sk_buff *probe_resp;/* ProbeResp template for IBSS */ u32 supp_rates_bits[IEEE80211_NUM_BANDS ];
net/mac80211/wext.c +7 -0
@@ -1003,6 +1003,13 @@ static int ieee80211_ioctl_siwauth(strucelse ret = -EOPNOTSUPP ;break ; +case IW_AUTH_MFP : +if (sdata->vif.type ==IEEE80211_IF_TYPE_STA || + sdata->vif.type ==IEEE80211_IF_TYPE_IBSS ) + sdata->u.sta.mfp = data->value; +else + ret = -EOPNOTSUPP ; +break ;default : ret = -EOPNOTSUPP ;break ;
--
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: [RFC PATCH 7/7] 802.11w: Configuration of MFP disabled/optional/required
net/mac80211/ieee80211_i.h struct ieee80211_if_sta { · line 378
Quoted 5 lines
net/mac80211/ieee80211_i.h +4
-0+#define IEEE80211_MFP_DISABLED 0 +#define IEEE80211_MFP_OPTIONAL 1 +#define IEEE80211_MFP_REQUIRED 2 +int mfp;/* management frame protection */
Maybe an enum would be good?
net/mac80211/wext.c static int ieee80211_ioctl_siwauth(struc · line 1009
Quoted 10 lines
net/mac80211/wext.c +4
-0@@ -1003,6 +1003,13 @@ static int ieee80211_ioctl_siwauth(strucelse ret = -EOPNOTSUPP ;break ; +case IW_AUTH_MFP : +if (sdata->vif.type ==IEEE80211_IF_TYPE_STA || + sdata->vif.type ==IEEE80211_IF_TYPE_IBSS ) + sdata->u.sta.mfp = data->value;
and shouldn't that be used somewhere?
johannes
Re: [RFC PATCH 7/7] 802.11w: Configuration of MFP disabled/optional/required
Quoted 6 lines · Johannes Berg
net/mac80211/ieee80211_i.h struct ieee80211_if_sta { · line 378
Quoted 4 lines
net/mac80211/ieee80211_i.h +4
-0+#define IEEE80211_MFP_DISABLED 0 +#define IEEE80211_MFP_OPTIONAL 1 +#define IEEE80211_MFP_REQUIRED 2 +int mfp;/* management frame protection */ Maybe an enum would be good?
Sure.
Quoted 8 lines
net/mac80211/wext.c static int ieee80211_ioctl_siwauth(struc · line 1009
Quoted 6 lines
net/mac80211/wext.c +4
-0+case IW_AUTH_MFP : +if (sdata->vif.type ==IEEE80211_IF_TYPE_STA || + sdata->vif.type ==IEEE80211_IF_TYPE_IBSS ) + sdata->u.sta.mfp = data->value;and shouldn't that be used somewhere?
Well, yes. This is still somewhat unclear area to me and in particular, I'm not sure whether the IW_AUTH_MFP parameter will end up being used in mac80211. It would be used if the kernel code (or firmware in fullmac designs) would select the AP. mac80211 may need another configuration item to set whether MFP was actually negotiated during association. This has changed a bit in the latest 802.11w draft and I haven't yet updated my implementation to use the new mechanism. For the time being, sdata->u.sta.mfp is more or less a placeholder for something that may disappear or change to something else..
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: [RFC PATCH 7/7] 802.11w: Configuration of MFP disabled/optional/required
Quoted 10 lines
Quoted 9 lines
net/mac80211/wext.c static int ieee80211_ioctl_siwauth(struc · line 1009
Quoted 7 lines
net/mac80211/wext.c +4
-0+case IW_AUTH_MFP : +if (sdata->vif.type ==IEEE80211_IF_TYPE_STA || + sdata->vif.type ==IEEE80211_IF_TYPE_IBSS ) + sdata->u.sta.mfp = data->value;and shouldn't that be used somewhere?
Quoted 9 lines
Well, yes. This is still somewhat unclear area to me and in particular, I'm not sure whether the
IW_AUTH_MFPparameter will end up being used in mac80211. It would be used if the kernel code (or firmware in fullmac designs) would select the AP. mac80211 may need another configuration item to set whether MFP was actually negotiated during association. This has changed a bit in the latest 802.11w draft and I haven't yet updated my implementation to use the new mechanism. For the time being,sdata->u.sta.mfpis more or less a placeholder for something that may disappear or change to something else..
Ok, yeah, that explains why I wasn't really able to see how it determined whether MFP was optional/required for a certain association etc.
johannes
Johannes Berg
maintainerQuoted 10 lines
The current version is relatively complete for mac80211, but there are still couple of known missing functions and I've done only very limited testing so far. I was able to send and receive both CCMP and BIP protected deauthentication frames and based on a sniffer log, the frames looked correct. All this is with
mac80211_hwsimand software crypto. It is unclear whether this can be used as-is with devices that use hwaccel for crypto at least before the low-level drivers and/or firmware have been modified to cope with the possibility of CCMP being used with management frames.
b43 will be able to do this for sure, it doesn't care what sort of frame is encrypted. The question is how drivers can indicate support/non-support I guess.
johannes
Quoted 8 lines · Johannes Berg
Quoted 4 lines
crypto. It is unclear whether this can be used as-is with devices that use hwaccel for crypto at least before the low-level drivers and/or firmware have been modified to cope with the possibility of CCMP being used with management frames.
b43 will be able to do this for sure, it doesn't care what sort of frame is encrypted. The question is how drivers can indicate support/non-support I guess.
One of the problems is that CCMP as defined in IEEE 802.11i for data frames is not compatible with CCMP as defined in IEEE 802.11w for management frames (there are small differences in AAD and nonce generation). As such, if the hardware/firmware is trying to decrypt received CCMP protected frames based on the IEEE 802.11i rules even if the frame is a management frame, the end result is not going to be very good.. It would be necessary to either disable hwaccel for CCMP decryption for management frames (if possible) or add software workaround to re-encrypt the management frame incorrectly (to undo hardware/firmware operations) and then decrypt it in software..
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 11 lines · On Tuesday 17 June 2008 19:47:49 Jouni Malinen wrote:
Quoted 8 lines · Johannes Berg
Quoted 4 lines
crypto. It is unclear whether this can be used as-is with devices that use hwaccel for crypto at least before the low-level drivers and/or firmware have been modified to cope with the possibility of CCMP being used with management frames.
b43 will be able to do this for sure, it doesn't care what sort of frame is encrypted. The question is how drivers can indicate support/non-support I guess.
Quoted 7 lines
One of the problems is that CCMP as defined in IEEE 802.11i for data frames is not compatible with CCMP as defined in IEEE 802.11w for management frames (there are small differences in AAD and nonce generation). As such, if the hardware/firmware is trying to decrypt received CCMP protected frames based on the IEEE 802.11i rules even if the frame is a management frame, the end result is not going to be very good..
Well, as long as the checksum will fail in that case we're OK for b43, as the driver will notify the need for software crypto for those packets.
Signature · 1 line
Greetings Michael.
Johannes Berg
maintainerQuoted 12 lines · Michael Buesch
Quoted 11 lines · On Tuesday 17 June 2008 19:47:49 Jouni Malinen wrote:
Quoted 8 lines · Johannes Berg
Quoted 4 lines
crypto. It is unclear whether this can be used as-is with devices that use hwaccel for crypto at least before the low-level drivers and/or firmware have been modified to cope with the possibility of CCMP being used with management frames.
b43 will be able to do this for sure, it doesn't care what sort of frame is encrypted. The question is how drivers can indicate support/non-support I guess.
Quoted 7 lines
Quoted 7 lines
One of the problems is that CCMP as defined in IEEE 802.11i for data frames is not compatible with CCMP as defined in IEEE 802.11w for management frames (there are small differences in AAD and nonce generation). As such, if the hardware/firmware is trying to decrypt received CCMP protected frames based on the IEEE 802.11i rules even if the frame is a management frame, the end result is not going to be very good..
Oh, ok, never mind then. Probably not worth accelerating anyway.
Quoted 2 lines
Well, as long as the checksum will fail in that case we're OK for b43, as the driver will notify the need for software crypto for those packets.
I don't think it'll try to decrypt them anyway but I thought we could at least use it to encrypt.
johannes
Quoted 2 lines · Michael Buesch
Well, as long as the checksum will fail in that case we're OK for b43, as the driver will notify the need for software crypto for those packets.
Yes, MIC won't match (or well, in theory it could, but in practice..) and if the original frame is available after failed hw-decryption attempt, this is indeed all that's needed here. Some hardware designs are not able to deliver the unmodified frame due to the way AES hwaccel is implemented in them and that gets bit tricky to handle in software for IEEE 802.11w.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 11 lines · On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
Quoted 2 lines · Michael Buesch
Well, as long as the checksum will fail in that case we're OK for b43, as the driver will notify the need for software crypto for those packets.
Yes, MIC won't match (or well, in theory it could, but in practice..) and if the original frame is available after failed hw-decryption attempt, this is indeed all that's needed here. Some hardware designs are not able to deliver the unmodified frame due to the way AES hwaccel is implemented in them and that gets bit tricky to handle in software for IEEE 802.11w.
Yeah I see. Probably need to disable HW crypto for them. (If firmware modification to pass MGMT frames untouched is impossible)
Signature · 1 line
Greetings Michael.
Johannes Berg
maintainerQuoted 13 lines · Michael Buesch
Quoted 11 lines · On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
Quoted 2 lines · Michael Buesch
Well, as long as the checksum will fail in that case we're OK for b43, as the driver will notify the need for software crypto for those packets.
Yes, MIC won't match (or well, in theory it could, but in practice..) and if the original frame is available after failed hw-decryption attempt, this is indeed all that's needed here. Some hardware designs are not able to deliver the unmodified frame due to the way AES hwaccel is implemented in them and that gets bit tricky to handle in software for IEEE 802.11w.
Quoted 2 lines
Yeah I see. Probably need to disable HW crypto for them. (If firmware modification to pass MGMT frames untouched is impossible)
Broadcom's firmware already passes MGMT frames through untouched (unless they are auth frames and those aren't protected in 802.11w I think.)
johannes
Quoted 14 lines · On Tuesday 17 June 2008 20:31:47 Johannes Berg wrote:
Quoted 13 lines · Michael Buesch
Quoted 11 lines · On Tuesday 17 June 2008 20:23:22 Jouni Malinen wrote:
Quoted 2 lines · Michael Buesch
Well, as long as the checksum will fail in that case we're OK for b43, as the driver will notify the need for software crypto for those packets.
Yes, MIC won't match (or well, in theory it could, but in practice..) and if the original frame is available after failed hw-decryption attempt, this is indeed all that's needed here. Some hardware designs are not able to deliver the unmodified frame due to the way AES hwaccel is implemented in them and that gets bit tricky to handle in software for IEEE 802.11w.
Quoted 5 lines
Quoted 2 lines
Yeah I see. Probably need to disable HW crypto for them. (If firmware modification to pass MGMT frames untouched is impossible)
Broadcom's firmware already passes MGMT frames through untouched (unless they are auth frames and those aren't protected in 802.11w I think.)
Ah I see. Makes sense.
Signature · 1 line
Greetings Michael.
Quoted 4 lines · Jouni Malinen
This is the first and still quite preliminary version of changes to introduce IEEE 802.11w (management frame protection) support into mac80211. As such, I'm mainly looking for comments on the current design to help me in finalizing and cleaning up the patches.
Thanks for the comments! I think I resolved most of them and made my current set of patches available at http://w1.fi/mfp/ in order to avoid having to post them to the list after all minor changes. I'll send new versions to the list once I get some more known issues resolved and the patches are closer to being ready to be included in wireless-testing.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerQuoted 5 lines
This patch set does not address the issues found in configuring default keys for monitor interfaces, i.e., this still needs a workaround in hostapd to set IGTK for both wlan# and mon.wlan#. In addition, the debugfs directory is left behind when the monitor interface is removed.
Can you try this patch?
http://johannes.sipsolutions.net/patches/kernel/all/2008-07-09-17%3a38/021-mac80211-inject-sdata.patch
It should use the sdata from the TA instead of the monitor when treating injecting frames, where possible.
johannes
Johannes Berg
maintainerQuoted 10 lines · Johannes Berg
Quoted 4 lines
This patch set does not address the issues found in configuring default keys for monitor interfaces, i.e., this still needs a workaround in hostapd to set IGTK for both wlan# and mon.wlan#. In addition, the debugfs directory is left behind when the monitor interface is removed.
Can you try this patch?
http://johannes.sipsolutions.net/patches/kernel/all/2008-07-09-17%3a38/021-mac80211-inject-sdata.patchIt should use the sdata from the TA instead of the monitor when treating injecting frames, where possible.
Just realised that it doesn't handle VLANs properly. Could you add a static MAC/VLAN mapping to hostapd to make VLANs possible without setting up radius? :)
johannes
Quoted 3 lines · Johannes Berg
Just realised that it doesn't handle VLANs properly. Could you add a static MAC/VLAN mapping to hostapd to make VLANs possible without setting up radius? :)
Well, I could, but this doesn't sound like a real world feature.. I would assume it would be relatively simple addition to the file-based MAC ACL (accept_mac_file) to allow optional listing of VLAN ID that would then be used as if it came from the authentication server.
Anyway, It shouldn't require much complexity to set up FreeRADIUS with two users that are assigned to different VLAN groups. hostapd.conf lists the needed tunnel attributes for this.. ;-)
Signature · 1 line
Jouni Malinen PGP id EFC895FA
VLAN testing (and mac80211_hwsim test cases in general)
In reply to Johannes BergQuoted 3 lines · Johannes Berg
Just realised that it doesn't handle VLANs properly. Could you add a static MAC/VLAN mapping to hostapd to make VLANs possible without setting up radius? :)
In order to get more people testing this, I finally gave in and added that option into hostapd ;-), so now you can do this without having to set up a RADIUS server. To make things even easier, I made an example configuration and test instructions for mac80211_hwsim available:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests/0002-vlan
I started collecting mac80211_hwsim test cases into mac80211_hwsim/tests directory in hostap.git. I hope this will make it easy for developers to test mac80211 features. For the time being, this is for manual testing, but hopefully at some point these tests can be run automatically with a script (e.g., daily or whenever wireless-testing changes, etc.). The test.txt file includes the commands needed to run both the AP and client(s). Some additional infrastructure would be needed to validate the end results and start/stop wpa_supplicant and hostapd in the background.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Johannes Berg
maintainerRe: VLAN testing (and mac80211_hwsim test cases in general)
Quoted 6 lines · Jouni Malinen
Quoted 3 lines · Johannes Berg
Just realised that it doesn't handle VLANs properly. Could you add a static MAC/VLAN mapping to hostapd to make VLANs possible without setting up radius? :)
Quoted 6 lines
In order to get more people testing this, I finally gave in and added that option into hostapd ;-), so now you can do this without having to set up a RADIUS server. To make things even easier, I made an example configuration and test instructions for
mac80211_hwsimavailable:http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests/0002-vlan
Awesome, thanks. I'll look at the code, it seems to me that I actually want to be able to configure to not reject unknown stations but put them into their own VLAN, or something, then this feature could actually be useful in production.
Quoted 9 lines
I started collecting
mac80211_hwsimtest cases into mac80211_hwsim/tests directory in hostap.git. I hope this will make it easy for developers to test mac80211 features. For the time being, this is for manual testing, but hopefully at some point these tests can be run automatically with a script (e.g., daily or whenever wireless-testing changes, etc.). The test.txt file includes the commands needed to run both the AP and client(s). Some additional infrastructure would be needed to validate the end results and start/stopwpa_supplicantand hostapd in the background.
I'm not so much worried about starting/stopping them, you can easily write a small program or so that simply forks and then runs them in the foreground so that it has control over them and knows what PIDs they have etc.
The validation is a bit harder, you can listen for wext events, but you can't even try pinging between the interfaces... Maybe the validation should check what's going on on the "air".
johannes
Re: VLAN testing (and mac80211_hwsim test cases in general)
Quoted 4 lines · Johannes Berg
Awesome, thanks. I'll look at the code, it seems to me that I actually want to be able to configure to not reject unknown stations but put them into their own VLAN, or something, then this feature could actually be useful in production.
That would require a bit more code to have the default VLAN ID for unknown STAs stored somewhere, but that should be relatively small change to hostapd with all the other VLAN ID processing available.
Quoted 3 lines
The validation is a bit harder, you can listen for wext events, but you can't even try pinging between the interfaces... Maybe the validation should check what's going on on the "air".
debugfs provides some help for things like VLAN (or well, would provide, if we actually showed that information there ;-), but that can be easily added). As far as data packets are concerned, we could implement a simple "ping" program that uses packet sockets to send some data (and reply to specific messages). This can then by-pass the issues with IP and local interface.
It would be useful to have a tool that processes hwsim0 dump, though, and provides a language for writing "expect scripts" for 802.11 (+radiotap) frames.. For example, something like "EXPECT ProbeReq CHAN=1 SRC=<mac> DST=<bcast>; EXPECT ProbeResp CHAN=1 SRC=<bssid> DST=<mac>" and so on.. That tool would then write a report on what happened and provided pass/fail result based on requirements in the script.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Re: VLAN testing (and mac80211_hwsim test cases in general)
Quoted 8 lines · On Friday 29 August 2008 10:37:41 Jouni Malinen wrote:
debugfs provides some help for things like VLAN (or well, would provide, if we actually showed that information there ;-), but that can be easily added). As far as data packets are concerned, we could implement a simple "ping" program that uses packet sockets to send some data (and reply to specific messages). This can then by-pass the issues with IP and local interface.
Hello all, I saw the test driver project in kernelnewbies.org, posted by Johannes, so I was working a little bit on the subject.
I am an absolute newbie, but I would like to share my thoughts while I was working on this and seeing mac80211_hwsim. Again, probably most of them are useless, but give me a try :). This is gonna be a little bit off-topic... sorry.
First of all, I built a fool bus, just for plugging and unplugging the devices on it (using debugfs for this task). I think it was the better way for simulate a real device structure, but in fact is totally useless :$.
Quoted 6 lines
It would be useful to have a tool that processes hwsim0 dump, though, and provides a language for writing "expect scripts" for 802.11 (+radiotap) frames.. For example, something like "EXPECT ProbeReq CHAN=1 SRC=<mac> DST=<bcast>; EXPECT ProbeResp CHAN=1 SRC=<bssid> DST=<mac>" and so on.. That tool would then write a report on what happened and provided pass/fail result based on requirements in the script.
Then, every device has debugfs I/O files (well, writing isn't working properly yet). I tought it was the best way to allow an user tool to handle configurations and communication with devices. I mean, the 'air' would be these debugfs files next to an user tool to simulate what you want using them.
Well, the next two weeks are my exams period, so i will be out of service, but I would like to help with this. Therefore, I'll pay attention to the list just in case I could help with this stuff.
Regards,
Jose Ignacio.