> > > + // 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? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
