On Mon, 2013-11-04 at 14:36 +0100, Simon Wunderlich wrote:
> Hey Luca,
Hey Simon,
Thanks for your quick reply. :)
> > A beacon should never have a Channel Switch Announcement information
> > element with a count of 0, because a count of 1 means switch just
> > before the next beacon. So, if a count of 0 was valid in a beacon, it
> > would have been transmitted in the next channel already, which is
> > useless. A CSA count equal to zero is only meaningful in action
> > frames or probe_responses.
> >
> > Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
> > functions accordingly.
> >
> > Cc: Simon Wunderlich <sw@xxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Luciano Coelho <luciano.coelho@xxxxxxxxx>
> > ---
> >
> > Hi Simon (et al),
> >
> > I identified this issue while playing around with CSA. I noticed that
> > we are sending a CSA beaon with count == 0, which should not happen.
> > The last beacon visible in the current channel (ie. before the switch)
> > contains a CSA IE with count == 1.
> >
> > I wanted to check with you if my proposed change would have any
> > side-effects, especially with the ath9k driver, which is the only user
> > of this code in the mainline at the moment.
> >
> > The potential danger here is if you don't check
> > ieee80211_csa_is_complete() before you send the first CSA beacon out.
> > With the previous code, there would always be a beacon with CSA (count
> > == 0), but now, if the count starts with 1, there won't be any. If
> > you don't check, my patch will probably introduce a WARN when the
> > ath9k driver tries to get the beacon without checking for CSA
> > completion..
> >
> > Any other comments or a sanity check would also be appreciated.
>
> 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.
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).
I'll probably start looking into the action frame implementation soon.
> 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. :\
--
Cheers,
Luca.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
