Re: [PATCH 1/4] cfg80211/nl80211: add channel switch started and failed notifications

[Johannes Berg <johannes@sipsolutions.net>]

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