> I'm sending this as patch to keep the versioning, although it can be > considered as RFC, I would be suprised if all single channel/single > interface aspects were considered correctly. :) :) I think we need a bit more "design review" first. To me, the open questions are: * Should switching to a DFS channel be allowed at all? How so, if radar can't be tested before? You just stop the AP instead but userspace can do that just as well. * What happens with multiple virtual interfaces? You allow a single channel context only which makes sense, but that doesn't disallow things like having a client + AP, and then the client switching away because the P2P GO it was connected to randomly decided to switch. This would break radar detection. (1) What should happen in this case? * To avoid that problem, could restrict to a single virtual interface. However, that's unlikely to be sufficient -- you'd want to still be able to implement multi-BSSID APs which then switch together etc. * That raises another interesting question -- should multiple BSSIDs on the same channel really *all* call the driver's ap_channel_switch() callback? That seems ... strange! * Do we need any software channel switch handling? Generally the biggest issue is around multi-channel channel switch behaviour I think. Any good ideas? johannes (1) Actually today it would either break the AP (channel contexts NOT supported by the driver) or disconnect the client (otherwise) -- 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
