On Wed, 2014-05-07 at 11:41 +0200, Michal Kazior wrote: > > I'm not really sure how this would work though - drivers that have > > firmware generating beacons don't generally seem to be in a position to > > just stop that aspect and continue operating otherwise, with active > > clients and all that. It seems to me this might be really difficult to > > implement. > > Yeah. This seems like a problem for template drivers. But on the other > hand if they are capable of handling CSA IE counter they should > understand CSA, shouldn't they? Yeah but that doesn't mean they can simply stop beaconing for "extended" periods of time. > > Remind me why we're doing this - didn't you originally have something in > > mind that was forcing them all to be synchronized with the switch? > > No, not really. > > With per-vif CSA requests you can end up submitting requests between > vif TBTTs, no? Having an atomic "switch vif1,vif2,vif3 to chanX" could > help - although currently ieee80211_beacon_get() isn't really > synchronized well so you still hit the problem. > > And how do you expect to deal with multi-vif with APs with different > beacon intervals? Those inherently can't be tightly synchronized. The > same goes for AP+STA if you start AP first (with the other way around > you could, in theory, match STA's AP TBTT with your own). I'm not really sure all of these are cases that we need to consider though? Multi-BSS I totally see, but if you're trying to do that with different beacon intervals you're probably in a world of pain already - not sure we should support that to start with... AP/GO-follows-STA I can also see, due to regulatory and concurrent BSS/P2P usage. As for those other cases, are they really relevant? 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
