> > 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. > > Uh huh. Aren't we disassociating when we change to a new bssid? > I think the best way would be check the trace I attached in the first post. /LaE -- 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