On 7 May 2014 13:19, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > 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? I can smell a recursive start-stop ping-pong if you restart unconditionally. Michal -- 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
