From: Simon Wunderlich <sw@simonwunderlich.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, Eliad Peller <eliad@wizery.com>,
mathias.kretschmer@fit.fraunhofer.de
Subject: Re: [PATCH] mac80211: allow scans on radar channels, unless there is CAC or CSA
Date: Thu, 20 Sep 2018 12:27:05 +0200 [thread overview]
Message-ID: <2969898.mUHQksrBSp@prime> (raw)
In-Reply-To: <1537435276.3874.14.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
On Thursday, September 20, 2018 11:21:16 AM CEST Johannes Berg wrote:
> On Tue, 2018-09-18 at 16:16 +0200, Simon Wunderlich wrote:
> > Operating on a DFS channel doesn't mean we can't leave it for a short
> > time - actually, some features like off-channel CAC work by leaving the
> > operation channel to check other channels for availability (although
> > off-channel CAC isn't implemented in mac80211). In our case, we want to
> > use mesh while doing background surveys on other channels from time to
> > time.
>
> Actually ... as far as I can tell it *does* mean that, at least
> currently for FCC.
Mhm. I remember you said that before. But I can't find references for it. I
checked the FCC 15.407 document [1] but couldn't find anything in favor or
against that. Same for the measurement procedures [2]. I also couldn't find
off-channel CAC in FCC, which I used for my argument in ETSI:
In ETSI 301 893 [3] they talk about non-continuous checks for off-channel CAC
(in 4.2.6.2.3, second paragraph) and continuous period for CAC (4.2.6.2.2.2,
first paragraph). Continuity is not mentioned for in-service monitoring
(4.2.6.2.4), but off-channel CAC could only work when continuity is not
required.
I'd appreciate if you (or someone else) can point me to where it's stated that
we can't leave the channel for the a short time. I'm assuming that we are back
fast enough to ensure the required detection probability.
Cheers,
Simon
[1] https://www.law.cornell.edu/definitions/index.php?
width=840&height=800&iframe=true&def_id=41106ee4d951847389e55571a5e5e8aa&term_occur=1&term_src=Title:
47:Chapter:I:Subchapter:A:Part:15:Subpart:E:15.407
[2] https://apps.fcc.gov/kdb/GetAttachment.html?id=V2DzGgztnfxjTcht59nQ7Q%3D
%3D&desc=905462%20D02%20UNII%20DFS%20Compliance%20Procedures%20New%20Rules
%20v02&tracking_number=27155
[3] https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/
en_301893v020101p.pdf
>
> johannes
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-09-20 16:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-18 14:16 [PATCH] mac80211: allow scans on radar channels, unless there is CAC or CSA Simon Wunderlich
2018-09-20 9:20 ` Dan Carpenter
2018-09-20 13:30 ` Simon Wunderlich
2018-09-20 13:40 ` Dan Carpenter
2018-09-20 9:21 ` Johannes Berg
2018-09-20 10:27 ` Simon Wunderlich [this message]
2019-03-29 10:35 ` 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=2969898.mUHQksrBSp@prime \
--to=sw@simonwunderlich.de \
--cc=eliad@wizery.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mathias.kretschmer@fit.fraunhofer.de \
/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).