On Tue, 2014-02-04 at 12:57 +0100, Johannes Berg wrote: > On Tue, 2014-02-04 at 13:42 +0200, Luca Coelho wrote: > > > Nothing! As far as that's permissible. Ilan's patchset might change > > > that, but that's mostly a regulatory thing, rather than a CSA thing. > > > > Ah, you have some insider information! :P > > Not really, he posted those patches ... :) Heh, I should read the mailing list more carefully instead of marking everything as read without reading. ;) > > Sure, but how does the userspace know that the other interface *needs* > > to be moved, regardless of regulatory problems? It needs to know that > > there are not enough contexts to keep the interfaces in different > > channels... > > It has all that information, it can know the channels, channel contexts, > etc. Okay, so I assume it also knows how many vifs can be in the same context and all the possible vif type combinations. And do the same checks that cfg80211 already does... > > > > ...and, if the userspace doesn't react, we disconnect the GO. I think > > > > it's safer this way for the GO-follows-STA case. > > > > > > That would be a consequence of Ilan's work, yes. > > > > Okay, if that's going to be guaranteed, I'm fine with it. > > Not yet, but Ilan probably needs to take care of that. > > > > This typically won't happen, since userspace will do something else, but > > > we need to have some default policy. I don't think anything else makes > > > much sense? > > > > My point was that a CSA could have been triggered due to regulatory > > (which the AP/GO is monitoring), so the safest would be to move everyone > > out of the channel by default. > > But the kernel can't do that, it needs userspace to do it. Right, but by "moving out of the channel by default" I meant disconnecting those who don't so we are sure there's no one left. > And if the > CSA was triggered due to regulatory, then the GO that follow the client > can only be on this channel with Ilan's work, otherwise it's allowed to > be standalone there. Okay, I'll check Ilan's patches. -- Luca. -- 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
