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(-)
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
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
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
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
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
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
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
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)