On Wed, 2014-05-07 at 11:05 +0200, Michal Kazior wrote: > > I don't think that works for all drivers - only drivers that actually > > generate and tx each beacon - but other drivers just update a template. > > We actually have some pending patches to make that work correctly for > > the CSA counters, but I'm not really sure what you want to happen in the > > case that one is switching while the other hasn't yet? Should it stop > > beaconing? Seems like clients would give up the switch then, no? > > Ah, I completely forgot about the template-based approach. > > But I don't think any beacons should be sent after cs_count=1 on the > old channel either way. Thus, I would expect template-based drivers to > stop beaconing after cs_count=1. cs_count=0 is a separate case as it > means "i can disappear at any time now" and is a special case, not > what happens after reaching cs_count=1 if I remember correctly. 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. > Clients should expect next beacon to appear on the new channel after > seeing beacon with cs_count=1. In that case regular cqm for clients > should apply. > > Real-world multi-vif CSA will probably be off by up to 1 or 2 beacon > intervals between vifs which should be disruptive for clients I guess. "not be disruptive"? 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? 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
