Wed Apr 23 07:59:08 PDT 2008
> > > + // 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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 828 bytes
Desc: This is a digitally signed message part
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20080423/aa4d2841/attachment.pgp
More information about the Hostap