[PATCH v2 1/2] nl80211: add flag to force passive scan on DFS channels

[PATCH v2 1/2] nl80211: add flag to force passive scan on DFS channels

[Antonio Quartulli]

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 <antonio@open-mesh.com>
---

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

[PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Antonio Quartulli]

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 <antonio@open-mesh.com>
---

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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Johannes Berg]

> @@ -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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Johannes Berg]

> > 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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Michal Kazior]

On 24 October 2016 at 15:42, Simon Wunderlich <sw@simonwunderlich.de> 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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Johannes Berg]

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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Johannes Berg]

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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Johannes Berg]

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

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]