On Tue, 2013-11-05 at 14:36 +0100, Simon Wunderlich wrote: > > On Mon, 2013-11-04 at 15:31 +0100, Simon Wunderlich wrote: > > > > > Thanks for checking back - I've read the part in the spec again [1], > > > > > and appearently you are right. > > > > > > > > > > With your proposed change, shouldn't we also change the behaviour if > > > > > the userspace requests a channel switch with count = 0? I guess we > > > > > should immediately change the channel then without waiting for > > > > > beacons? I don't see the point in changing the beacons if we don't > > > > > send them, after all. > > > > > > > > You're right, changing the beacons doesn't make sense in this case. > > > > I'll change that and send v2. > > > > > > > > Another thing is that we are missing the action frames. The idea with > > > > the count == 0 is that the STA's should start listening on the other > > > > channel immediately after receiving the action frame (because the > > > > switch will happen at any time). > > > > > > > > If we don't send the action frame, passing context == 0 from the > > > > userspace doesn't much make sense, because the clients won't know we're > > > > switching. Well, maybe it makes a bit of sense, if there are no > > > > clients connected, but nevertheless. > > > > > > Yeah, switching without actionframe and count == 0 is pretty useless. > > > > Actually, if the userspace requests count == 1, we won't have any > > beacons either, because 1 means "just before the next TBTT". So for > > count == 1 (coming from the userspace) we shouldn't configure the > > beacon, since we won't send it. We need the action frame for this case > > too. > > > > Hmm, right, we will decrement the counter before sending it out ... I think this won't be a problem anymore when I change the code to switch channel immediately (without setting the beacons) in case of count == 0 and count == 1. > > > For AP mode, I guess the right place to implement the action frames would > > > be hostap? This would at least allow great flexibility with CSA, ECSA > > > and all the new channel switch IEs coming now. The beacons are also > > > generated in userspace, after all. > > > > What new channel channel switch IEs? > > Right now we also have extendended channel switch announcements (ECSA), and > secondary channel offset, and there are more to come with 802.11ac I think. I > have not studied it yet (and I don't have access to 802.11 drafts), but have a > look at that: > > https://mentor.ieee.org/802.11/dcn/13/11-13-0105-00-00ac-lb190-proposed- > resolution-on-cid-7367-and-7368.docx&ei=T_N4UuHWGcmt4ATQj4DwBg&usg=AFQjCNE5E- > bpqRGQM7-QwG0L4TiU3OOLig&bvm=bv.55980276,d.bGE&cad=rja > > (not only the .doc format is ugly) Yes, you're right. In 11ac there are a few more elements that should go in the CSA action frame. And some wrappers and other things that go in the beacons and probe_resps during CSA. But still, for the action frames, these are rather static and I don't think it's really bad to do it in mac80211 itself. But I don't have a strong opinion regarding this... > > You're right that it might make sense to implement the action frames in > > hostap. But OTOH, the action frame is quite simple and mac80211 should > > have all the information needed to send it out. > > > > > BTW, I've just checked and the WiFi Alliance requires at least 5 beacons > > > with CSA-IEs to pass the 802.11h test. :) > > > > Do you mean that the tests only check when count starts as > 5? > > > > It checks if the last beacon hast a CSA IE in the beacon, and also if there > are 4 beacons before that including a CSA IE. It does not check for the count > though, but that's implicitly given ... Okay, so we just need to remember to use count >= 6 when testing. ;) -- Luca. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
