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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).