On Tue, 2013-11-05 at 10:27 +0200, Luciano Coelho 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.
Hmmm... Now there's something that is a bit unclear to me in the specs:
"For nonmesh STAs, the Channel Switch Count field either is set to the
number of TBTTs until the STA sending the Channel Switch Announcement
element switches to the new channel or is set to 0."
There's nothing specifying exactly when, relative to the beacon, the
switch actually happens. Just before? Just after? Is the beacon that
matches that TBTT transmitted in the current or in the next channel?
For a value of 1, it's pretty clear:
"A value of 1 indicates that the switch occurs immediately before the
next TBTT."
I don't think we're doing that now. At least in the ath9k case, you
switch the channel immediately after the beacon with count == 1, by
calling ieee80211_csa_finish(). The correct would be just before the
next beacon is sent.
A value of 0 is also unclear, because it doesn't refer to any TBTTs at
all. So if you read it literally, the following would mean that it
could at *any* time in the future:
"A value of 0 indicates that the switch occurs at any time after the
frame containing the element is transmitted."
Am I missing something? What do you think?
--
Cheers,
Luca.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
