[PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Ortwin Glück]

reset_auth is called before each authentication try. So it should not destroy
the auth_alg that was set before.

NB: this may have side-effects with automatic algorithm selection if AP responds 
with alg not supported.

Signed-off-by: Ortwin Glueck <odi@odi.ch>
---
  net/mac80211/mlme.c |   10 +---------
  1 files changed, 1 insertions(+), 9 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 902cac1..5dbe012 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3420,6 +3420,7 @@ static void ieee80211_sta_reset_auth(struct net_device *dev,
  				     struct ieee80211_if_sta *ifsta)
  {
  	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);

  	if (local->ops->reset_tsf) {
  		/* Reset own TSF to allow time synchronization work. */
@@ -3428,15 +3429,6 @@ static void ieee80211_sta_reset_auth(struct net_device *dev,

  	ifsta->wmm_last_param_set = -1; /* allow any WMM update */

-
-	if (ifsta->auth_algs & IEEE80211_AUTH_ALG_OPEN)
-		ifsta->auth_alg = WLAN_AUTH_OPEN;
-	else if (ifsta->auth_algs & IEEE80211_AUTH_ALG_SHARED_KEY)
-		ifsta->auth_alg = WLAN_AUTH_SHARED_KEY;
-	else if (ifsta->auth_algs & IEEE80211_AUTH_ALG_LEAP)
-		ifsta->auth_alg = WLAN_AUTH_LEAP;
-	else
-		ifsta->auth_alg = WLAN_AUTH_OPEN;
  	ifsta->auth_transaction = -1;
  	ifsta->flags &= ~IEEE80211_STA_ASSOCIATED;
  	ifsta->auth_tries = ifsta->assoc_tries = 0;
-- 
1.5.6.4

Re: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Johannes Berg]

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

On Mon, 2008-09-15 at 17:50 +0200, Ortwin Glück wrote:
> reset_auth is called before each authentication try. So it should not destroy
> the auth_alg that was set before.
> 
> NB: this may have side-effects with automatic algorithm selection if AP responds 
> with alg not supported.

This seems entirely wrong.

Is your AP not capable of/configured to do open auth and _also_ doesn't
reject the attempt? That is, the AP is just completely broken?

johannes

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

Re: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Ortwin Glück]

Johannes Berg wrote:
> On Mon, 2008-09-15 at 17:50 +0200, Ortwin Gl=C3=BCck wrote:
>> reset_auth is called before each authentication try. So it should no=
t destroy
>> the auth_alg that was set before.
>>
>> NB: this may have side-effects with automatic algorithm selection if=
 AP responds=20
>> with alg not supported.
>=20
> This seems entirely wrong.
>=20
> Is your AP not capable of/configured to do open auth and _also_ doesn=
't
> reject the attempt? That is, the AP is just completely broken?

Well, I see that with other (binary) drivers it actively rejects such=20
authentication attempts. But with this driver it doesnt. The only diffe=
rence=20
that I can see from the packet logs is that mac80211 sends no probes be=
fore the=20
authentication, and that the sequence number is being reset. So maybe t=
hat keeps=20
this Netgear AP (yes it's crap) from rejecting. Or then it's something =
in ath9k=20
that causes the AP not to receive the packets in the first place.

Ortwin

--
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: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Johannes Berg]

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

On Mon, 2008-09-15 at 18:00 +0200, Ortwin Glück wrote:
> 
> Johannes Berg wrote:
> > On Mon, 2008-09-15 at 17:50 +0200, Ortwin Glück wrote:
> >> reset_auth is called before each authentication try. So it should not destroy
> >> the auth_alg that was set before.
> >>
> >> NB: this may have side-effects with automatic algorithm selection if AP responds 
> >> with alg not supported.
> > 
> > This seems entirely wrong.
> > 
> > Is your AP not capable of/configured to do open auth and _also_ doesn't
> > reject the attempt? That is, the AP is just completely broken?
> 
> Well, I see that with other (binary) drivers it actively rejects such 
> authentication attempts. But with this driver it doesnt. The only difference 
> that I can see from the packet logs is that mac80211 sends no probes before the 
> authentication, and that the sequence number is being reset.

When's the sequence number reset? Which sequence number?

>  So maybe that keeps 
> this Netgear AP (yes it's crap) from rejecting. Or then it's something in ath9k 
> that causes the AP not to receive the packets in the first place.

That'd be weird.

johannes

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

Re: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Ortwin Glück]

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



Johannes Berg wrote:
> When's the sequence number reset? Which sequence number?

Sorry, seq number is alright now. That was fixed recently.

Really the only difference that I see now is the probe request/response.
Attached are two Wireshark packets logs. Ignore all the Beacons and scroll down 
until the authentication sequence.

good - what my card sends with some binary drivers
bad2 - what mac80211 sends (2.6.27-rc5 my 2 patches)

[-- Attachment #2: bad2 --]
[-- Type: application/octet-stream, Size: 24770 bytes --]

[-- Attachment #3: good --]
[-- Type: application/octet-stream, Size: 61235 bytes --]

Re: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Johannes Berg]

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

On Mon, 2008-09-15 at 18:39 +0200, Ortwin Glück wrote:

> Really the only difference that I see now is the probe request/response.
> Attached are two Wireshark packets logs. Ignore all the Beacons and scroll down 
> until the authentication sequence.
> 
> good - what my card sends with some binary drivers
> bad2 - what mac80211 sends (2.6.27-rc5 my 2 patches)

The packet capture indicates that the packets are retransmitted
indicating  that the AP isn't even acknowledging them, which in turn
indicates it's not receiving them. This suggests there's something wrong
with ath9k, are you positive it works with those mac80211 hacks?

johannes

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

Re: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Ortwin Glück]

Johannes Berg wrote:
> The packet capture indicates that the packets are retransmitted
> indicating  that the AP isn't even acknowledging them, which in turn
> indicates it's not receiving them. This suggests there's something wrong
> with ath9k, are you positive it works with those mac80211 hacks?
> 
> johannes

You're very right. I just moved my laptop into the same room where the AP is. 
And guess what: auth and association works straight away. Apparently ath9k sets 
up the card so badly that the transmission power is extremely low! Also I 
couldn't set any other rate than 1M.

So, please forget about these 2 patches. They should not be necessary. Instead I 
will focus on debugging ath9k.

Cheers

Ortwin

Re: [PATCH 2/2] Don't destroy authentication algorithm before authenticating.

[Luis R. Rodriguez]

On Mon, Sep 15, 2008 at 12:02:45PM -0700, Ortwin Gl=FCck wrote:
> Johannes Berg wrote:
> > The packet capture indicates that the packets are retransmitted
> > indicating  that the AP isn't even acknowledging them, which in tur=
n
> > indicates it's not receiving them. This suggests there's something =
wrong
> > with ath9k, are you positive it works with those mac80211 hacks?
> >
> > johannes
>=20
> You're very right. I just moved my laptop into the same room where th=
e AP is.
> And guess what: auth and association works straight away. Apparently =
ath9k sets
> up the card so badly that the transmission power is extremely low! Al=
so I
> couldn't set any other rate than 1M.

The rate indicated by iwconfig is bogus, we have to fix the reported
rate, we'll do that soon. We'll review this thread too and try to get
this fixed.

Thanks for reporting it.

  Luis
--
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