On 7 May 2014 10:05, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2014-05-07 at 09:25 +0200, Michal Kazior wrote: > >> > Should csa_active really stay true in the reserved_chanctx case? >> > Wouldn't that leave it beaconing, with potentially suddenly negative >> > (due to underflow) CSA counter, or something? >> >> Hmm.. I think drivers should check ieee80211_csa_is_complete() before >> calling to ieee80211_beacon_get(). At least that's what ath9k and >> ath10k effectively do now. Hwsim might complain though but this should >> be changed for multi-vif CSA. You may need to wait for other vifs to >> finish CS (the incompat case) so you shouldn't call >> ieee80211_beacon_get() after you get last CSA beacon on a given AP >> vif. > > 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. 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. Michał -- 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
