linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 4 Nov 2013 15:31:56 +0100	[thread overview]
Message-ID: <201311041531.56693.sw@simonwunderlich.de> (raw)
In-Reply-To: <1383574023.5928.149.camel@porter.coelho.fi>

Hey Luca,

> > 
> > 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.

> 
> 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 ...

> 
> 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. I guess it would be useful to send 
at least the action frames out if we want to change "fast" (count=0).

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.

BTW, I've just checked and the WiFi Alliance requires at least 5 beacons with 
CSA-IEs to pass the 802.11h test. :)

> 
> > 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. :)

Cheers,
    Simon

  reply	other threads:[~2013-11-04 14:31 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 [this message]
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
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=201311041531.56693.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).