From: Bernhard Schmidt <bernhard.schmidt@saxnet.de>
To: Wojciech Dubowik <dubowoj@neratec.com>
Cc: "linux-wireless" <linux-wireless@vger.kernel.org>,
lrodriguez <lrodriguez@atheros.com>, nbd <nbd@openwrt.org>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC] mac80211: Wait with enabling beacons on DFS channels
Date: Tue, 11 Jan 2011 16:14:08 +0100 [thread overview]
Message-ID: <201101111614.09073.bernhard.schmidt@saxnet.de> (raw)
In-Reply-To: <15461044.40.1294756856032.JavaMail.wlan@CHBU500181>
On Tuesday, January 11, 2011 15:40:56 Wojciech Dubowik wrote:
> Hello,
> Basic DFS functionality requires that when we change to radar
> enabled channels we need to wait and listen before we can send
> beacons/frames -> Channel Availability Check (CAC).
> There is a case when we can switch to it immediately if we have
> been monitoring it off_channel for specific time. This is bit
> more complicated and doesn't need to be implemented in the first
> place because it's sort of functional optimization.
>
> Anyway there is a need for mechanism to control when to enable
> beacons if we switch to radar channel.
>
> Pseudo-code-diff bellow is an example for ath9k where we could enable
> beacons at once or fire a worker to re-enable it after CAC expires
> if radar hasn't been detected. In theory we need only to disable
> beacons because we shouldn't get any directed frames we could reply
> to and stations anyway can't probe directly. In practice to be
> sure it couldn't be probably done with making rx filters more
> restrictive during CAC period. Maybe there are other ways as well.
>
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -285,8 +285,14 @@
> ath9k_hw_set_interrupts(ah, ah->imask);
>
> if (!(sc->sc_flags & (SC_OP_OFFCHANNEL))) {
> - if (sc->sc_flags & SC_OP_BEACONS)
> - ath_beacon_config(sc, NULL);
> +
> + if (sc->sc_flags & SC_OP_BEACONS) {
> + if (channel->flags & IEEE80211_CHAN_RADAR
> + && !(channel->flags &
> IEEE80211_CHAN_NOL_FREE)) +
ieee80211_queue_delayed_work
> + (sc->hw, &sc->dfs_wait_cac_work, 0);
> + else
> + ath_beacon_config(sc, NULL);
> + }
> +
> ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
0);
> ath_start_ani(common);
> }
>
>
>
> Problem with this solution is that every driver would need to do
> their own timers and state machines to get this functionality which
> is shared by all.
> I don't know about other driver's structures but maybe a better way
> would be to implement mac80211 command to disable/enable beacons and
> set rx filters which every driver supporting DFS would have to implement.
> Mac80211 would have then timer which would control when to enable
> beacons. I guess Non Occupancy List (NOL) would be handled there as
> well so all the DFS timers could be in the same place.
>
> Any comments?
Afaik we did discuss this on IRC a few weeks ago and if I remember correctly
we decided to discard any configuration request before the CAC is over and the
channel is marked as 'clean'. As in, hostapd is modified such that it sends a
'do radar stuff now' command and only if the channel can be marked as clean
sending the actual configuration, in between those is the CAC period.
--
Best regards,
Dipl.-Inf. (FH) Bernhard Schmidt (software development)
saxnet GmbH, Willy-Brandt-Ring 1, 08606 Oelsnitz
Tel. +49 (0) 3741 300 6. 100 - Fax +49 (0) 3741 300 6. 101
managing director: Steffen Dreise - county court Chemnitz - HRB 23017
http://www.saxnet.de
prev parent reply other threads:[~2011-01-11 15:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5840411.32.1294754666078.JavaMail.wlan@CHBU500181>
2011-01-11 14:40 ` [RFC] mac80211: Wait with enabling beacons on DFS channels Wojciech Dubowik
2011-01-11 15:14 ` Bernhard Schmidt [this message]
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=201101111614.09073.bernhard.schmidt@saxnet.de \
--to=bernhard.schmidt@saxnet.de \
--cc=dubowoj@neratec.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=lrodriguez@atheros.com \
--cc=nbd@openwrt.org \
/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).