In certain circumstances the user might not want to actively
scan DFS channels, therefore add a nl80211 scan flag to
instruct the underlying layers that DFS channels must be
passively scanned.
This flag can be specified upon scan trigger command.
Signed-off-by: Antonio Quartulli <[email protected]>
---
v2: no change
include/uapi/linux/nl80211.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1f0b4cf..2083e53 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4456,12 +4456,14 @@ enum nl80211_connect_failed_reason {
* locally administered 1, multicast 0) is assumed.
* This flag must not be requested when the feature isn't supported, check
* the nl80211 feature flags for the device.
+ * @NL80211_SCAN_FLAG_PASSIVE_RADAR: force passive scan on DFS channels
*/
enum nl80211_scan_flags {
NL80211_SCAN_FLAG_LOW_PRIORITY = 1<<0,
NL80211_SCAN_FLAG_FLUSH = 1<<1,
NL80211_SCAN_FLAG_AP = 1<<2,
NL80211_SCAN_FLAG_RANDOM_ADDR = 1<<3,
+ NL80211_SCAN_FLAG_PASSIVE_RADAR = 1<<4,
};
/**
--
2.6.3
if the NL80211_SCAN_FLAG_PASSIVE_RADAR flag was specified upon
sw scan start, passively scan any channel marked as DFS.
Signed-off-by: Antonio Quartulli <[email protected]>
---
v2: fix variable names and add scan_req argument to
ieee80211_scan_get_channel_time()
net/mac80211/scan.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 4aeca4b..e369d61 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -599,7 +599,9 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
if ((req->channels[0]->flags &
IEEE80211_CHAN_NO_IR) ||
- !req->n_ssids) {
+ !req->n_ssids ||
+ ((req->channels[0]->flags & IEEE80211_CHAN_RADAR) &&
+ (req->flags & NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
} else {
ieee80211_scan_state_send_probe(local, &next_delay);
@@ -639,13 +641,16 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
}
static unsigned long
-ieee80211_scan_get_channel_time(struct ieee80211_channel *chan)
+ieee80211_scan_get_channel_time(struct ieee80211_channel *chan,
+ struct cfg80211_scan_request *scan_req)
{
/*
* TODO: channel switching also consumes quite some time,
* add that delay as well to get a better estimation
*/
- if (chan->flags & IEEE80211_CHAN_NO_IR)
+ if ((chan->flags & IEEE80211_CHAN_NO_IR) ||
+ ((chan->flags & IEEE80211_CHAN_RADAR) &&
+ (scan_req->flags & NL80211_SCAN_FLAG_PASSIVE_RADAR)))
return IEEE80211_PASSIVE_CHANNEL_TIME;
return IEEE80211_PROBE_DELAY + IEEE80211_CHANNEL_TIME;
}
@@ -698,7 +703,8 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
*/
bad_latency = time_after(jiffies +
- ieee80211_scan_get_channel_time(next_chan),
+ ieee80211_scan_get_channel_time(next_chan,
+ scan_req),
local->leave_oper_channel_time + HZ / 8);
if (associated && !tx_empty) {
@@ -777,7 +783,9 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
*
* In any case, it is not necessary for a passive scan.
*/
- if (chan->flags & IEEE80211_CHAN_NO_IR || !scan_req->n_ssids) {
+ if (chan->flags & IEEE80211_CHAN_NO_IR || !scan_req->n_ssids ||
+ ((chan->flags & IEEE80211_CHAN_RADAR) &&
+ (scan_req->flags & NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
*next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
local->next_scan_state = SCAN_DECISION;
return;
--
2.6.3
On 20/11/15 18:49, Johannes Berg wrote:
>
>> @@ -599,7 +599,9 @@ static int __ieee80211_start_scan(struct
>> ieee80211_sub_if_data *sdata,
>>
>> if ((req->channels[0]->flags &
>> IEEE80211_CHAN_NO_IR) ||
>> - !req->n_ssids) {
>> + !req->n_ssids ||
>> + ((req->channels[0]->flags &
>> IEEE80211_CHAN_RADAR) &&
>> + (req->flags &
>> NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
>> next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
>>
>
> I don't really see any circumstances under which it's valid to actively
> scan radar channels ... seems like we should do this unconditionally?
I think it would be reasonable only if the target channel is the one we
are using and we have done CSA. But when scanning non-operative channels
I don't think this could work.
As discussed on IRC I'd rather go for passively scanning any DFS channel.
Cheers,
--
Antonio Quartulli
> @@ -599,7 +599,9 @@ static int __ieee80211_start_scan(struct
> ieee80211_sub_if_data *sdata,
>
> if ((req->channels[0]->flags &
> IEEE80211_CHAN_NO_IR) ||
> - !req->n_ssids) {
> + !req->n_ssids ||
> + ((req->channels[0]->flags &
> IEEE80211_CHAN_RADAR) &&
> + (req->flags &
> NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
> next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
>
I don't really see any circumstances under which it's valid to actively
scan radar channels ... seems like we should do this unconditionally?
johannes
On Monday, October 24, 2016 4:38:36 PM CEST Johannes Berg wrote:
> On Mon, 2016-10-24 at 16:36 +0200, Simon Wunderlich wrote:
> > On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote:
> > > On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> > > > Otherwise, it would be pretty much impossible to perform CSAs to
> > > > another DFS channel.
> > >
> > > I was told that to do that you'd need another NIC that's pre-
> > > CAC'ing another channel.
> >
> > Here is the portion from ETSI 301 893 v1.8.1 [1] (the most recent one
> > to my knowledege), section 4.7.1.4 which describes operation from
> >
> > master devices (Access Points):
> > [...]
>
> Yeah I'm pretty sure there are differences in ETSI vs. FCC. Perhaps the
> information I was told about was for FCC. But perhaps it's all just
> completely wrong :)
I think I've found the right specification [1] for FCC. They doesn't state so
explicitly that it is allowed, but I don't see any remark that this behaviour
is forbidden, either. The important section is 5.1.1 Master devices in 905462
D02 UNII DFS Compliance Procedures New Rules v02, which is pretty similar to
ETSI. They say:
<snip>
a)
The Master Device will use DFS in order to detect Radar Waveforms with
received signal strength above the DFS Detection Threshold in the 5250 - 5350
MHz and 5470 - 5725 MHz bands. DFS is not required in the 5150 - 5250 MHz or
5725 - 5825 MHz bands.
b)
Before initiating a network on a Channel, the Master Device will perform a
Channel Availability Check for a specified time duration (Channel Availability
Check Time) to ensure that there is no radar system operating on the
Channel, using DFS described under subsection a) above.
c) The Master Device initiates a U-NII network by transmitting control
signals that will enable other U-NII devices to Associate with the Master
Device.
d)
During normal operation, the Master Device will monitor the Channel
(In-Service Monitoring) to ensure that there is no radar system operating on
the Channel, using DFS described under a).
e)
If the Master Device has detected a Radar Waveform during In-Service
Monitoring as described under d), the Operating Channel of the U-
NII network is no longer an Available Channel. The Master Device will
instruct all associated Client Device(s) to stop transmitting on this
Channel within the Channel Move Time. The transmissions during the
Channel Move Time will be limited to the Channel Closing Transmission
Time.
</snap>
Again, no explicit "on installation" here, but there is also nothing saying
that we can not check/operate on other channels in the meantime. (NOTE: going
off-channel while operating is a different topic).
Cheers,
Simon
[1] https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?
switch=P&id=27155
On Mon, 2016-10-24 at 16:36 +0200, Simon Wunderlich wrote:
> On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote:
> >
> > On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> > >
> > > Otherwise, it would be pretty much impossible to perform CSAs to
> > > another DFS channel.
> >
> > I was told that to do that you'd need another NIC that's pre-
> > CAC'ing another channel.
>
> Here is the portion from ETSI 301 893 v1.8.1 [1] (the most recent one
> to my knowledege), section 4.7.1.4 which describes operation from
> master devices (Access Points):
> [...]
Yeah I'm pretty sure there are differences in ETSI vs. FCC. Perhaps the
information I was told about was for FCC. But perhaps it's all just
completely wrong :)
johannes
On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote:
> > > I think it would be reasonable only if the target channel is the
> > > one we are using and we have done CSA. But when scanning non-
> > > operative channels I don't think this could work.
> >
> > this has been sleeping for a while.. :)
> > Would it make sense to rebase it and resubmit it for inclusion?
> >
> > Given the previous discussion we could change the logic as:
> > * always passively scan DFS channels that are not usable
> > * always actively scan DFS channels that are usable (i.e. CAC was
> > performed).
>
> Doesn't that contradict what you said above?
>
> If we scan, don't we possibly lose our CAC result anyway, since we went
> off-channel? In FCC at least? In ETSI I think we're allowed to do that
> for a bit?
I believe going off-channel was allowed in general - in fact, some routers CAC
all channels on boot up and then keep the "usable" state forever.
Otherwise, it would be pretty much impossible to perform CSAs to another DFS
channel.
Cheers,
Simon
> > I think it would be reasonable only if the target channel is the
> > one we are using and we have done CSA. But when scanning non-
> > operative channels I don't think this could work.
> this has been sleeping for a while.. :)
> Would it make sense to rebase it and resubmit it for inclusion?
>
> Given the previous discussion we could change the logic as:
> * always passively scan DFS channels that are not usable
> * always actively scan DFS channels that are usable (i.e. CAC was
> performed).
Doesn't that contradict what you said above?
If we scan, don't we possibly lose our CAC result anyway, since we went
off-channel? In FCC at least? In ETSI I think we're allowed to do that
for a bit?
Anyway, why not just always scan passively, to simplify?
johannes
On Fri, Nov 20, 2015 at 08:52:32PM +0800, Antonio Quartulli wrote:
> On 20/11/15 18:49, Johannes Berg wrote:
> >
> >> @@ -599,7 +599,9 @@ static int __ieee80211_start_scan(struct
> >> ieee80211_sub_if_data *sdata,
> >>
> >> if ((req->channels[0]->flags &
> >> IEEE80211_CHAN_NO_IR) ||
> >> - !req->n_ssids) {
> >> + !req->n_ssids ||
> >> + ((req->channels[0]->flags &
> >> IEEE80211_CHAN_RADAR) &&
> >> + (req->flags &
> >> NL80211_SCAN_FLAG_PASSIVE_RADAR))) {
> >> next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
> >>
> >
> > I don't really see any circumstances under which it's valid to actively
> > scan radar channels ... seems like we should do this unconditionally?
>
> I think it would be reasonable only if the target channel is the one we
> are using and we have done CSA. But when scanning non-operative channels
> I don't think this could work.
>
> As discussed on IRC I'd rather go for passively scanning any DFS channel.
>
> Cheers,
Hey Johannes,
this has been sleeping for a while.. :)
Would it make sense to rebase it and resubmit it for inclusion?
Given the previous discussion we could change the logic as:
* always passively scan DFS channels that are not usable
* always actively scan DFS channels that are usable (i.e. CAC was performed).
How does it sound? this would totally avoid the use of the switch in the scan
command.
Cheers,
--
Antonio Quartulli
On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> Otherwise, it would be pretty much impossible to perform CSAs to
> another DFS channel.
I was told that to do that you'd need another NIC that's pre-CAC'ing
another channel.
johannes
On Mon, Oct 24, 2016 at 03:33:24PM +0200, Johannes Berg wrote:
>
> > > I think it would be reasonable only if the target channel is the
> > > one we are using and we have done CSA. But when scanning non-
> > > operative channels I don't think this could work.
>
> > this has been sleeping for a while.. :)
> > Would it make sense to rebase it and resubmit it for inclusion?
> >
> > Given the previous discussion we could change the logic as:
> > * always passively scan DFS channels that are not usable
> > * always actively scan DFS channels that are usable (i.e. CAC was
> > performed).
>
> Doesn't that contradict what you said above?
>
> If we scan, don't we possibly lose our CAC result anyway, since we went
> off-channel? In FCC at least? In ETSI I think we're allowed to do that
> for a bit?
argh. ok, I think I had forgotten about this detail.
>
> Anyway, why not just always scan passively, to simplify?
>
Probably better..ok let's do it this way.
Thanks !
--
Antonio Quartulli
On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote:
> On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> > Otherwise, it would be pretty much impossible to perform CSAs to
> > another DFS channel.
>
> I was told that to do that you'd need another NIC that's pre-CAC'ing
> another channel.
Here is the portion from ETSI 301 893 v1.8.1 [1] (the most recent one to my
knowledege), section 4.7.1.4 which describes operation from master devices
(Access Points):
<snip>
b) A master device shall only start operations on Available Channels. At
installation (or reinstallation) of the equipment, the RLAN is assumed to have
no Available Channels within the band 5 250 MHz to 5 350 MHz and/or 5 470 MHz
to 5 725 MHz. In such a case, before starting operations on one or more of
these channels, the master device shall perform either a Channel Availability
Check or an Off-Channel CAC to ensure that there are no radars operating on
any selected channel. If no radar has been detected, the channel(s) becomes an
Available Channel(s) and remains as such until a radar signal is detected
during the In-Service Monitoring.
The Channel Availability Check or the Off-Channel CAC may be performed over a
wider bandwidth such that all channels within the tested bandwidth become
Available Channels.
NOTE 1:The initial Channel Availability Check may be activated manually at
installation or reinstallation of the equipment.
c) Once the RLAN has started operations on an Available Channel, then that
channel becomes an Operating Channel. During normal operation, the master
device shall monitor all Operating Channels (In-Service Monitoring) to ensure
that there is no radar operating within these channel(s). If no radar was
detected on an Operating Channel but the RLAN stops operating on that channel,
then the channel becomes an Available Channel.
NOTE 2:An RLAN is allowed to start transmissions on multiple (adjacent or non-
adjacent) Available Channels. In this case all these channels become Operating
Channels.
<snap>
As I interpret this, (b) states explicitly that we can have many available
channels. We only need to mark channels where we detect a radar.
BTW, there was also something like a 24h disconnect previously, which was
removed in 2009 [2].
Cheers,
Simon
[1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.08.01_60/
en_301893v010801p.pdf
[2] http://www.wlan-skynet.de/docs/rechtliches/etsi_301_893.shtml (german
only)
>
> johannes
On 24 October 2016 at 15:42, Simon Wunderlich <[email protected]> wrote=
:
> On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote:
>> > > I think it would be reasonable only if the target channel is the
>> > > one we are using and we have done CSA. But when scanning non-
>> > > operative channels I don't think this could work.
>> >
>> > this has been sleeping for a while.. :)
>> > Would it make sense to rebase it and resubmit it for inclusion?
>> >
>> > Given the previous discussion we could change the logic as:
>> > * always passively scan DFS channels that are not usable
>> > * always actively scan DFS channels that are usable (i.e. CAC was
>> > performed).
>>
>> Doesn't that contradict what you said above?
>>
>> If we scan, don't we possibly lose our CAC result anyway, since we went
>> off-channel? In FCC at least? In ETSI I think we're allowed to do that
>> for a bit?
>
> I believe going off-channel was allowed in general - in fact, some router=
s CAC
> all channels on boot up and then keep the "usable" state forever.
I recall a discussion around this behavior [scan all on boot] a long
time ago. I believe earlier ETSI spec revisions allowed it but recent
ones made it more explicit that you can't cache CAC results like that
but don't take my word for it. I don't have have the spec on me now so
can't check.
Micha=C5=82
On Wednesday, October 26, 2016 2:58:56 PM CEST Johannes Berg wrote:
> > (NOTE: going off-channel while operating is a different topic).
>
> Why do you think it's different?
>
> Seems exactly the same to me, since you come back to the channel and
> start sending without any new checking?
There are two ways to leave a channel:
1.) Leave the operating channel "permanently". Then the ETSI 301 893 says:
"If no radar was detected on an Operating Channel but the RLAN stops operating
on that channel, then the channel becomes an Available Channel." (4.7.1.4
Master Devices (c))
Then we can select a new operating channel and re-start the process.
2.) Off-Channel CAC: This is an optional feature. Simply spoken, we keep the
channel operating, but try to do CAC-checking on a different channel by
shortly switching to that new channel from time to time. The new channel must
be checked for a longer time than the standard CAC time (6 minutes for non-
weather radar channels in ETSI).
The main difference is that we keep the current channel as "operating channel"
and are also required to be able to detect radars with the same probability.
Also note that this feature is not implemented in Linux as far as I know, and
personally I haven't seen it in the wild yet.
From 4.7.2.3.1:
"Off-Channel CAC is defined as an optional mechanism by which an RLAN device
monitors channel(s), different from the Operating Channel(s), for the presence
of radar signals. The Off-Channel CAC may be used in addition to the Channel
Availability Check defined in clause 4.7.2.2, for identifying Available
Channels.
Off-Channel CAC is performed by a number of non-continuous checks spread over
a period in time. This period, which is required to determine the presence of
radar signals, is defined as the Off-Channel CAC Time.
If no radars have been detected in a channel, then that channel becomes an
Available Channel."
Cheers,
Simon
On Mon, 2016-10-24 at 16:53 +0200, Simon Wunderlich wrote:
> [snip]
>
> Again, no explicit "on installation" here, but there is also nothing
> saying that we can not check/operate on other channels in the
> meantime.
Yeah, ok.
> (NOTE: going off-channel while operating is a different topic).
Why do you think it's different?
Seems exactly the same to me, since you come back to the channel and
start sending without any new checking?
johannes