public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: driver_nl80211 broken again
Date: Sat, 05 Sep 2009 05:08:23 +0300	[thread overview]
Message-ID: <1252116503.2398.26.camel@maxim-laptop> (raw)
In-Reply-To: <1251147515.20161.3.camel@johannes.local>

On Mon, 2009-08-24 at 22:58 +0200, Johannes Berg wrote:
> On Mon, 2009-08-24 at 23:06 +0300, Maxim Levitsky wrote:
> 
> > This is typical output of iwconfig, after failure
> > (and I know that this output means trouble):
> 
> Hmm, thanks for the info and especially the log. Unfortunately, I can't
> reproduce this at all.
> 
> Can you run wpa_supplicant with timing info (add -t to the command line)
> and at the same time run "iw event -t" please?
> 
> johannes

I have finally got to the bottom of this, ad it doesn't look good.
There are two bugs that overlap:


1 - when connecting again to the access point (same or another), 
wpa_supplicant does the following:

deassoc
auth
assoc

So it assumes that deassoc command disconnects completely, but it not
longer true.
Yet, I have tried to make its dissassoc function do both, but it failed.
I used following patch:


diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index c68dd82..50afeeb 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -1278,8 +1278,10 @@ void wpa_supplicant_disassociate(struct wpa_supplicant *wpa_s,
        if (!is_zero_ether_addr(wpa_s->bssid)) {
                if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_USER_SPACE_MLME)
                        ieee80211_sta_disassociate(wpa_s, reason_code);
-               else
+               else {
                        wpa_drv_disassociate(wpa_s, wpa_s->bssid, reason_code);
+                       wpa_drv_deauthenticate(wpa_s, wpa_s->bssid, reason_code);
+               }
                addr = wpa_s->bssid;
        }
        wpa_clear_keys(wpa_s, addr);


I got this.


EAPOL: startWhen --> 0
EAPOL: disable timer tick
wpa_driver_nl80211_disassociate
wpa_driver_nl80211_deauthenticate
nl80211: MLME command failed: ret=-67 (Link has been severed)



However, this "hack", did the trick:

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 97a278a..60c4355 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2561,7 +2561,7 @@ int ieee80211_mgd_disassoc(struct ieee80211_sub_if_data *sdata,
                return -ENOLINK;
        }
 
-       ieee80211_set_disassoc(sdata, false);
+       ieee80211_set_disassoc(sdata, true);
 
        mutex_unlock(&ifmgd->mtx);
 
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 79d2eec..fec34a7 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -222,7 +222,7 @@ static void __cfg80211_send_disassoc(struct net_device *dev,
                for (i = 0; i < MAX_AUTH_BSSES; i++) {
                        if (wdev->authtry_bsses[i] || wdev->auth_bsses[i])
                                continue;
-                       wdev->auth_bsses[i] = wdev->current_bss;
+                       /*wdev->auth_bsses[i] = wdev->current_bss;*/
                        wdev->current_bss = NULL;
                        done = true;
                        cfg80211_sme_disassoc(dev, i);


With this ugly hack, everything works just fine. 
-----------------------------------------------------------------------------------------------
2 - independent of the above, the ieee80211_set_disassoc
doesn't work right if deauth==false.


If it is, then a work item is added to station work thread, and it is
never removed:

	} else {
		struct ieee80211_mgd_work *wk = ifmgd->old_associate_work;

		wk->state = IEEE80211_MGD_STATE_IDLE;
		list_add(&wk->list, &ifmgd->work_list);
	}


iee80211_sta_work just ignores the IEEE80211_MGD_STATE_IDLE, thus it
work item remains forever.

This breaks scanning, since __ieee80211_start_scan will refuses to run
until, ifmgd->work_list is empty.



Best regards,
	Maxim Levitsky


  reply	other threads:[~2009-09-05  2:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-24 12:32 driver_nl80211 broken again Maxim Levitsky
2009-08-24 14:08 ` Johannes Berg
2009-08-24 20:06   ` Maxim Levitsky
2009-08-24 20:58     ` Johannes Berg
2009-09-05  2:08       ` Maxim Levitsky [this message]
2009-09-05 13:07         ` Johannes Berg
2009-09-08 15:29         ` Johannes Berg
2009-09-08 20:54           ` Maxim Levitsky
2009-09-30  1:19             ` Maxim Levitsky
2009-09-30 22:13               ` Jouni Malinen
2009-10-01  8:46                 ` Johannes Berg
2009-10-02 21:31                   ` Trepak Vilmos
2009-10-03  5:52                     ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1252116503.2398.26.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox