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.
> > count == 0 should probably be avoided, because the specs are not that
> > clear about it. In case transmission on our channel needs to be stopped
> > immediately (eg. with DSS), we can always use the channel switch mode
> > (ie. no TX until the switch happens).
>
> Hmm, we probably need to review the IBSS part too - we adopt the channel
> switch from others here, and adopting with count = 0 works now but would
> create a warning with your change ...
Okay, I'll check IBSS too.
> > I'll probably start looking into the action frame implementation soon.
>
> I've recently added CSA action frame support for the IBSS mode, because the
> distributed beaconing may lead to slow adoption of the CSA IEs in the IBSS.
> Check ieee80211_send_action_csa() for that.
Cool, I had missed that. I admit I didn't look into IBSS much. That
was going to be my next step. (Isn't that always a good excuse ;)
> I guess it would be useful to send
> at least the action frames out if we want to change "fast" (count=0).
Or 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?
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?
> > > Currently,
> > > ath9k calls the csa_finish() after checking whether beacon sending was
> > > complete ... so this would have to be changed.
> >
> > Yeah, that's what I suspected from my very quick look at the ath9k code.
> > I'll see if I can change this easily. I'll probably need some help with
> > testing, because I don't have an ath9k device. :\
>
> No problem, I can test here, just tell me what to test. :)
Cool! Basically I just want you to make sure what I do still works and I
don't break anything of what you have been doing. ;)
--
Cheers,
Luca.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
