On Wed, Sep 29, 2010 at 12:54:27PM +0530, Luis R. Rodriguez wrote: > > (where we just authenticated with another AP) > > Not sure I get this part. I mean we are trying to tx frames on the channel where we got newly authenticated to another AP. > > > just before starting association with the new AP. > > Right, but when we are already switched to the new channel, and the > reason is that when we try to send a frame we never kept track of the > peer's original channel. Now, I also see the teardown happen right > before mac80211 tells us its associated to the new AP as well but it > not sure what cfg80211 thinks at that point. At least the cfg80211 > patch's intention seemed to be to allow association to both, and > tearing down the association to the other once you completed > association to the other. I do see, what you describe though too -- > only authentication to the new AP, and right before association, we > send the teardown. The problem is though that when we send the > teardown we are already set on the new channel. Ok. From my understanding, the sequence of operations during roaming are 1. NL80211_CMD_AUTHENTICATE to an (better) AP from user space - Change to New Ap's channel and send auth req (done by ieee80211_work_work()). - Notify auth resp to userspace (ieee80211_probe_auth_done()) 2. NL80211_CMD_ASSOCIATE to newly authenticated AP from user space - Clean up any existing BA session with an AP, if any. Here the assumption is, ieee80211_work_work() has already configured the device back to it's operating channel (the old one) after the authentication is complete with the new AP. This should have happened part of 1. - Start the association process with the new AP. Vasanth -- 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
