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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
