On 23/10/2012 08:20, Michal Kazior wrote:
On 14/10/12 16:48, Victor Goldenshtein wrote:+static int nl80211_ap_channel_switch(struct sk_buff *skb, + struct genl_info *info) +{This function should probably enforce interface combinations with `cfg80211_can_use_chan()`. Otherwise we might end up in a state which doesn't correspond to any interface combination - and won't be able to bring up new interfaces.
I guess you're right, we probably should check here whether we can switch to the next channel (with cfg80211_can_use_chan) and in the case we're not, the AP/GO should be disabled.
This however introduces a new problem. Let's suppose we have 2 APs on channel 1. The device doesn't support multi-channel. We won't be able to switch channel on these APs at all. We might want to change the channel switch to resolve around the channel itself (not the interface) - so we'd be saying "move all interfaces with channel X to channel Y" instead of "move interface X to channel Y". Or we could let the driver decide what it'll do - e.g. silently switch more than one interface to a different channel (which makes sense with AP/DFS I guess) and just notify cfg/userspace about it. That would require us to provide a way to switch interfaces (atomically possibly) between channels while keeping in sync with interface combinations though.
If the driver/device supports MR only on a SC - means it doesn't supports channel switch in MR, so basically the radar detection event triggers AP channel switch which fails (with this new check) and the AP shut down. Of course there are possible driver specific workarounds (as you mentioned above) but these are not part of this series.
Just for interest's sake, what is the use case having two APs on the same channel?
-- Thanks, Victor. -- 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
