> -----Original Message----- > From: linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless- > owner@xxxxxxxxxxxxxxx] On Behalf Of Johannes Berg > Sent: Tuesday, May 06, 2014 13:47 > To: Luca Coelho > Cc: linux-wireless@xxxxxxxxxxxxxxx; michal.kazior@xxxxxxxxx; Peer, Ilan; > Otcheretianski, Andrei > Subject: Re: [PATCH 1/4] cfg80211/nl80211: add channel switch started and > failed notifications > > On Fri, 2014-05-02 at 16:40 +0300, Luca Coelho wrote: > > > + * @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY: Notify that a channel > switch > > + * has been started on an interface, regardless of the initiator > > + * (ie. whether it was requested from a remote device or > > + * initiated on our own). It indicates that > > + * %NL80211_ATTR_IFINDEX will be on %NL80211_ATTR_WIPHY_FREQ > > + * after %NL80211_ATTR_CH_SWITCH_COUNT TBTT's. > > You don't seem to have that now, but it may not always be needed, and we > could add it later (unless userspace needs to rely on having the attribute - > otherwise it has to check for it) > > Actually though, maybe you do need it, so that you can determine whether it > makes sense to try anything smart - if the count is 1 or you received an action > frame then you probably don't have time at all? > > > + * @NL80211_CMD_CH_SWITCH_FAILED_NOTIFY: Notify that a channel > switch > > + * has failed on %NL80211_ATTR_IFINDEX. This notification can > > + * only be sent after a @NL80211_CMD_CH_SWITCH_STARTED_NOTIFY > has > > + * been issued. > > (+Ilan, Andrei) > > 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 ...). 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. Regards, Ilan. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
