RE: Roaming problems

[Dan Williams <dcbw@redhat.com>]

On Wed, 2008-04-23 at 18:27 +0200, Lars Ericsson wrote:
> > > The below patch makes sure that we drop the BSSID when we 
> > disassociate.
> > 
> > > --- a/ieee80211_sta.c	Wed Apr 23 10:14:30 2008
> > > +++ b/ieee80211_sta.c	Wed Apr 23 08:41:23 2008
> > > @@ -479,6 +479,9 @@ static void ieee80211_set_associated(str
> > >  		netif_carrier_off(dev);
> > >  		ieee80211_reset_erp_info(dev);
> > >  		memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
> > > +
> > > +		// 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.
> > 
> 
> Ok, I had that in mind but could not see how to solve that.
> 
> The root problem is that the drive start associate when any of the
> ieee80211_ioctl_siwgenie()
> ieee80211_ioctl_siwessid() and ieee80211_ioctl_siwap() is called.
> If the wpa_supplicant need call more than one of them the association start
> to early.

When either SIWESSID or SIWAP is called, the driver should restart
association using the latest settings sent by the supplicant.  So by the
end of the GENIE -> SSID -> BSSID call chain, the driver should have
everything it needs to associate, and should restart association with
those parameters.

Dan