Don't destroy authentication algorithm before authenticating.

PATCH In review Ortwin Glück 3 participants 8 messages Sep 15, 2008 mac80211

lore

Share & tools

lore

Ortwin Glück

author

2008-09-15 15:50 UTC #0 lore raw

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

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 <[email protected]>

---
 net/mac80211/mlme.c |   10 +---------
 1 files changed, 1 insertions(+), 9 deletions(-)

net/mac80211/mlme.c +1 -9

index 902cac1..5dbe012 100644
@@ -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;

Signature · 1 line

1.5.6.4

Johannes Berg

maintainer

2008-09-15 15:54 UTC #1 lore raw

Quoted 5 lines · 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.

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

Ortwin Glück

author

2008-09-15 16:01 UTC #2 lore raw

Quoted 2 lines · Johannes Berg

Quoted 1 line · 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

Quoted 3 lines

Quoted 3 lines
the auth_alg that was set before.
NB: this may have side-effects with automatic algorithm selection if=

AP responds=20

Quoted 5 lines

Quoted 1 line
with alg not supported.
=20
This seems entirely wrong.
=20
Is your AP not capable of/configured to do open auth and _also_ doesn=

Quoted 1 line

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Johannes Berg

maintainer

2008-09-15 16:05 UTC #3 lore raw

Quoted 11 lines · Ortwin Glück

Quoted 9 lines · Johannes Berg
Quoted 5 lines · 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.
This seems entirely wrong.

Quoted 7 lines

Quoted 2 lines
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?

Quoted 3 lines

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

Ortwin Glück

author

2008-09-15 16:39 UTC #4 lore raw

Quoted 1 line · Johannes Berg

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)

Johannes Berg

maintainer

2008-09-15 18:16 UTC #5 lore raw

Quoted 6 lines · Ortwin Glück

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

Ortwin Glück

author

2008-09-15 19:02 UTC #6 lore raw

Quoted 6 lines · Johannes Berg

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

Luis R. Rodriguez

2008-09-15 20:49 UTC #7 lore raw

Quoted 3 lines · Ortwin Gl=FCck

Quoted 2 lines · Johannes Berg
The packet capture indicates that the packets are retransmitted indicating that the AP isn't even acknowledging them, which in tur=

Quoted 1 line

Quoted 1 line
indicates it's not receiving them. This suggests there's something =

wrong

Quoted 5 lines

Quoted 3 lines
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.

Quoted 1 line

And guess what: auth and association works straight away. Apparently =

ath9k sets

Quoted 1 line

up the card so badly that the transmission power is extremely low! Al=

so I

Quoted 1 line

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html