>
> > > 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
>
Yep, agree that the only valid option here is to stop the 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?
>
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.
Regards,
Ilan.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
