> 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."
If it says for 1 "just before the next TBTT", then this would mean the next
beacon is on the next channel. I'd interpret then that for count=0, the
channel switch happens as soon as possible, and may happen any time 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.
Hm, I think you are right, although I'm not sure how easy that would be
implementation-wise.
BTW, for that case I think we also have to fix the client side, which is
currently switching immediately for count = 1 and not waiting for the next
TBTT. (see end of ieee80211_sta_process_chanswitch(), the rest appears correct
though).
>
> 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?
As said above, I'd interpret it as the change should happen as soon as
possible. If count = 1 means the change will happen "immediately before the
next TBTT", I would guess 0 would mean even before that, or at least not after
the "before the next TBTT".
I agree that the spec is not perfectly clear about that, but I currently don't
see any other reasonable interpretation here ...
Cheers,
Simon
--
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
