On Thu, 2014-01-23 at 08:28 +0200, Luca Coelho wrote: > Why is this necessary? I think it's easier to treat the CSA's > separately. When wpa_supplicant decides to switch channel in one > interface, it asks cfg80211 to do so. Then, if that interface change is > "approved" (ie. there's no internal reason why it would fail), cfg80211 > sends a notification to userspace that the interface will switch. Then > wpa_s decides whether any other interfaces need switching as well (ie. > if it's in the same channel context). I don't think that makes sense. If userspace requested the CSA operation, the fact that it will happen should be known as soon as the request returns 0. No need for a notification (other than when the mlme code in mac80211 decided to switch by itself). You're mixing the cases of GO-follow-client-interface and switch-multiple-AP-BSSes, which I'm not sure is right. The problem with using the approach you're suggesting to switch multiple AP interfaces is that when you do that, you open the system up to races much more than when requesting multiple interfaces at once. Also, I still think we need to enforce that the interface switch at the same time, which would practically be impossible with multiple switch commands. > > This makes it possible for userspace to request a > > multi-interface channel switch while allowing > > sanity checks wrt target interface/channel > > combination. > > Okay, the sanity checks are an interesting issue. But if the > combination is not good, the whole command will fail and none of the > interfaces will switch. If wpa_s does this interface-by-interface, > separately, the triggering interface (ie. the one that decided to switch > in the first place) may succeed while the subsequent requests may fail > (eg. if the interface combination is not allowed in the new channel). > If the second one fails, wpa_s may make another decision, for instance > trying to switch the second interface to a *different* channel instead, > or not switch at all. That makes no sense. You're talking about completely different scenarios, see above. 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
