Updated WE-18 (WPA) proposal

Updated WE-18 (WPA) proposal

[Jouni Malinen]

Finally, I had enough time to implement and test the proposed WE-18
(WPA) changes with Host AP driver and wpa_supplicant. This testing was
indeed needed since number of issues showed up. I have made an updated
version of the WE-18 proposal that seems to work with
hostap and wpa_supplicant (current development snapshot from
http://hostap/epitest.fi/). I have not yet verified how much of
interface needed for hostapd could be moved to these new parts of WE-18
instead of the currently used private ioctls.

Since WE-17 has apparently not yet been merged all the way into
linux-2.6 tree, the patch below is against Linux 2.6.8.1 that has been
patched with WE-17 patch (http://www.hpl.hp.com/personal/
Jean_Tourrilhes/Linux/iw268_we17-10.diff). This should be quite close
to what the final WE-18 would be diffed against. This WE-18 patch is
still experimental and it may still need to be changed (i.e., this
should not yet be merged into linux-2.6).

Change log against the latest WE-18 proposal (http://www.hpl.hp.com/
personal/Jean_Tourrilhes/Linux/iw_we18-3.diff):

- replaced optional parameter (iw_point) to SIOCSIWSCAN with a new ioctl
  (SIOCSIWSCANEXT) since the previous design was not really backwards
  compatible (e.g., 'iwlist wlan0 scan' did not work)
- replaced IWEVWPAIE/IWEVRSNIE with more generic IWEVGENIE which can
  also be used with non-WPA (e.g., IEEE 802.11e/WMM) IEs; in addition,
  fixed the type for this event to be IW_HEADER_TYPE_POINT (was _PARAM)
- use larger IW_GENERIC_IE_MAX (256->1024) to be able to handle possible
  needs for future IEEE 802.11 amendments
- added new IW_AUTH_INDEX parameters IW_AUTH_WPA_ENABLED and
  IW_AUTH_RX_UNENCRYPTED_EAPOL that were missing from the functionality
  needed by wpa_supplicant interface
- changed IW_AUTH_WPA_VERSION, IW_AUTH_PAIRWISE_CIPHER,
  IW_AUTH_GROUP_CIPHER, and IW_AUTH_KEY_MGMT to bit fields
- added LEAP to IW_AUTH_80211_AUTH_ALG values
- added IW_ENCODE_EXT_SET_TX_KEY (set key value and mark key as default
  TX key with one ioctl)
- added some more comments to areas that were unclear (have generated
  questions)
- added min_tokens values for SIOCSIWENCODEEXT and SIOCGIWENCODEEXT

Question: is length field in struct iw_point in bytes or tokens
(token_size bytes)? I assumed it was in bytes, but this did not work
very well with WE ioctls that had token_size != 1; I made SIOCSIWSCANEXT
use token_size = 1 for now, but it could be replaced to be
sizeof(struct) and min_tokens=max_tokesn=1 once this question is
resolved.



diff -upr 2.6.8.1-WE17/include/linux/wireless.h 2.6.8.1-WE18/include/linux/wireless.h
--- 2.6.8.1-WE17/include/linux/wireless.h	2004-08-29 21:23:32.277037256 -0700
+++ 2.6.8.1-WE18/include/linux/wireless.h	2004-08-29 19:25:33.000000000 -0700
@@ -1,7 +1,7 @@
 /*
  * This file define a set of standard wireless extensions
  *
- * Version :	17	21.6.04
+ * Version :	18	29.8.04
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
  * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved.
@@ -82,7 +82,7 @@
  * (there is some stuff that will be added in the future...)
  * I just plan to increment with each new version.
  */
-#define WIRELESS_EXT	17
+#define WIRELESS_EXT	18
 
 /*
  * Changes :
@@ -182,6 +182,19 @@
  *	- Document (struct iw_quality *)->updated, add new flags (INVALID)
  *	- Wireless Event capability in struct iw_range
  *	- Add support for relative TxPower (yick !)
+ *
+ * V17 to V18 (From Jouni Malinen <jkmaline@cc.hut.fi>)
+ * ----------
+ *	- Add support for WPA/WPA2
+ *	- Add extended encoding configuration (SIOCSIWENCODEEXT and
+ *	  SIOCGIWENCODEEXT)
+ *	- Add SIOCSIWGENIE/SIOCGIWGENIE
+ *	- Add SIOCSIWMLME
+ *	- Add struct iw_range bit field for supported encoding capabilities
+ *	- Add extended scan request (SIOCSIWSCANEXT)
+ *	- Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA
+ *	  related parameters (extensible up to 4096 parameter values)
+ *	- Add wireless events: IWEVGENIE, IWEVMICHAELMICFAILURE
  */
 
 /**************************** CONSTANTS ****************************/
@@ -256,6 +269,29 @@
 #define SIOCSIWPOWER	0x8B2C		/* set Power Management settings */
 #define SIOCGIWPOWER	0x8B2D		/* get Power Management settings */
 
+/* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM).
+ * This ioctl uses struct iw_point and data buffer that includes IE id and len
+ * fields. More than one IE may be included in the request. Setting the generic
+ * IE to empty buffer (len=0) removes the generic IE from the driver. */
+#define SIOCSIWGENIE	0x8B30		/* set generic IE */
+#define SIOCGIWGENIE	0x8B31		/* get generic IE */
+
+/* WPA : IEEE 802.11 MLME requests */
+#define SIOCSIWMLME	0x8B16		/* request MLME operation; uses
+					 * struct iw_mlme */
+/* WPA : Authentication mode parameters */
+#define SIOCSIWAUTH	0x8B32		/* set authentication mode params */
+#define SIOCGIWAUTH	0x8B33		/* get authentication mode params */
+
+/* WPA : Extended version of encoding configuration */
+#define SIOCSIWENCODEEXT 0x8B34		/* set encoding token & mode */
+#define SIOCGIWENCODEEXT 0x8B35		/* get encoding token & mode */
+
+/* Extended scan request; like SIOCSIWSCAN, but with additional parameters in
+ * struct iw_scan_req buffer. This shares SIOCGIWSCAN for reading the results.
+ */
+#define SIOCSIWSCANEXT	0x8B36		/* trigger scanning (extended) */
+
 /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */
 
 /* These 32 ioctl are wireless device private, for 16 commands.
@@ -297,6 +333,15 @@
 #define IWEVCUSTOM	0x8C02		/* Driver specific ascii string */
 #define IWEVREGISTERED	0x8C03		/* Discovered a new node (AP mode) */
 #define IWEVEXPIRED	0x8C04		/* Expired a node (AP mode) */
+#define IWEVGENIE	0x8C05		/* Generic IE (WPA, RSN, WMM, ..)
+					 * (scan results); This includes id and
+					 * length fields. One IWEVGENIE may
+					 * contain more than one IE. Scan
+					 * results may contain one or more
+					 * IWEVGENIE events. */
+#define IWEVMICHAELMICFAILURE 0x8C06	/* Michael MIC failure
+					 * (struct iw_michaelmicfailure)
+					 */
 
 #define IWEVFIRST	0x8C00
 
@@ -432,12 +477,87 @@
 #define IW_SCAN_THIS_MODE	0x0020	/* Scan only this Mode */
 #define IW_SCAN_ALL_RATE	0x0040	/* Scan all Bit-Rates */
 #define IW_SCAN_THIS_RATE	0x0080	/* Scan only this Bit-Rate */
+/* struct iw_scan_req scan_type */
+#define IW_SCAN_TYPE_ACTIVE 0
+#define IW_SCAN_TYPE_PASSIVE 1
 /* Maximum size of returned data */
 #define IW_SCAN_MAX_DATA	4096	/* In bytes */
 
 /* Max number of char in custom event - use multiple of them if needed */
 #define IW_CUSTOM_MAX		256	/* In bytes */
 
+/* Generic information element */
+#define IW_GENERIC_IE_MAX	1024
+
+/* MLME requests (SIOCSIWMLME / struct iw_mlme) */
+#define IW_MLME_DEAUTH		0
+#define IW_MLME_DISASSOC	1
+
+/* SIOCSIWAUTH/SIOCGIWAUTH struct iw_param flags */
+#define IW_AUTH_INDEX		0x0FFF
+#define IW_AUTH_FLAGS		0xF000
+/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095)
+ * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the
+ * parameter that is being set/get to; value will be read/written to
+ * struct iw_param value field) */
+#define IW_AUTH_WPA_VERSION		0
+#define IW_AUTH_CIPHER_PAIRWISE		1
+#define IW_AUTH_CIPHER_GROUP		2
+#define IW_AUTH_KEY_MGMT		3
+#define IW_AUTH_TKIP_COUNTERMEASURES	4
+#define IW_AUTH_DROP_UNENCRYPTED	5
+#define IW_AUTH_80211_AUTH_ALG		6
+#define IW_AUTH_WPA_ENABLED		7
+#define IW_AUTH_RX_UNENCRYPTED_EAPOL	8
+
+/* 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) */
+#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
+
+/* IW_AUTH_KEY_MGMT values (bit field) */
+#define IW_AUTH_KEY_MGMT_802_1X	1
+#define IW_AUTH_KEY_MGMT_PSK	2
+
+/* IW_AUTH_80211_AUTH_ALG values (bit field) */
+#define IW_AUTH_ALG_OPEN_SYSTEM	0x00000001
+#define IW_AUTH_ALG_SHARED_KEY	0x00000002
+#define IW_AUTH_ALG_LEAP	0x00000004
+
+/* SIOCSIWENCODEEXT definitions */
+#define IW_ENCODE_SEQ_MAX_SIZE	8
+/* struct iw_encode_ext ->alg */
+#define IW_ENCODE_ALG_NONE	0
+#define IW_ENCODE_ALG_WEP	1
+#define IW_ENCODE_ALG_TKIP	2
+#define IW_ENCODE_ALG_CCMP	3
+/* struct iw_encode_ext ->ext_flags */
+#define IW_ENCODE_EXT_TX_SEQ_VALID	0x00000001
+#define IW_ENCODE_EXT_RX_SEQ_VALID	0x00000002
+#define IW_ENCODE_EXT_GROUP_KEY		0x00000004
+#define IW_ENCODE_EXT_SET_TX_KEY	0x00000008
+
+/* IWEVMICHAELMICFAILURE : struct iw_michaelmicfailure ->flags */
+#define IW_MICFAILURE_KEY_ID	0x00000003 /* Key ID 0..3 */
+#define IW_MICFAILURE_GROUP	0x00000004
+#define IW_MICFAILURE_PAIRWISE	0x00000008
+#define IW_MICFAILURE_STAKEY	0x00000010
+#define IW_MICFAILURE_COUNT	0x00000060 /* 1 or 2 (0 = count not supported)
+					    */
+
+/* Bit field values for enc_capa in struct iw_range */
+#define IW_ENC_CAPA_WPA		0x00000001
+#define IW_ENC_CAPA_WPA2	0x00000002
+#define IW_ENC_CAPA_CIPHER_TKIP	0x00000004
+#define IW_ENC_CAPA_CIPHER_CCMP	0x00000008
+
 /* Event capability macros - in (struct iw_range *)->event_capa
  * Because we have more than 32 possible events, we use an array of
  * 32 bit bitmasks. Note : 32 bits = 0x20 = 2^5. */
@@ -546,6 +666,86 @@ struct	iw_thrspy
 	struct iw_quality	high;		/* High threshold */
 };
 
+/*
+ *	Data for extended scan request (MLME-SCAN.request)
+ */
+struct	iw_scan_req
+{
+	__u8		mode;	/* IW_MODE_AUTO (= Both), IW_MODE_ADHOC, or
+				 * IW_MODE_INFRA */
+	__u8		scan_type; /* IW_SCAN_TYPE_{ACTIVE,PASSIVE} */
+	__u8		essid_len;
+	__u8		num_channels; /* num entries in channel_list;
+				       * 0 = scan all allowed channels */
+	struct sockaddr	bssid; /* ff:ff:ff:ff:ff:ff for broadcast BSSID or
+				* individual address of a specific BSS */
+	/* Use this ESSID if IW_SCAN_THIS_ESSID flag is used instead of using
+	 * the current ESSID. This allows scan requests for specific ESSID
+	 * without having to change the current ESSID and potentially breaking
+	 * the current association. */
+	__u8		essid[IW_ESSID_MAX_SIZE];
+	__u32		probe_delay; /* delay in usec prior to transmitting
+				      * ProbeReq */
+	__u32		min_channel_time; /* in TU, >= probe_delay */
+	__u32		max_channel_time; /* in TU, >= min_channel_time */
+	struct iw_freq	channel_list[IW_MAX_FREQUENCIES];
+};
+
+/* ------------------------- WPA SUPPORT ------------------------- */
+
+/*
+ *	Extended data structure for get/set encoding (this is used with
+ *	SIOCSIWENCODEEXT/SIOCGIWENCODEEXT. struct iw_point and IW_ENCODE_*
+ *	flags are used in the same way as with SIOCSIWENCODE/SIOCGIWENCODE and
+ *	only the data contents changes (key data -> this structure, including
+ *	key data).
+ *
+ *	If the new key is the first group key, it will be set as the default
+ *	TX key. Otherwise, default TX key index is only changed if
+ *	IW_ENCODE_EXT_SET_TX_KEY flag is set.
+ *
+ *	Key will be changed with SIOCSIWENCODEEXT in all cases except for
+ *	special "change TX key index" operation which is indicated by setting
+ *	key_len = 0 and ext_flags |= IW_ENCODE_EXT_SET_TX_KEY.
+ *
+ *	tx_seq/rx_seq are only used when respective
+ *	IW_ENCODE_EXT_{TX,RX}_SEQ_VALID flag is set in ext_flags. Normal
+ *	TKIP/CCMP operation is to set RX seq with SIOCSIWENCODEEXT and start
+ *	TX seq from zero whenever key is changed. SIOCGIWENCODEEXT is normally
+ *	used only by an Authenticator (AP or an IBSS station) to get the
+ *	current TX sequence number. Using TX_SEQ_VALID for SIOCSIWENCODEEXT and
+ *	RX_SEQ_VALID for SIOCGIWENCODEEXT are optional, but can be useful for
+ *	debugging/testing.
+ */
+struct	iw_encode_ext
+{
+	__u32		ext_flags; /* IW_ENCODE_EXT_* */
+	__u8		tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */
+	__u8		rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */
+	struct sockaddr	addr; /* ff:ff:ff:ff:ff:ff for broadcast/multicast
+			       * (group) keys or unicast address for
+			       * individual keys */
+	__u16		alg; /* IW_ENCODE_ALG_* */
+	__u16		key_len;
+	__u8		key[0];
+};
+
+/* SIOCSIWMLME data */
+struct	iw_mlme
+{
+	__u16		cmd; /* IW_MLME_* */
+	__u16		reason_code;
+	struct sockaddr	addr;
+};
+
+/* IWEVMICHAELMICFAILURE data */
+struct	iw_michaelmicfailure
+{
+	__u32		flags;
+	struct sockaddr	src_addr;
+	__u8		tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */
+};
+
 /* ------------------------ WIRELESS STATS ------------------------ */
 /*
  * Wireless statistics (used for /proc/net/wireless)
@@ -725,6 +925,8 @@ struct	iw_range
 	struct iw_freq	freq[IW_MAX_FREQUENCIES];	/* list */
 	/* Note : this frequency list doesn't need to fit channel numbers,
 	 * because each entry contain its channel index */
+
+	__u32		enc_capa; /* IW_ENC_CAPA_* bit field */
 };
 
 /*
diff -upr 2.6.8.1-WE17/net/core/wireless.c 2.6.8.1-WE18/net/core/wireless.c
--- 2.6.8.1-WE17/net/core/wireless.c	2004-08-29 21:23:32.285036040 -0700
+++ 2.6.8.1-WE18/net/core/wireless.c	2004-08-29 21:27:41.406163872 -0700
@@ -186,6 +186,12 @@ static const struct iw_ioctl_description
 		.header_type	= IW_HEADER_TYPE_ADDR,
 		.flags		= IW_DESCR_FLAG_DUMP,
 	},
+	[SIOCSIWMLME	- SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+		.token_size	= sizeof(struct iw_mlme),
+		.min_tokens	= 1,
+		.max_tokens	= 1,
+	},
 	[SIOCGIWAPLIST	- SIOCIWFIRST] = {
 		.header_type	= IW_HEADER_TYPE_POINT,
 		.token_size	= sizeof(struct sockaddr) +
@@ -272,6 +278,52 @@ static const struct iw_ioctl_description
 	[SIOCGIWPOWER	- SIOCIWFIRST] = {
 		.header_type	= IW_HEADER_TYPE_PARAM,
 	},
+	[SIOCSIWGENIE	- SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+		.token_size	= 1,
+		.max_tokens	= IW_GENERIC_IE_MAX,
+	},
+	[SIOCGIWGENIE	- SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+		.token_size	= 1,
+		.max_tokens	= IW_GENERIC_IE_MAX,
+	},
+	[SIOCSIWAUTH	- SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_PARAM,
+	},
+	[SIOCGIWAUTH	- SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_PARAM,
+	},
+	[SIOCSIWENCODEEXT - SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+		.token_size	= 1,
+		.min_tokens	= sizeof(struct iw_encode_ext),
+		.max_tokens	= sizeof(struct iw_encode_ext) +
+				  IW_ENCODING_TOKEN_MAX,
+	},
+	[SIOCGIWENCODEEXT - SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+		.token_size	= 1,
+		.min_tokens	= sizeof(struct iw_encode_ext),
+		.max_tokens	= sizeof(struct iw_encode_ext) +
+				  IW_ENCODING_TOKEN_MAX,
+	},
+	[SIOCSIWSCANEXT	- SIOCIWFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+#if 0
+		/* FIX: JKM - is this correct? Is length in struct iw_point
+		 * number of bytes or number of tokens in the buffer?
+		 * I changed this to use token_size=1 for now, since I assumed
+		 * length from user space would always be in bytes.. */
+		.token_size	= sizeof(struct iw_scan_req),
+		.min_tokens	= 1,
+		.max_tokens	= 1,
+#else
+		.token_size	= 1,
+		.min_tokens	= sizeof(struct iw_scan_req),
+		.max_tokens	= sizeof(struct iw_scan_req),
+#endif
+	},
 };
 static const int standard_ioctl_num = (sizeof(standard_ioctl) /
 				       sizeof(struct iw_ioctl_description));
@@ -298,6 +350,16 @@ static const struct iw_ioctl_description
 	[IWEVEXPIRED	- IWEVFIRST] = {
 		.header_type	= IW_HEADER_TYPE_ADDR, 
 	},
+	[IWEVGENIE	- IWEVFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT,
+		.token_size	= 1,
+		.max_tokens	= IW_GENERIC_IE_MAX,
+	},
+	[IWEVMICHAELMICFAILURE	- IWEVFIRST] = {
+		.header_type	= IW_HEADER_TYPE_POINT, 
+		.token_size	= 1,
+		.max_tokens	= sizeof(struct iw_michaelmicfailure),
+	},
 };
 static const int standard_event_num = (sizeof(standard_event) /
 				       sizeof(struct iw_ioctl_description));



-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Updated WE-18 (WPA) proposal

[Jean Tourrilhes]

On Sun, Aug 29, 2004 at 09:54:41PM -0700, Jouni Malinen wrote:
> Finally, I had enough time to implement and test the proposed WE-18
> (WPA) changes with Host AP driver and wpa_supplicant.

	Great !

> Since WE-17 has apparently not yet been merged all the way into
> linux-2.6 tree, the patch below is against Linux 2.6.8.1 that has been
> patched with WE-17 patch (http://www.hpl.hp.com/personal/
> Jean_Tourrilhes/Linux/iw268_we17-10.diff).

	Don't worry, I'll fix that. Anyway, WE-17 is pending in Jeff's
tree, and I don't think he will make major changes to it.

> - replaced optional parameter (iw_point) to SIOCSIWSCAN with a new ioctl
>   (SIOCSIWSCANEXT) since the previous design was not really backwards
>   compatible (e.g., 'iwlist wlan0 scan' did not work)

	Latest Wireless Tools actually fixes that. Most distro seems
to have adopted WT-27-preXX, and I plan to release WT-27 soon after
WE-17, so I would not consider that a big issue.
	Having a separate ioctl has one advantage, you know if the
driver support it or not. One the other hand, having a single ioctl
may reduce bloat.

> Question: is length field in struct iw_point in bytes or tokens
> (token_size bytes)? I assumed it was in bytes, but this did not work
> very well with WE ioctls that had token_size != 1; I made SIOCSIWSCANEXT
> use token_size = 1 for now, but it could be replaced to be
> sizeof(struct) and min_tokens=max_tokesn=1 once this question is
> resolved.

	Originally, I was using length == num-tokens, with token-size != 1.
	However, after a while, I realised that having length ==
num-bytes was a much better option, so that's why the "newer" ioctls
tend to all have token_size == 1.
	In the case of SIOCSIWSCANEXT, it's especially important as
the struct may grow in the future, so the size would allow to
distinguish the various additions.

	Thanks a lot !

	Jean

Re: Updated WE-18 (WPA) proposal

[Jeff Garzik]

Jean Tourrilhes wrote:
> 	Don't worry, I'll fix that. Anyway, WE-17 is pending in Jeff's
> tree, and I don't think he will make major changes to it.


hehe :)

Yep, it's merged in netdev-2.6 (and thus -mm as well), and queued for 
upstream.

FWIW any 'radical' wireless changes will go into wireless-2.6.  There is 
still the stable upstream branch, to which WE patches can continue to be 
applied...

	Jeff

Re: Updated WE-18 (WPA) proposal

[Jean Tourrilhes]

On Mon, Aug 30, 2004 at 01:28:43PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >	Don't worry, I'll fix that. Anyway, WE-17 is pending in Jeff's
> >tree, and I don't think he will make major changes to it.
> 
> 
> hehe :)
> 
> Yep, it's merged in netdev-2.6 (and thus -mm as well), and queued for 
> upstream.

	Thanks ;-)

> FWIW any 'radical' wireless changes will go into wireless-2.6.  There is 
> still the stable upstream branch, to which WE patches can continue to be 
> applied...

	If you don't mind, I would like a bit more understanding about
how much is "radical" and how much is not. I would personally put that
around "breaking backward compatibility", but you may have other
ideas.
	Also, I'm not clear how the stuff in wireless-2.6 is supposed
to trickle into the other trees (netdev-2.6, -mm and Linus's), and how
to better link it with the CVS of the various drivers involved.

> 	Jeff

	Have fun...

	Jean

Re: Updated WE-18 (WPA) proposal

[Jeff Garzik]

Jean Tourrilhes wrote:
> On Mon, Aug 30, 2004 at 01:28:43PM -0400, Jeff Garzik wrote:
> 
>>Jean Tourrilhes wrote:
>>
>>>	Don't worry, I'll fix that. Anyway, WE-17 is pending in Jeff's
>>>tree, and I don't think he will make major changes to it.
>>
>>
>>hehe :)
>>
>>Yep, it's merged in netdev-2.6 (and thus -mm as well), and queued for 
>>upstream.
> 
> 
> 	Thanks ;-)
> 
> 
>>FWIW any 'radical' wireless changes will go into wireless-2.6.  There is 
>>still the stable upstream branch, to which WE patches can continue to be 
>>applied...
> 
> 
> 	If you don't mind, I would like a bit more understanding about
> how much is "radical" and how much is not. I would personally put that
> around "breaking backward compatibility", but you may have other
> ideas.

Yes, as discussed (er, argued :)) radical would include breaking 
backwards compat.


> 	Also, I'm not clear how the stuff in wireless-2.6 is supposed
> to trickle into the other trees (netdev-2.6, -mm and Linus's), and how
> to better link it with the CVS of the various drivers involved.

Less of a trickle than a flood:  wireless-2.6 should be the target for 
development of shared wireless stack code.  As several drivers are 
currently using bits of HostAP, for example, wireless-2.6 should be a 
focal point for patches that modify these drivers to instead share the 
same code.

Once this generic work is done, it would get pushed all at once to 
netdev-2.6, where it would receive testing in -mm.  Then, later, pushed 
to mainline.

	Jeff

Re: Updated WE-18 (WPA) proposal

[Luis R. Rodriguez]

On Mon, Aug 30, 2004 at 01:55:52PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:

<-- snip -->

> >	Also, I'm not clear how the stuff in wireless-2.6 is supposed
> >to trickle into the other trees (netdev-2.6, -mm and Linus's), and how
> >to better link it with the CVS of the various drivers involved.
> 
> Less of a trickle than a flood:  wireless-2.6 should be the target for 
> development of shared wireless stack code.  As several drivers are 
> currently using bits of HostAP, for example, wireless-2.6 should be a 
> focal point for patches that modify these drivers to instead share the 
> same code.
> 
> Once this generic work is done, it would get pushed all at once to 
> netdev-2.6, where it would receive testing in -mm.  Then, later, pushed 
> to mainline.
> 
> 	Jeff

Beides wpa_supplicant from hostap code (which is actually going into
WE18) what other code re-use is on the roadmap as of yet for wireless-2.6?

Also who is coordinating this?

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: Updated WE-18 (WPA) proposal

[Jeff Garzik]

Luis R. Rodriguez wrote:
> On Mon, Aug 30, 2004 at 01:55:52PM -0400, Jeff Garzik wrote:
> 
>>Jean Tourrilhes wrote:
> 
> 
> <-- snip -->
> 
>>>	Also, I'm not clear how the stuff in wireless-2.6 is supposed
>>>to trickle into the other trees (netdev-2.6, -mm and Linus's), and how
>>>to better link it with the CVS of the various drivers involved.
>>
>>Less of a trickle than a flood:  wireless-2.6 should be the target for 
>>development of shared wireless stack code.  As several drivers are 
>>currently using bits of HostAP, for example, wireless-2.6 should be a 
>>focal point for patches that modify these drivers to instead share the 
>>same code.
>>
>>Once this generic work is done, it would get pushed all at once to 
>>netdev-2.6, where it would receive testing in -mm.  Then, later, pushed 
>>to mainline.
>>
>>	Jeff
> 
> 
> Beides wpa_supplicant from hostap code (which is actually going into
> WE18) what other code re-use is on the roadmap as of yet for wireless-2.6?

Intel Centrino driver is re-using chunks of HostAP, and I'm looking at 
doing so for the RealTek 8180 driver I am about to publish.


> Also who is coordinating this?

The same person who coordinates the kernel at large... no one ;-)

	Jeff

Re: Updated WE-18 (WPA) proposal

[Pedro Ramalhais]

On Mon, 2004-08-30 at 05:54, Jouni Malinen wrote:
> Finally, I had enough time to implement and test the proposed WE-18
> (WPA) changes with Host AP driver and wpa_supplicant. This testing was
> indeed needed since number of issues showed up. I have made an updated
> version of the WE-18 proposal that seems to work with
> hostap and wpa_supplicant (current development snapshot from
> http://hostap/epitest.fi/). I have not yet verified how much of
> interface needed for hostapd could be moved to these new parts of WE-18
> instead of the currently used private ioctls.
> 
> Since WE-17 has apparently not yet been merged all the way into
> linux-2.6 tree, the patch below is against Linux 2.6.8.1 that has been
> patched with WE-17 patch (http://www.hpl.hp.com/personal/
> Jean_Tourrilhes/Linux/iw268_we17-10.diff). This should be quite close
> to what the final WE-18 would be diffed against. This WE-18 patch is
> still experimental and it may still need to be changed (i.e., this
> should not yet be merged into linux-2.6).
> 
> Change log against the latest WE-18 proposal (http://www.hpl.hp.com/
> personal/Jean_Tourrilhes/Linux/iw_we18-3.diff):
> 
> - replaced optional parameter (iw_point) to SIOCSIWSCAN with a new ioctl
>   (SIOCSIWSCANEXT) since the previous design was not really backwards
>   compatible (e.g., 'iwlist wlan0 scan' did not work)
> - replaced IWEVWPAIE/IWEVRSNIE with more generic IWEVGENIE which can
>   also be used with non-WPA (e.g., IEEE 802.11e/WMM) IEs; in addition,
>   fixed the type for this event to be IW_HEADER_TYPE_POINT (was _PARAM)
> - use larger IW_GENERIC_IE_MAX (256->1024) to be able to handle possible
>   needs for future IEEE 802.11 amendments
> - added new IW_AUTH_INDEX parameters IW_AUTH_WPA_ENABLED and
>   IW_AUTH_RX_UNENCRYPTED_EAPOL that were missing from the functionality
>   needed by wpa_supplicant interface
> - changed IW_AUTH_WPA_VERSION, IW_AUTH_PAIRWISE_CIPHER,
>   IW_AUTH_GROUP_CIPHER, and IW_AUTH_KEY_MGMT to bit fields
> - added LEAP to IW_AUTH_80211_AUTH_ALG values
> - added IW_ENCODE_EXT_SET_TX_KEY (set key value and mark key as default
>   TX key with one ioctl)
> - added some more comments to areas that were unclear (have generated
>   questions)
> - added min_tokens values for SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
> 
> Question: is length field in struct iw_point in bytes or tokens
> (token_size bytes)? I assumed it was in bytes, but this did not work
> very well with WE ioctls that had token_size != 1; I made SIOCSIWSCANEXT
> use token_size = 1 for now, but it could be replaced to be
> sizeof(struct) and min_tokens=max_tokesn=1 once this question is
> resolved.

Hi Jouni and Jean!

#define IW_AUTH_RX_UNENCRYPTED_EAPOL   8
I think this define isn't needed because you can get the same
information from IW_AUTH_KEY_MGMT:
#define IW_AUTH_KEY_MGMT_802_1X        1
#define IW_AUTH_KEY_MGMT_PSK   2
because if IW_AUTH_KEY_MGMT_802_1X || IW_AUTH_KEY_MGMT_PSK , then you
want to pass unencrypted EAPOL packets.

Likewise for IW_AUTH_WPA_ENABLED which you can get from
IW_AUTH_WPA_VERSION:
/* IW_AUTH_WPA_VERSION values */
#define IW_AUTH_WPA_VERSION_DISABLED    0
#define IW_AUTH_WPA_VERSION_WPA         1
#define IW_AUTH_WPA_VERSION_WPA2        2
If IW_AUTH_WPA_VERSION == IW_AUTH_WPA_VERSION_DISABLED then WPA is
disabled, else if IW_AUTH_WPA_VERSION_WPA || IW_AUTH_WPA_VERSION_WPA2
then it's enabled.

Thanks!
-- 
Pedro Ramalhais <ramalhais@serrado.net>

Re: Updated WE-18 (WPA) proposal

[Jouni Malinen]

On Tue, Aug 31, 2004 at 01:49:47AM +0100, Pedro Ramalhais wrote:

> #define IW_AUTH_RX_UNENCRYPTED_EAPOL   8
> I think this define isn't needed because you can get the same
> information from IW_AUTH_KEY_MGMT:
> #define IW_AUTH_KEY_MGMT_802_1X        1
> #define IW_AUTH_KEY_MGMT_PSK   2
> because if IW_AUTH_KEY_MGMT_802_1X || IW_AUTH_KEY_MGMT_PSK , then you
> want to pass unencrypted EAPOL packets.

IW_AUTH_KEY_MGMT was added to support NDIS-like drivers that want to
generate WPA IE internally. Many drivers, e.g., Host AP, do not use them
at all. Consequently, I wanted to have a separate parameter for this
particular case. Drivers do not need to implement support for both
cases.

> Likewise for IW_AUTH_WPA_ENABLED which you can get from
> IW_AUTH_WPA_VERSION:
> /* IW_AUTH_WPA_VERSION values */
> #define IW_AUTH_WPA_VERSION_DISABLED    0
> #define IW_AUTH_WPA_VERSION_WPA         1
> #define IW_AUTH_WPA_VERSION_WPA2        2
> If IW_AUTH_WPA_VERSION == IW_AUTH_WPA_VERSION_DISABLED then WPA is
> disabled, else if IW_AUTH_WPA_VERSION_WPA || IW_AUTH_WPA_VERSION_WPA2
> then it's enabled.

This is not the same. IW_AUTH_WPA_ENABLED is used to configure the
driver in WPA mode before any scan requests whereas IW_AUTH_WPA_VERSION
is used only after the scan requests. Drivers are free to not implement
IW_AUTH_WPA_ENABLED handler if they are always in "WPA mode".

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Updated WE-18 (WPA) proposal

[Luis R. Rodriguez]

On Mon, Aug 30, 2004 at 06:20:01PM -0400, Jeff Garzik wrote:
> Luis R. Rodriguez wrote:
> >On Mon, Aug 30, 2004 at 01:55:52PM -0400, Jeff Garzik wrote:
> >
> >>Jean Tourrilhes wrote:
> >
> >
> ><-- snip -->
> >
> >>>	Also, I'm not clear how the stuff in wireless-2.6 is supposed
> >>>to trickle into the other trees (netdev-2.6, -mm and Linus's), and how
> >>>to better link it with the CVS of the various drivers involved.
> >>
> >>Less of a trickle than a flood:  wireless-2.6 should be the target for 
> >>development of shared wireless stack code.  As several drivers are 
> >>currently using bits of HostAP, for example, wireless-2.6 should be a 
> >>focal point for patches that modify these drivers to instead share the 
> >>same code.
> >>
> >>Once this generic work is done, it would get pushed all at once to 
> >>netdev-2.6, where it would receive testing in -mm.  Then, later, pushed 
> >>to mainline.
> >>
> >>	Jeff
> >
> >
> >Beides wpa_supplicant from hostap code (which is actually going into
> >WE18) what other code re-use is on the roadmap as of yet for wireless-2.6?
> 
> Intel Centrino driver is re-using chunks of HostAP, and I'm looking at 
> doing so for the RealTek 8180 driver I am about to publish.

Can someone elaborate on what "chunks" the centrino driver is using
from hostap?

Jeff what aspects are you looking to re-use from hostap?

I guess we at prism54 should also see what we can re-use too then.
Our next driver (a softmac driver) will have a lot more code since the
MAC will need to be implemented on the driver side -- I'm not yet sure
of the exact details as I haven't grep'd through the available code yet
I'm wondering though -- are there any other softmac drivers out there,
or to come soon?

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: Updated WE-18 (WPA) proposal

[Pedro Ramalhais]

On Tue, 2004-08-31 at 09:54, Luis R. Rodriguez wrote:
> On Mon, Aug 30, 2004 at 06:20:01PM -0400, Jeff Garzik wrote:
> > Luis R. Rodriguez wrote:
> > >On Mon, Aug 30, 2004 at 01:55:52PM -0400, Jeff Garzik wrote:
> > >
> > >>Jean Tourrilhes wrote:
> > >
> > >
> > ><-- snip -->
> > >
> > >>>	Also, I'm not clear how the stuff in wireless-2.6 is supposed
> > >>>to trickle into the other trees (netdev-2.6, -mm and Linus's), and how
> > >>>to better link it with the CVS of the various drivers involved.
> > >>
> > >>Less of a trickle than a flood:  wireless-2.6 should be the target for 
> > >>development of shared wireless stack code.  As several drivers are 
> > >>currently using bits of HostAP, for example, wireless-2.6 should be a 
> > >>focal point for patches that modify these drivers to instead share the 
> > >>same code.
> > >>
> > >>Once this generic work is done, it would get pushed all at once to 
> > >>netdev-2.6, where it would receive testing in -mm.  Then, later, pushed 
> > >>to mainline.
> > >>
> > >>	Jeff
> > >
> > >
> > >Beides wpa_supplicant from hostap code (which is actually going into
> > >WE18) what other code re-use is on the roadmap as of yet for wireless-2.6?
> > 
> > Intel Centrino driver is re-using chunks of HostAP, and I'm looking at 
> > doing so for the RealTek 8180 driver I am about to publish.
> 
> Can someone elaborate on what "chunks" the centrino driver is using
> from hostap?
> 
> Jeff what aspects are you looking to re-use from hostap?
> 
> I guess we at prism54 should also see what we can re-use too then.
> Our next driver (a softmac driver) will have a lot more code since the
> MAC will need to be implemented on the driver side -- I'm not yet sure
> of the exact details as I haven't grep'd through the available code yet
> I'm wondering though -- are there any other softmac drivers out there,
> or to come soon?
> 
> 	Luis

The ipw2100 driver and ipw2200 driver both use these parts of hostap
code:
RX code (i think now it's in file hostap_80211_rx.c)
little parts of the TX code (hostap_80211_tx.c)
the hostap_crypt* code for WEP.
Some IEEE802.11 related parts of header files.
The ipw2100 is beggining to use hostap_crypt_tkip and hostap_crypt_ccmp
for WPA and WPA2.

I think that's it. Better ask James Ketrenos, he is one of the
developers at intel.
-- 
Pedro Ramalhais <ramalhais@serrado.net>

Re: Updated WE-18 (WPA) proposal

[Vladimir Kondratiev]

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

On Tuesday 31 August 2004 18:33, Pedro Ramalhais wrote:
PR> > > Intel Centrino driver is re-using chunks of HostAP, and I'm looking
 at PR> > > doing so for the RealTek 8180 driver I am about to publish.
PR> >
PR> > Can someone elaborate on what "chunks" the centrino driver is using
PR> > from hostap?
PR> >
PR> > Jeff what aspects are you looking to re-use from hostap?
PR> >
PR> > I guess we at prism54 should also see what we can re-use too then.
PR> > Our next driver (a softmac driver) will have a lot more code since the
PR> > MAC will need to be implemented on the driver side -- I'm not yet sure
PR> > of the exact details as I haven't grep'd through the available code yet
PR> > I'm wondering though -- are there any other softmac drivers out there,
PR> > or to come soon?
PR> >
PR> >  Luis
PR>
PR> The ipw2100 driver and ipw2200 driver both use these parts of hostap
PR> code:
PR> RX code (i think now it's in file hostap_80211_rx.c)
PR> little parts of the TX code (hostap_80211_tx.c)
PR> the hostap_crypt* code for WEP.
PR> Some IEEE802.11 related parts of header files.
PR> The ipw2100 is beggining to use hostap_crypt_tkip and hostap_crypt_ccmp
PR> for WPA and WPA2.
PR>
PR> I think that's it. Better ask James Ketrenos, he is one of the
PR> developers at intel.

Luis,
please correct me if I'm wrong. It seems to me that softmac drivers will need 
significant changes relative to the model that HostAP employ. Also, many 
changes dictated by QoS (TGe), if one want to really implement it. Will your 
product support TGe?
May be, we need to do design for generic "softmac" that will be then used with 
different PHY's. Question is, whether we can formally describe boundary 
between softmac and PHY.
I am interesting in joining this "softmac" development, as I will do some 
other .11 card which is "softmac". Can't reveal details yet, but we may 
discuss softmac issues without disclosing private info (I don't want to lose 
my job).

Vladimir.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Updated WE-18 (WPA) proposal

[Luis R. Rodriguez]

On Tue, Aug 31, 2004 at 06:48:48PM +0300, Vladimir Kondratiev wrote:
> On Tuesday 31 August 2004 18:33, Pedro Ramalhais wrote:
> PR> > > Intel Centrino driver is re-using chunks of HostAP, and I'm looking
>  at PR> > > doing so for the RealTek 8180 driver I am about to publish.
> PR> >
> PR> > Can someone elaborate on what "chunks" the centrino driver is using
> PR> > from hostap?
> PR> >
> PR> > Jeff what aspects are you looking to re-use from hostap?
> PR> >
> PR> > I guess we at prism54 should also see what we can re-use too then.
> PR> > Our next driver (a softmac driver) will have a lot more code since the
> PR> > MAC will need to be implemented on the driver side -- I'm not yet sure
> PR> > of the exact details as I haven't grep'd through the available code yet
> PR> > I'm wondering though -- are there any other softmac drivers out there,
> PR> > or to come soon?
> PR> >
> PR> >  Luis
> PR>
> PR> The ipw2100 driver and ipw2200 driver both use these parts of hostap
> PR> code:
> PR> RX code (i think now it's in file hostap_80211_rx.c)
> PR> little parts of the TX code (hostap_80211_tx.c)
> PR> the hostap_crypt* code for WEP.
> PR> Some IEEE802.11 related parts of header files.
> PR> The ipw2100 is beggining to use hostap_crypt_tkip and hostap_crypt_ccmp
> PR> for WPA and WPA2.
> PR>
> PR> I think that's it. Better ask James Ketrenos, he is one of the
> PR> developers at intel.
> 
> Luis,
> please correct me if I'm wrong. It seems to me that softmac drivers will need 
> significant changes relative to the model that HostAP employ.

I am not sure as:

1. I haven't yet gone through hostap code besides wpa_supplicant
2. I haven't yet gone through the available softmac code:

http://www.dse.co.nz/isroot/dse/support/XH8196-linux.zip

Only once I have done both will I be able to tell. My guess yes
as I do not think hostap is softmac based.

> Also, many 
> changes dictated by QoS (TGe), if one want to really implement it. Will your 
> product support TGe?

Again, 2.

> May be, we need to do design for generic "softmac" that will be then used with 
> different PHY's. 

That's where I was going with my previous e-mail.

> Question is, whether we can formally describe boundary 
> between softmac and PHY.

We need as much public information available on softmac and review, or
have someone experienced enough in this field to talk up.

> I am interesting in joining this "softmac" development, as I will do some 
> other .11 card which is "softmac". Can't reveal details yet, but we may 
> discuss softmac issues without disclosing private info (I don't want to lose 
> my job).

Well at least this confirms another card will be softmac based, and
hence the possible need for code sharing.

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E