dcbw at redhat.com
Wed Apr 23 12:21:53 EDT 2008
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.
More information about the HostAP