> > 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 > Currently this is what happens most of the time, when all ioclts had been issued from the driver, it drops current authentication/association atempts and start with the new one. Most of the times that works fine. But sometimes, when for any reason the 3 ioctls get delayed, the driver may success to associate with the old BSSID (since that is still valid in the driver). Then when all 3 ioctls has been received, including the new BSSID, the driver re-starts the authentication/association sequence with the new BSSID. The problem is that the STA already have a valid association with the first AP. In this case the new BSSID silently ignores any authentication/association attempts. My believe is that it knows that the STA already have a valid association. Could the problem be that the wpa_supplicant not issue a BSSID 00:00:00:00:00:00 before start the configuration to the new BSSID ? /Lars -- 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
