WEP and enc restricted

WEP and enc restricted

[Ortwin Glück]

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

Hi,

I am pretty sure that the mac80211 code doesn't handle WEP with shared keys 
correctly. Using the ath9k driver on my MacBook I am unable to put the driver 
into restricted mode (shared key). It stays in open mode. That is the following 
command has no effect: iwconfig wlan0 enc restricted. I can also confirm this 
when looking at the authentication packets that go over the air: they are sent 
with the open flag, and not the shared key flag.

Surprisingly nowhere in the mac80211 code the ifsta->auth_alg is set to 
WLAN_AUTH_SHARED_KEY so far. The attached small patch does just that. I am not 
100% sure if that's the way to do it, so please review carefully.

With this patch authentication works. The AP now denies association, but that is 
another problem.

Cheers

Ortwin

[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 496 bytes --]

--- wext.c.orig	2008-07-21 22:18:29.000000000 +0200
+++ wext.c	2008-09-14 16:46:09.000000000 +0200
@@ -929,6 +929,14 @@
 	else
 		idx--;
 
+	if (sdata->vif.type == IEEE80211_IF_TYPE_STA) {
+		struct ieee80211_if_sta *ifsta = &sdata->u.sta;
+		if (erq->flags & IW_ENCODE_OPEN)
+			ifsta->auth_alg = WLAN_AUTH_OPEN;
+		else if (erq->flags & IW_ENCODE_RESTRICTED)
+			ifsta->auth_alg = WLAN_AUTH_SHARED_KEY;
+	}
+
 	if (erq->flags & IW_ENCODE_DISABLED)
 		remove = 1;
 	else if (erq->length == 0) {

Re: WEP and enc restricted

[Dan Williams]

On Sun, 2008-09-14 at 17:44 +0200, Ortwin Gl=C3=BCck wrote:
> Hi,
>=20
> I am pretty sure that the mac80211 code doesn't handle WEP with share=
d keys=20
> correctly. Using the ath9k driver on my MacBook I am unable to put th=
e driver=20
> into restricted mode (shared key). It stays in open mode. That is the=
 following=20
> command has no effect: iwconfig wlan0 enc restricted. I can also conf=
irm this=20
> when looking at the authentication packets that go over the air: they=
 are sent=20
> with the open flag, and not the shared key flag.

It looks like ieee80211_rx_mgmt_auth() in mlme.c should be cycling
through the various auth methods when it gets an "auth not supported"
response from the AP.  I wonder why that's not working in your case.
Can you put some printks in there and see if that code gets triggered
and if not, poke around a bit to see why?

> Surprisingly nowhere in the mac80211 code the ifsta->auth_alg is set =
to=20
> WLAN_AUTH_SHARED_KEY so far. The attached small patch does just that.=
 I am not=20
> 100% sure if that's the way to do it, so please review carefully.

It looks like it does get set from the SIWAUTH handler if you pass in
the right auth algs bits; but you're correct in that SIWENCODE won't se=
t
the auth alg.  The patch seems to be correct.

However, the submission format needs a few things: the signed-off-by
line, and the patch should be inlined rather than attached to make for
easier review.  Please see here:

http://linux.yyz.us/patch-format.html

Thanks!
Dan

> With this patch authentication works. The AP now denies association, =
but that is=20
> another problem.
>=20
> Cheers
>=20
> Ortwin
> plain text document attachment (patch.diff)
> --- wext.c.orig	2008-07-21 22:18:29.000000000 +0200
> +++ wext.c	2008-09-14 16:46:09.000000000 +0200
> @@ -929,6 +929,14 @@
>  	else
>  		idx--;
> =20
> +	if (sdata->vif.type =3D=3D IEEE80211_IF_TYPE_STA) {
> +		struct ieee80211_if_sta *ifsta =3D &sdata->u.sta;
> +		if (erq->flags & IW_ENCODE_OPEN)
> +			ifsta->auth_alg =3D WLAN_AUTH_OPEN;
> +		else if (erq->flags & IW_ENCODE_RESTRICTED)
> +			ifsta->auth_alg =3D WLAN_AUTH_SHARED_KEY;
> +	}
> +
>  	if (erq->flags & IW_ENCODE_DISABLED)
>  		remove =3D 1;
>  	else if (erq->length =3D=3D 0) {

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WEP and enc restricted

[Ortwin Glück]

Dan Williams wrote:
> It looks like ieee80211_rx_mgmt_auth() in mlme.c should be cycling
> through the various auth methods when it gets an "auth not supported"
> response from the AP.  I wonder why that's not working in your case.
> Can you put some printks in there and see if that code gets triggered
> and if not, poke around a bit to see why?

Yes, I've seen that. I'll have to check the packet log again, but as far as I
remember the AP doesn't respond at all to these authentication packets. So the
cycling will never happen.

> It looks like it does get set from the SIWAUTH handler if you pass in
> the right auth algs bits; but you're correct in that SIWENCODE won't set
> the auth alg.  The patch seems to be correct.

In SIWAUTH only the available algorithms are set, not the actual one. It's a
different variable:
  sdata->u.sta.auth_alg*s* = data->value;

> However, the submission format needs a few things

I'll resend the patch in the correct format.

Cheers

Ortwin