From: Jouni Malinen <j@w1.fi>
To: Jean-Pierre Tosoni <jp.tosoni@acksys.fr>
Cc: 'Ben Greear' <greearb@candelatech.com>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: ath10k firmware sends probes on DFS channels without radar detection
Date: Fri, 16 Dec 2016 00:58:27 +0200 [thread overview]
Message-ID: <20161215225827.GB24883@w1.fi> (raw)
In-Reply-To: <00fd01d256fc$2f780db0$8e682910$@acksys.fr>
On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > Thanks for the suggestion, I already tried something like this in
> > > wmi.c, with the same result:
> > >
> > > - Before patching the firmware scans DFS channels actively (with
> > probes).
> > >
> > > - After patching, the firmware scans DFS channels passively *until*
> > > any beacon is received on the DFS channel. When *any* beacon is seen,
> > > the firmware decides to scan actively on its own, without any new
> > > IR/RADAR info from the driver.
> > >
> > > So, your patch is required but not sufficient.
> > >
> > > Somehow I was able to overcome this by reloading the regulation domain
> > > in the radio card before each scan request:
Interesting.. I'm not completely sure what could have changed the
behavior based on beacon hint. I thought it was cfg80211, but if the
simple change for doing NO_IR | RADAR is not sufficient, it would seem
to imply that something else can do this. Some more debugging to do, I
guess.
> The distinction between NO_IR and CHAN_RADAR is not very clear to me.
> NO_IR appears only in the world regulatory domain so it's not relevant here.
NO_IR is a combination of not allowing AP, IBSS, or active scanning
without having somehow been enabled by another device. RADAR has that
same impact and in addition, requirement for doing radar detection and
DFS by a master device.
> I'd say
> "the CHAN_RADAR flag should always make the firmware never do IR when
> probing"
> ...maybe, except if the channel is the operating channel. (this should
> exclude
> unassociated stations)
For most cases, I'd agree that active scanning should not be used on DFS
channels. That said, unicast Probe Request frame to the current AP while
associated could be a reasonable exception. In addition, WPS with PBC
depends on Probe Request frames to allow PBC session overlap detection,
so there might be sufficient justification to allow Probe Request frame
to be sent out for a very short duration (couple of seconds) after
seeing a Beacon frame on the channel for such special cases.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Jouni Malinen <j@w1.fi>
To: Jean-Pierre Tosoni <jp.tosoni@acksys.fr>
Cc: 'Ben Greear' <greearb@candelatech.com>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: ath10k firmware sends probes on DFS channels without radar detection
Date: Fri, 16 Dec 2016 00:58:27 +0200 [thread overview]
Message-ID: <20161215225827.GB24883@w1.fi> (raw)
In-Reply-To: <00fd01d256fc$2f780db0$8e682910$@acksys.fr>
On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > Thanks for the suggestion, I already tried something like this in
> > > wmi.c, with the same result:
> > >
> > > - Before patching the firmware scans DFS channels actively (with
> > probes).
> > >
> > > - After patching, the firmware scans DFS channels passively *until*
> > > any beacon is received on the DFS channel. When *any* beacon is seen,
> > > the firmware decides to scan actively on its own, without any new
> > > IR/RADAR info from the driver.
> > >
> > > So, your patch is required but not sufficient.
> > >
> > > Somehow I was able to overcome this by reloading the regulation domain
> > > in the radio card before each scan request:
Interesting.. I'm not completely sure what could have changed the
behavior based on beacon hint. I thought it was cfg80211, but if the
simple change for doing NO_IR | RADAR is not sufficient, it would seem
to imply that something else can do this. Some more debugging to do, I
guess.
> The distinction between NO_IR and CHAN_RADAR is not very clear to me.
> NO_IR appears only in the world regulatory domain so it's not relevant here.
NO_IR is a combination of not allowing AP, IBSS, or active scanning
without having somehow been enabled by another device. RADAR has that
same impact and in addition, requirement for doing radar detection and
DFS by a master device.
> I'd say
> "the CHAN_RADAR flag should always make the firmware never do IR when
> probing"
> ...maybe, except if the channel is the operating channel. (this should
> exclude
> unassociated stations)
For most cases, I'd agree that active scanning should not be used on DFS
channels. That said, unicast Probe Request frame to the current AP while
associated could be a reasonable exception. In addition, WPS with PBC
depends on Probe Request frames to allow PBC session overlap detection,
so there might be sufficient justification to allow Probe Request frame
to be sent out for a very short duration (couple of seconds) after
seeing a Beacon frame on the channel for such special cases.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2016-12-15 22:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-06 17:02 ath10k firmware sends probes on DFS channels without radar detection Jean-Pierre Tosoni
2016-12-06 17:02 ` Jean-Pierre Tosoni
2016-12-06 19:36 ` Ben Greear
2016-12-06 19:36 ` Ben Greear
2016-12-14 18:14 ` Jean-Pierre Tosoni
2016-12-14 18:14 ` Jean-Pierre Tosoni
2016-12-14 18:28 ` Ben Greear
2016-12-14 18:28 ` Ben Greear
2016-12-14 19:58 ` Jouni Malinen
2016-12-14 19:58 ` Jouni Malinen
2016-12-15 15:22 ` Jean-Pierre Tosoni
2016-12-15 15:22 ` Jean-Pierre Tosoni
2016-12-15 16:32 ` Ben Greear
2016-12-15 16:32 ` Ben Greear
2016-12-15 17:53 ` Jean-Pierre Tosoni
2016-12-15 17:53 ` Jean-Pierre Tosoni
2016-12-15 22:58 ` Jouni Malinen [this message]
2016-12-15 22:58 ` Jouni Malinen
2016-12-26 11:15 ` Jean-Pierre Tosoni
2016-12-26 11:15 ` Jean-Pierre Tosoni
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=20161215225827.GB24883@w1.fi \
--to=j@w1.fi \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=jp.tosoni@acksys.fr \
--cc=linux-wireless@vger.kernel.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 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.