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.
Therefore, we can enable scans while on DFS channels, unless there is
CAC going on (must be continuous) or a CSA is happening.
Reported-by: Mathias Kretschmer <[email protected]>
Cc: Eliad Peller <[email protected]>
Signed-off-by: Simon Wunderlich <[email protected]>
---
net/mac80211/scan.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 47d2ed570470..58a454515a5a 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -477,8 +477,11 @@ static int ieee80211_start_sw_scan(struct ieee80211_local *local,
static bool ieee80211_can_scan(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata)
{
- if (ieee80211_is_radar_required(local))
- return false;
+ if (sdata->wdev.cac_started)
+ return -EBUSY;
+
+ if (sdata->vif.csa_active)
+ return -EBUSY;
if (!list_empty(&local->roc_list))
return false;
@@ -550,7 +553,7 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
lockdep_assert_held(&local->mtx);
- if (local->scan_req || ieee80211_is_radar_required(local))
+ if (local->scan_req)
return -EBUSY;
if (!ieee80211_can_scan(local, sdata)) {
--
2.11.0
On Thu, Sep 20, 2018 at 03:30:05PM +0200, Simon Wunderlich wrote:
> Hi Dan,
>
> whoops, right ... thank you!
>
> Will do in a v2, at least if this patch is wanted. :)
>
These are automated emails, I just look at them and forward them. I
don't actually "love your patch" because I haven't even looked at it.
The bot adds that text to sound more friendly...
Presumably the patch is wanted, but I don't know. Anyway, yes, please
do send a v2.
regards,
dan carpenter
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.
johannes
Hi Simon,
I love your patch! Perhaps something to improve:
url: https://github.com/0day-ci/linux/commits/Simon-Wunderlich/mac80211-allow-scans-on-radar-channels-unless-there-is-CAC-or-CSA/20180919-071924
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
New smatch warnings:
net/mac80211/scan.c:508 ieee80211_can_scan() warn: signedness bug returning '(-16)'
Old smatch warnings:
net/mac80211/scan.c:511 ieee80211_can_scan() warn: signedness bug returning '(-16)'
# https://github.com/0day-ci/linux/commit/ad9617f275c425ddf25eb83678062ab87d4c0870
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout ad9617f275c425ddf25eb83678062ab87d4c0870
vim +508 net/mac80211/scan.c
f3b85252 Johannes Berg 2009-04-23 503
133d40f9 Stanislaw Gruszka 2012-03-28 504 static bool ieee80211_can_scan(struct ieee80211_local *local,
^^^^
133d40f9 Stanislaw Gruszka 2012-03-28 505 struct ieee80211_sub_if_data *sdata)
133d40f9 Stanislaw Gruszka 2012-03-28 506 {
ad9617f2 Simon Wunderlich 2018-09-18 507 if (sdata->wdev.cac_started)
ad9617f2 Simon Wunderlich 2018-09-18 @508 return -EBUSY;
^^^^^^^^^^^^^
ad9617f2 Simon Wunderlich 2018-09-18 509
ad9617f2 Simon Wunderlich 2018-09-18 510 if (sdata->vif.csa_active)
ad9617f2 Simon Wunderlich 2018-09-18 511 return -EBUSY;
^^^^^^^^^^^^^^
164eb02d Simon Wunderlich 2013-02-08 512
2eb278e0 Johannes Berg 2012-06-05 513 if (!list_empty(&local->roc_list))
133d40f9 Stanislaw Gruszka 2012-03-28 514 return false;
133d40f9 Stanislaw Gruszka 2012-03-28 515
133d40f9 Stanislaw Gruszka 2012-03-28 516 if (sdata->vif.type == NL80211_IFTYPE_STATION &&
392b9ffb Stanislaw Gruszka 2013-08-27 517 sdata->u.mgd.flags & IEEE80211_STA_CONNECTION_POLL)
133d40f9 Stanislaw Gruszka 2012-03-28 518 return false;
133d40f9 Stanislaw Gruszka 2012-03-28 519
133d40f9 Stanislaw Gruszka 2012-03-28 520 return true;
133d40f9 Stanislaw Gruszka 2012-03-28 521 }
133d40f9 Stanislaw Gruszka 2012-03-28 522
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Dan,
whoops, right ... thank you!
Will do in a v2, at least if this patch is wanted. :)
Thank you!
Simon
On Thursday, September 20, 2018 12:20:14 PM CEST Dan Carpenter wrote:
> Hi Simon,
>
> I love your patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Simon-Wunderlich/mac80211-allow-sc
> ans-on-radar-channels-unless-there-is-CAC-or-CSA/20180919-071924 base:
> https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
>
> New smatch warnings:
> net/mac80211/scan.c:508 ieee80211_can_scan() warn: signedness bug returning
> '(-16)'
>
> Old smatch warnings:
> net/mac80211/scan.c:511 ieee80211_can_scan() warn: signedness bug returning
> '(-16)'
>
> #
> https://github.com/0day-ci/linux/commit/ad9617f275c425ddf25eb83678062ab87d4
> c0870 git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout ad9617f275c425ddf25eb83678062ab87d4c0870
> vim +508 net/mac80211/scan.c
>
> f3b85252 Johannes Berg 2009-04-23 503
> 133d40f9 Stanislaw Gruszka 2012-03-28 504 static bool
> ieee80211_can_scan(struct ieee80211_local *local, ^^^^
> 133d40f9 Stanislaw Gruszka 2012-03-28 505 struct
> ieee80211_sub_if_data *sdata) 133d40f9 Stanislaw Gruszka 2012-03-28 506 {
> ad9617f2 Simon Wunderlich 2018-09-18 507 if (sdata->wdev.cac_started)
> ad9617f2 Simon Wunderlich 2018-09-18 @508 return -EBUSY;
> ^^^^^^^^^^^^^
> ad9617f2 Simon Wunderlich 2018-09-18 509
> ad9617f2 Simon Wunderlich 2018-09-18 510 if (sdata->vif.csa_active)
> ad9617f2 Simon Wunderlich 2018-09-18 511 return -EBUSY;
> ^^^^^^^^^^^^^^
> 164eb02d Simon Wunderlich 2013-02-08 512
> 2eb278e0 Johannes Berg 2012-06-05 513 if
> (!list_empty(&local->roc_list)) 133d40f9 Stanislaw Gruszka 2012-03-28 514
> return false;
> 133d40f9 Stanislaw Gruszka 2012-03-28 515
> 133d40f9 Stanislaw Gruszka 2012-03-28 516 if (sdata->vif.type ==
> NL80211_IFTYPE_STATION && 392b9ffb Stanislaw Gruszka 2013-08-27 517
> sdata->u.mgd.flags & IEEE80211_STA_CONNECTION_POLL) 133d40f9 Stanislaw
> Gruszka 2012-03-28 518 return false;
> 133d40f9 Stanislaw Gruszka 2012-03-28 519
> 133d40f9 Stanislaw Gruszka 2012-03-28 520 return true;
> 133d40f9 Stanislaw Gruszka 2012-03-28 521 }
> 133d40f9 Stanislaw Gruszka 2012-03-28 522
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology
> Center https://lists.01.org/pipermail/kbuild-all Intel
> Corporation
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
On Thu, 2018-09-20 at 12:27 +0200, Simon Wunderlich wrote:
> 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.
I still don't have a document, but we spoke about it at the wireless
workshop and Jouni agrees that this is an absolute no-go for FCC, while
allowed for ETSI.
I guess you can make it depend on the radar domain information.
johannes