linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wojciech Dubowik <dubowoj@neratec.com>
To: linux-wireless <linux-wireless@vger.kernel.org>
Cc: lrodriguez <lrodriguez@atheros.com>, nbd <nbd@openwrt.org>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: [RFC] mac80211: Wait with enabling beacons on DFS channels
Date: Tue, 11 Jan 2011 15:40:56 +0100 (CET)	[thread overview]
Message-ID: <15461044.40.1294756856032.JavaMail.wlan@CHBU500181> (raw)
In-Reply-To: <5840411.32.1294754666078.JavaMail.wlan@CHBU500181>

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?


Br,
Wojtek

       reply	other threads:[~2011-01-11 14:41 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 ` Wojciech Dubowik [this message]
2011-01-11 15:14   ` [RFC] mac80211: Wait with enabling beacons on DFS channels Bernhard Schmidt

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=15461044.40.1294756856032.JavaMail.wlan@CHBU500181 \
    --to=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).