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 -- 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
