crda: enforce ETSI CAC timer of 600s on the weather band

A really weird patch that splits the U-NII-2e band into 1, 2 or 3 sub-bands to enforce a CAC time of 10 minutes in the range 5600-5650 MHz.

---

I came with the following patch to enforce ETSI regulation in Europe for weather channels.
It applies to crda and when it encounters this frequency range, it splits it out and enforces the 10 minutes CAC.
I know it's weird as is, I just wonder if it's the good way of solving this until CAC is in regulatory.bin or the kernel takes care of it.

 crda.c |  104
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 94 insertions(+), 10 deletions(-)

crda.c +17 -0

index f40131f..4c4aeba 100644
@@ -140,6 +140,36 @@ nla_put_failure:
 	return -1;
 }
 
+static int put_dom_reg_rule(struct ieee80211_reg_rule *rule, struct nl_msg
 *msg, int i)
+{
+	int r;
+	struct nlattr *nl_reg_rule;
+	unsigned long width;
+
+	width = rule->freq_range.end_freq_khz -
 rule->freq_range.start_freq_khz;
+	if (width <= 0)
+		return 0; // nothing to do -- assert success
+
+	nl_reg_rule = nla_nest_start(msg, i);
+	if (!nl_reg_rule)
+		return 1;
+
+	if (width < rule->freq_range.max_bandwidth_khz) {
+		if (width >= 160000) rule->freq_range.max_bandwidth_khz =
 160000;
+		else if (width >= 80000) rule->freq_range.max_bandwidth_khz

= 80000;

crda.c +1 -0

+		else if (width >= 40000) rule->freq_range.max_bandwidth_khz

= 40000;

crda.c +1 -0

+		else if (width >= 20000) rule->freq_range.max_bandwidth_khz

= 20000;

crda.c +1 -0

+		else if (width >= 10000) rule->freq_range.max_bandwidth_khz

= 10000;

crda.c +14 -10

+		else rule->freq_range.max_bandwidth_khz = 5000;
+	}
+	r = put_reg_rule(rule, msg);
+	if (r)
+		return 1;
+
+	nla_nest_end(msg, nl_reg_rule);
+	return 0;
+}
+
 int main(int argc, char **argv)
 {
 	int fd = -1;

@@ -228,16 +258,70 @@ int main(int argc, char **argv)
 	}
 
 	for (j = 0; j < rd->n_reg_rules; j++) {
-		struct nlattr *nl_reg_rule;
-		nl_reg_rule = nla_nest_start(msg, i);
-		if (!nl_reg_rule)
-			goto nla_put_failure;
-
-		r = put_reg_rule(&rd->reg_rules[j], msg);
-		if (r)
-			goto nla_put_failure;
-
-		nla_nest_end(msg, nl_reg_rule);
+		const struct ieee80211_reg_rule *rule = &rd->reg_rules[j];
+
+#define METEO_BAND_START	(5600 * 1000)
+#define METEO_BAND_BEFORE_START	(5570 * 1000)	// to allow BW=40

and 80

crda.c +7 -0

+#define METEO_BAND_END		(5650 * 1000)
+		if (rd->dfs_region == REGDB_DFS_ETSI
+		  && rule->freq_range.start_freq_khz < METEO_BAND_END
+		  && rule->freq_range.end_freq_khz > METEO_BAND_START) {
+			struct ieee80211_reg_rule split_rule;
+			/*
+			 * ETSI rule including all or part of the weather

band

crda.c +3 -0

+			 *
+			 * If necessary the frequency range is split in 3
+			 * to allow inserting the 10 minutes CAC in the 2nd

one

crda.c +3 -0

+			 */
+			/* If the range overlaps the 5600 MHz frequency */
+			if (rule->freq_range.start_freq_khz <

METEO_BAND_BEFORE_START) {

crda.c +5 -0

+
+				/* copy band data (CAC, BW...) */
+				split_rule = *rule;
+				/* remove upper channels */
+				split_rule.freq_range.end_freq_khz =

METEO_BAND_BEFORE_START;

crda.c +10 -0

+
+				/* configure lower channels */
+				if (put_dom_reg_rule(&split_rule, msg, i))
+					goto nla_put_failure;
+			}
+
+			/* The rest necessarily begins before 5650 MHz */
+			/* copy band data (CAC, BW...) */
+			split_rule = *rule;
+			if (rule->freq_range.start_freq_khz <

METEO_BAND_BEFORE_START) {

crda.c +1 -0

+				split_rule.freq_range.start_freq_khz =

METEO_BAND_BEFORE_START;

crda.c +5 -0

+			}
+
+			/* compute center range */
+			if (rule->freq_range.end_freq_khz <= METEO_BAND_END)
+				split_rule.freq_range.end_freq_khz =

rule->freq_range.end_freq_khz;

crda.c +2 -0

+			else
+				split_rule.freq_range.end_freq_khz =

METEO_BAND_END;

crda.c +1 -0

+			split_rule.dfs_cac_ms = 10 * 60 * 1000; /* 10

minutes */

crda.c +7 -0

+
+			/* configure weather frequencies */
+			if (put_dom_reg_rule(&split_rule, msg, i))
+				goto nla_put_failure;
+
+			/* If the range overlaps the 5650 MHz frequency */
+			if (rule->freq_range.end_freq_khz > METEO_BAND_END)

{

crda.c +3 -0

+
+				/* copy band data (CAC, BW...) */
+				split_rule = *rule; /* copie les donnees de

la bande */

crda.c +2 -0

+				/* remove lower channels */
+				split_rule.freq_range.start_freq_khz =

METEO_BAND_END;

crda.c +8 -0

+
+				/* configure higher channels */
+				if (put_dom_reg_rule(&split_rule, msg, i))
+					goto nla_put_failure;
+			}
+		} else {
+			/* configure the whole range */
+			/* WARNING: this fonction may change

(const)rule->...max_bandwidth_khz */

crda.c +1 -0

+			if (put_dom_reg_rule((struct ieee80211_reg_rule

*)rule, msg, i))

crda.c +2 -0

+				goto nla_put_failure;
+		}
 	}
 
 	nla_nest_end(msg, nl_reg_rules);

Signature · 1 line

1.7.2.5

Quoted 2 lines · Jean-Pierre Tosoni

A really weird patch that splits the U-NII-2e band into 1, 2 or 3 sub-bands to enforce a CAC time of 10 minutes in the range 5600-5650 MHz.

Wrong maintainer / list. CRDA patches should be directed to Luis and the linux-wireless list (feel free to Cc wireless-regdb if you like).

Quoted 6 lines · Seth Forshee

Quoted 2 lines · Jean-Pierre Tosoni

A really weird patch that splits the U-NII-2e band into 1, 2 or 3 sub-bands to enforce a CAC time of 10 minutes in the range 5600-5650 MHz.

Wrong maintainer / list. CRDA patches should be directed to Luis and the linux-wireless list (feel free to Cc wireless-regdb if you like).

However, I'm not convinced that this actually *belongs* into the crda code? That seems like the wrong approach - shouldn't these rules be captured in the database? We do have AUTO-BW now so it should be possible, no?

And if the timings aren't captured in the db.txt file they really should be.

Quoted 13 lines · Johannes Berg

Quoted 6 lines · Seth Forshee

Quoted 2 lines · Jean-Pierre Tosoni

A really weird patch that splits the U-NII-2e band into 1, 2 or 3 sub-bands to enforce a CAC time of 10 minutes in the range 5600-5650 MHz.

Wrong maintainer / list. CRDA patches should be directed to Luis and the linux-wireless list (feel free to Cc wireless-regdb if you like).

However, I'm not convinced that this actually *belongs* into the crda code? That seems like the wrong approach - shouldn't these rules be captured in the database? We do have AUTO-BW now so it should be possible, no?

Quoted 2 lines

And if the timings aren't captured in the db.txt file they really should be.

Yeah with AUTO-BW the bands could be broken up in db.txt, and we could even put in the CAC times. But we still can't get the CAC times into the current regulatory.bin format, so it doesn't really accomplish anything.

Quoted 17 lines · Seth Forshee

Quoted 15 lines · Johannes Berg

Quoted 6 lines · Seth Forshee

Quoted 2 lines · Jean-Pierre Tosoni

A really weird patch that splits the U-NII-2e band into 1, 2 or 3 sub-bands to enforce a CAC time of 10 minutes in the range 5600-5650 MHz.

Wrong maintainer / list. CRDA patches should be directed to Luis and the linux-wireless list (feel free to Cc wireless-regdb if you like).

However, I'm not convinced that this actually *belongs* into the crda code? That seems like the wrong approach - shouldn't these rules be captured in the database? We do have AUTO-BW now so it should be possible, no?

And if the timings aren't captured in the db.txt file they really should be.

Quoted 3 lines

Yeah with AUTO-BW the bands could be broken up in db.txt, and we could even put in the CAC times. But we still can't get the CAC times into the current regulatory.bin format, so it doesn't really accomplish anything.

But then there's also little point in putting any code for it into the crda binary, no?

Quoted 6 lines

Quoted 3 lines

Yeah with AUTO-BW the bands could be broken up in db.txt, and we could even put in the CAC times. But we still can't get the CAC times into the current regulatory.bin format, so it doesn't really accomplish anything.

But then there's also little point in putting any code for it into the crda binary, no?

Just to be clear, I'm not arguing for or against the patch at all. I'm only trying to explain why Jean-Pierre is proposing to change CRDA rather than db.txt. Maybe I should just let him speak for himself ...

As I understand it Jean-Pierre is looking for a stop-gap to get CAC times into the kernel until such time as we have a file format which allows getting them from regulatory.bin. Chaning CRDA can accomplish this, whereas modifying db.txt cannot.