From: Luis R. Rodriguez <hidden> Date: 2004-06-29 19:21:01
I'll keep my latest wpa work/patch at the following URL:
http://prism54.org/~mcgrof/prism54-wpa.diff
I've nuked module params and am relying on private ioctls now since,
* we already have a [s|g]et_wpa priv iotcl, and
* in preperation for the WPA patch for Wireless Extensions.
I'll work on wpa ie scans tonight and try to fix mgt for
handling traps in extended mode. This is not related to wpa, but
I also made the firmware load at probe time. I turned the radio
off at probe after firmware load time too since the device is
not technically up yet.
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
From: Jeff Garzik <hidden> Date: 2004-06-29 20:22:10
On Tue, Jun 29, 2004 at 03:21:01PM -0400, Luis R. Rodriguez wrote:
I'll keep my latest wpa work/patch at the following URL:
http://prism54.org/~mcgrof/prism54-wpa.diff
I've nuked module params and am relying on private ioctls now since,
* we already have a [s|g]et_wpa priv iotcl, and
* in preperation for the WPA patch for Wireless Extensions.
I'll work on wpa ie scans tonight and try to fix mgt for
handling traps in extended mode. This is not related to wpa, but
I also made the firmware load at probe time. I turned the radio
off at probe after firmware load time too since the device is
not technically up yet.
Patch seems sane, though I vaguely recall xchg() not being atomic on all
platforms (such as i386?). Maybe I'm wrong, an expert should speak up :)
I also worry that the following is a race, but I have not traced the
code to verify or discount my guess:
+ u32 mlme, authen, dot1x, filter, wep;
+
+
+ if (islpci_get_state(priv) < PRV_STATE_INIT)
+ return 0;
down_write(&priv->mib_sem);
Hmm.. I do not understand the change you did for priv->wpa processing.
There seems to be some kind of misunderstanding on what DOT11_AUTHENABLE
and DOT11_OID_MLMEAUTOLEVEL is set to in various mode. I do not fully
understand what you mean with TKIP vs 802.1x. TKIP is an encryption
algorithm like WEP. IEEE 802.1X is authentication protocol which can be
used with IEEE 802.1X EAPOL-Key frames to distribute WEP keys _or_ with
WPA to generate keying material for WPA 4-Way Handshake that will
generate the data encryption keys.
DOT11_AUTHENABLE should be set to DOT11_AUTH_OS for WPA modes (i.e., not
_SK or _BOTH like you had in some cases). DOT11_AUTH_SK can only be used
with static WEP configuration (i.e., not with WPA or with IEEE 802.1X
when using dynamic WEP key generation). DOT11_AUTH_BOTH is likewise only
reasonable for static WEP configuration since it includes _SK as an
option. DOT11OID_MLMEAUTOLEVEL seems to be required to be
DOT11_MLME_EXTENDED for all cases where WPA IE is used.
--
Jouni Malinen PGP id EFC895FA
From: Luis R. Rodriguez <hidden> Date: 2004-06-30 14:01:04
On Tue, Jun 29, 2004 at 04:22:10PM -0400, Jeff Garzik wrote:
On Tue, Jun 29, 2004 at 03:21:01PM -0400, Luis R. Rodriguez wrote:
quoted
I'll keep my latest wpa work/patch at the following URL:
http://prism54.org/~mcgrof/prism54-wpa.diff
I've nuked module params and am relying on private ioctls now since,
* we already have a [s|g]et_wpa priv iotcl, and
* in preperation for the WPA patch for Wireless Extensions.
I'll work on wpa ie scans tonight and try to fix mgt for
handling traps in extended mode. This is not related to wpa, but
I also made the firmware load at probe time. I turned the radio
off at probe after firmware load time too since the device is
not technically up yet.
Patch seems sane, though I vaguely recall xchg() not being atomic on all
platforms (such as i386?). Maybe I'm wrong, an expert should speak up :)
Just in case -- please don't apply the patch yet, I put it up as for review
and update as to where I am.
I also worry that the following is a race, but I have not traced the
code to verify or discount my guess:
+ u32 mlme, authen, dot1x, filter, wep;
+
+
+ if (islpci_get_state(priv) < PRV_STATE_INIT)
+ return 0;
down_write(&priv->mib_sem);
FWIW, the context that this is within is prism54_set_wpa, a private ioctl.
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
Hmm.. I do not understand the change you did for priv->wpa processing.
There seems to be some kind of misunderstanding on what DOT11_AUTHENABLE
and DOT11_OID_MLMEAUTOLEVEL is set to in various mode.
First, thanks for the reply.
In regards to MLME, that was just a big fat typo.
I do not fully
understand what you mean with TKIP vs 802.1x. TKIP is an encryption
algorithm like WEP. IEEE 802.1X is authentication protocol which can be
used with IEEE 802.1X EAPOL-Key frames to distribute WEP keys _or_ with
WPA to generate keying material for WPA 4-Way Handshake that will
generate the data encryption keys.
Yes, sorry, what I was trying to distinguish was using WPA using either
PSK or 802.1x for 4-way handshake. I did not know there were two 802.1x key
mechanisms though, as you point out. Wherever I said just TKIP I meant over TKIP
using a PSK. I believe the second mode of 802.1x can be used with this
chipset, not sure of the first though (to distribute WEP keys).
DOT11_AUTHENABLE should be set to DOT11_AUTH_OS for WPA modes (i.e., not
_SK or _BOTH like you had in some cases). DOT11_AUTH_SK can only be used
with static WEP configuration (i.e., not with WPA or with IEEE 802.1X
when using dynamic WEP key generation). DOT11_AUTH_BOTH is likewise only
reasonable for static WEP configuration since it includes _SK as an
option.
OS stands for Open System here. Are you sure of this? I'll ask around, just to
confirm too.
DOT11OID_MLMEAUTOLEVEL seems to be required to be
DOT11_MLME_EXTENDED for all cases where WPA IE is used.
Yes, this I am aware of this. I've regenerated my patch. This *is* what
I meant. I think then we just need to clear up on what values should be
set for AUTHENABLE. I assumed the filter settings should work as I noted
but I am not yet sure obviously since I cannot test yet.
Last note is just keep in my that the patch is not supposed to work, its
more of work in progress, particularly turning the radio off involves
more work than what I currently have there. That is what I spend last
night working on. I'll try to finish that off first before I move on to
trying to detect WPA IEs.
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
On Wed, Jun 30, 2004 at 11:13:46AM -0400, Luis R. Rodriguez wrote:
quoted
algorithm like WEP. IEEE 802.1X is authentication protocol which can be
used with IEEE 802.1X EAPOL-Key frames to distribute WEP keys _or_ with
WPA to generate keying material for WPA 4-Way Handshake that will
generate the data encryption keys.
Yes, sorry, what I was trying to distinguish was using WPA using either
PSK or 802.1x for 4-way handshake. I did not know there were two 802.1x key
mechanisms though, as you point out. Wherever I said just TKIP I meant over TKIP
using a PSK. I believe the second mode of 802.1x can be used with this
chipset, not sure of the first though (to distribute WEP keys).
I kind of though so, too, but the configuration did not match this at
all.. WPA-PSK and WPA-EAP(IEEE 802.1X/RADIUS) should use the same
settings for IEEE 802.11 auth alg and MLME auto level.
quoted
DOT11_AUTHENABLE should be set to DOT11_AUTH_OS for WPA modes (i.e., not
_SK or _BOTH like you had in some cases). DOT11_AUTH_SK can only be used
with static WEP configuration (i.e., not with WPA or with IEEE 802.1X
when using dynamic WEP key generation). DOT11_AUTH_BOTH is likewise only
reasonable for static WEP configuration since it includes _SK as an
option.
OS stands for Open System here. Are you sure of this? I'll ask around, just to
confirm too.
Yes, I'm sure. See IEEE 802.11 standard for details. Open System auth
alg is required for WPA. Shared keys auth alg uses WEP, so the only to
use it is to have pre-shared WEP keys. I don't remember whether FullMAC
version of PrismGT driver has a separate mode for WPA, but if not, this
oid needs to be OS. It certainly cannot be SK.
--
Jouni Malinen PGP id EFC895FA