On Wed, 2014-05-07 at 10:27 +0000, Peer, Ilan wrote: > > In the first case, there's no notification, nor any need for it. In the second > > case, the scenario you suggest doesn't apply, and STOP_AP has to happen > > anyway because the state is completely messed up, clients will be in the > > process of switching etc. > > > > > Other than that, a STOP_AP might introduce some races, as > > > wpa_supplicant/hostap will not know if the stop_ap was due to the > > > failed CS or due to some other reason. > > > > I don't see why that would matter - even if the STOP_AP *was* for some > > other reason, but happened in the middle of the CS flow, the reaction would > > presumably be the same? > > > > It can be beneficial to know that the STOP_AP was called due to > failure of CS, as wpa_supplicant/hostap can tear down the AP and then > (if possible) set it up again on the new channel or another channel. Maybe that's more of an argument for adding a sort of "reason" or "cause" to the STOP_AP? (Btw, no tear down needed in this case - that's already done) OTOH, what else are you thinking of doing? Why would you ever, under any circumstances, not restart the AP if it was stopped by the device? johannes -- 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
