From: Dan Williams <dcbw@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Lars Ericsson <Lars_Ericsson@telia.com>,
linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
Subject: RE: Roaming problems
Date: Wed, 23 Apr 2008 12:21:53 -0400 [thread overview]
Message-ID: <1208967713.24395.4.camel@localhost.localdomain> (raw)
In-Reply-To: <1208962748.31429.84.camel@johannes.berg>
On Wed, 2008-04-23 at 16:59 +0200, Johannes Berg wrote:
> > > > + // make sure no association start before we got a new BSSID
> > > > + ifsta->flags &= ~IEEE80211_STA_BSSID_SET;
> > >
> > > I don't think that patch makes sense, after all, userspace could request
> > > to disassociate and afterwards re-request to associate by setting the
> > > SSID and not setting the BSSID again, which would lose the fixed BSSID
> > > without userspace interaction.
> > >
> > > However, I'm not sure how to fix this.
> >
> > Enhance roaming support in wpa_supplicant I'd expect. If you set the
> > BSSID explicitly, which wpa_supplicant does, then the driver should not
> > roam to any other BSSID until userspace sends SIOCSIWAP
> > 00:00:00:00:00:00 or sets whatever the 'disabled' flag is. Such is
> > WEXT.
> >
> > I'm not actually sure why wpa_supplicant sets the BSSID explicitly, but
> > I also haven't looked into it much.
>
> Lars mentioned that it sets the SSID first and then the BSSID, maybe the
> trivial fix would be to make it do that the other way around?
Maybe, but why should the driver care? It should be re-attempting
association when either of SSID or BSSID gets set, interrupting any
current ongoing association to a different AP.
Dan
next prev parent reply other threads:[~2008-04-23 16:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 15:09 Roaming problems Lars Ericsson
2008-04-23 8:39 ` Lars Ericsson
2008-04-23 11:12 ` Johannes Berg
2008-04-23 13:53 ` Dan Williams
2008-04-23 14:59 ` Johannes Berg
2008-04-23 16:21 ` Dan Williams [this message]
2008-04-23 16:39 ` Johannes Berg
2008-04-23 16:44 ` Lars Ericsson
2008-04-23 16:53 ` Johannes Berg
2008-04-23 17:12 ` Lars Ericsson
2008-04-23 17:59 ` Johannes Berg
2008-04-23 16:27 ` Lars Ericsson
2008-04-23 16:31 ` Dan Williams
2008-04-23 20:47 ` John W. Linville
2008-04-24 6:45 ` Holger Schurig
2008-04-24 9:55 ` Lars Ericsson
2008-04-24 9:59 ` Johannes Berg
2008-04-24 17:36 ` Lars Ericsson
2008-04-26 20:54 ` Johannes Berg
2008-04-28 18:28 ` Lars Ericsson
2008-04-28 18:34 ` Johannes Berg
2008-04-28 18:43 ` Dan Williams
2008-04-28 20:22 ` Lars Ericsson
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=1208967713.24395.4.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=Lars_Ericsson@telia.com \
--cc=hostap@lists.shmoo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.