nl80211: add flag to force passive scan on DFS channels

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.

---

v2: no change

 include/uapi/linux/nl80211.h | 2 ++
 1 file changed, 2 insertions(+)

index 1f0b4cf..2083e53 100644
@@ -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.

---

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

index 4aeca4b..e369d61 100644
@@ -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

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

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

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

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

argh. ok, I think I had forgotten about this detail.

Probably better..ok let's do it this way.

Thanks !

Antonio Quartulli

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

On 24 October 2016 at 15:42, Simon Wunderlich <[email protected]> wrote= :

s CAC

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

I was told that to do that you'd need another NIC that's pre-CAC'ing another channel.

johannes

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)

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

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

Yeah, ok.

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

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