From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Victor Goldenshtein <victorg@ti.com>,
linux-wireless@vger.kernel.org, kgiori@qca.qualcomm.com,
mcgrof@frijolero.org, adrian.chadd@gmail.com, j@w1.fi,
coelho@ti.com, assaf@ti.com, yoni.divinsky@ti.com, igalc@ti.com,
adrian@freebsd.org, nbd@nbd.name,
simon.wunderlich@s2003.tu-chemnitz.de
Subject: Re: [PATCH v2 3/7] nl80211/cfg80211: add ability to enable TX on op-channel
Date: Wed, 20 Jun 2012 13:53:47 +0200 [thread overview]
Message-ID: <4FE1B9CB.2090206@neratec.com> (raw)
In-Reply-To: <1340181992.4655.39.camel@jlt3.sipsolutions.net>
On 06/20/2012 10:46 AM, Johannes Berg wrote:
> On Wed, 2012-06-20 at 10:44 +0200, Johannes Berg wrote:
>>> + if ((!chan->radar_detect_timeout ||
>>> + time_is_after_jiffies(chan->radar_detect_timeout)) &&
>>> + (chan->flags & IEEE80211_CHAN_RADAR))
>>> + return -EPERM;
>>
>> Ok so you reject it if it's 0, but the jiffies calculation could return
>> 0 too.. in fact, since jiffies start at -5 minutes on boot, you might
>> even hit it if you start radar detection 4 minutes after boot.
>
> Also, it seems that the value should be reset eventually ... at least on
> interface down or so. Otherwise you can start CAC, then bring the
> interface down to stop the device, and then bring it back up (CAC check
> is no longer running) and then you can use the channel after some time
> even though you never really checked for radar...
>
No, if you bring it back up on the same DFS channel,
radar_detection_timeout will be set back to +60s by
start_radar_detection(). Looks safe to me.
> And if you start CAC on two different devices on the same channel, but
> they happen to share channel structs in the driver then this will all
> conflict quite badly.
>
Details ;) In fact, if you start device A at a DFS channel and device B
at the same channel 50secs later and device A did not detect radars
after 60secs, ideally both should get TX enabled at the same time with
B's CAC being aborted after 10secs.
For that radar_detect_timeout had to be per wiphy.
With the proposal here you have to wait for the last device to pass the
CAC and if you alternatively put devices A and B up and down every
30secs you can effectively prevent them from TXing forever.
>
> This needs a lot of more thinking it seems.
>
> johannes
>
next prev parent reply other threads:[~2012-06-20 11:53 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 13:10 [PATCH v2 1/7] nl80211/cfg80211: add radar detection command/event Victor Goldenshtein
2012-06-19 13:10 ` [PATCH v2 2/7] mac80211: " Victor Goldenshtein
2012-06-20 8:40 ` Johannes Berg
2012-06-19 13:10 ` [PATCH v2 3/7] nl80211/cfg80211: add ability to enable TX on op-channel Victor Goldenshtein
2012-06-20 8:44 ` Johannes Berg
2012-06-20 8:46 ` Johannes Berg
2012-06-20 11:53 ` Zefir Kurtisi [this message]
2012-06-20 11:57 ` Johannes Berg
2012-06-20 12:58 ` Zefir Kurtisi
2012-06-20 13:12 ` Johannes Berg
2012-06-20 13:32 ` Goldenshtein, Victor
2012-06-20 14:18 ` Johannes Berg
2012-06-20 13:38 ` Zefir Kurtisi
2012-06-20 14:19 ` Johannes Berg
2012-06-20 15:06 ` Goldenshtein, Victor
2012-06-20 14:34 ` Goldenshtein, Victor
2012-06-19 13:11 ` [PATCH v2 4/7] mac80211: " Victor Goldenshtein
2012-06-19 13:11 ` [PATCH v2 5/7] nl80211/cfg80211: add ap channel switch command/event Victor Goldenshtein
2012-06-20 8:47 ` Johannes Berg
2012-06-20 17:17 ` Goldenshtein, Victor
2012-06-20 17:39 ` Johannes Berg
2012-06-21 5:35 ` Goldenshtein, Victor
2012-06-21 7:06 ` Johannes Berg
2012-06-19 13:11 ` [PATCH v2 6/7] mac80211: " Victor Goldenshtein
2012-06-20 8:48 ` Johannes Berg
2012-06-19 13:11 ` [PATCH v2 7/7] mac80211: add DFS support to monitor interface Victor Goldenshtein
2012-06-20 8:49 ` Johannes Berg
2012-06-20 16:50 ` Goldenshtein, Victor
2012-06-20 8:40 ` [PATCH v2 1/7] nl80211/cfg80211: add radar detection command/event Johannes Berg
2012-06-20 12:22 ` Zefir Kurtisi
2012-06-20 12:29 ` Johannes Berg
2012-06-20 16:42 ` Goldenshtein, Victor
2012-06-20 17:40 ` Johannes Berg
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=4FE1B9CB.2090206@neratec.com \
--to=zefir.kurtisi@neratec.com \
--cc=adrian.chadd@gmail.com \
--cc=adrian@freebsd.org \
--cc=assaf@ti.com \
--cc=coelho@ti.com \
--cc=igalc@ti.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=kgiori@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@frijolero.org \
--cc=nbd@nbd.name \
--cc=simon.wunderlich@s2003.tu-chemnitz.de \
--cc=victorg@ti.com \
--cc=yoni.divinsky@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.