From: Simon Wunderlich <sw@simonwunderlich.de>
To: "Coelho, Luciano" <luciano.coelho@intel.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>
Subject: Re: [RFC] mac80211: don't transmit beacon with CSA count 0
Date: Tue, 5 Nov 2013 14:36:13 +0100 [thread overview]
Message-ID: <201311051436.13222.sw@simonwunderlich.de> (raw)
In-Reply-To: <1383640077.579.14.camel@porter.coelho.fi>
> 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 ...
> > 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)
>
> 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 ...
Cheers,
Simon
next prev parent reply other threads:[~2013-11-05 13:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 12:59 [RFC] mac80211: don't transmit beacon with CSA count 0 Luciano Coelho
2013-11-04 13:36 ` Simon Wunderlich
2013-11-04 14:07 ` Coelho, Luciano
2013-11-04 14:31 ` Simon Wunderlich
2013-11-05 8:28 ` Coelho, Luciano
2013-11-05 10:06 ` Coelho, Luciano
2013-11-05 14:00 ` Simon Wunderlich
2013-11-05 14:35 ` Coelho, Luciano
2013-11-05 13:36 ` Simon Wunderlich [this message]
2013-11-05 14:25 ` Coelho, Luciano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201311051436.13222.sw@simonwunderlich.de \
--to=sw@simonwunderlich.de \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=luciano.coelho@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).