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

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2014-05-07 at 06:08 +0000, Peer, Ilan wrote:

> > I'm not really sure why you have this - it seems that in this case the interface
> > will be stopped so you'll get a STOP_AP or DISCONNECT or whatever other
> > notification. This may not actually be completely true right now (I seem to
> > remember a fix in this area but can't seem to find it in my tree!!) but we'll
> > have to fix that part anyway. Not really sure why then that couldn't be used
> > instead of this notification? The userspace code is going to have to worry
> > about that anyway, I'd think.
> > 
> 
> At least for AP/GO, there are cases that a failed channel switch
> should not necessarily trigger a STOP_AP flow. For example, in case
> that multi-channel is supported, wpa_supplicant might request a
> channel switch to try to switch an AP/GO interface to a channel used
> by a station interface (to avoid multi channel operation), but in case
> that such a transition fails, it is still a valid to continue to use
> current channel and do not stop the GO. In such a case, it would be
> useful to get a failure notification. Generally, I think that since
> hostapd/wpa_supplicant have started the channel switch, it might be
> better to have them handle a notification and take the appropriate
> action (if needed stop the AP/GO ...). 

I don't understand this - there are two ways the channel switch can
fail:

 * the request fails
   this just returns an error code to userspace during the request,
there's no
   notification even with these patches
 * the request succeeds, but real switch fails
   we beacon with the CSA, counting it down etc., but when it comes to
actually
   switching, the switch fails. This should hopefully be rather
unlikely, but if
   it really happens the only thing we can do to recover (and actually
do now
   after Michal's patches) is to STOP_AP

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?

johannes