All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-09  8:40 ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-09  8:40 UTC (permalink / raw)
  To: wireless-regdb; +Cc: linux-wireless, mcgrof, Janusz Dziedzic

Introduce support for setting DFS CAC time
in milliseconds.

Eg.
(5250 - 5330 @ AUTO), (20), (60000), DFS

will setup CAC 60 seconds CAC time.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
 db2bin.py  |    6 +++---
 dbparse.py |   17 +++++++++++++----
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/db2bin.py b/db2bin.py
index 41d3741..f6c3bc1 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -7,7 +7,7 @@ from dbparse import DBParser
 import sys
 
 MAGIC = 0x52474442
-VERSION = 19
+VERSION = 20
 
 if len(sys.argv) < 3:
     print 'Usage: %s output-file input-file [key-file]' % sys.argv[0]
@@ -93,8 +93,8 @@ for reg_rule in rules:
     freq_range, power_rule = reg_rule.freqband, reg_rule.power
     reg_rules[reg_rule] = output.tell()
     # struct regdb_file_reg_rule
-    output.write(struct.pack('>III', freq_ranges[freq_range], power_rules[power_rule],
-                             reg_rule.flags))
+    output.write(struct.pack('>IIII', freq_ranges[freq_range], power_rules[power_rule],
+                             reg_rule.flags, reg_rule.cac_time))
 
 
 reg_rules_collections = {}
diff --git a/dbparse.py b/dbparse.py
index b735b6a..d54311f 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -77,12 +77,13 @@ class FlagError(Exception):
         self.flag = flag
 
 class Permission(object):
-    def __init__(self, freqband, power, flags):
+    def __init__(self, freqband, power, flags, cac_time):
         assert isinstance(freqband, FreqBand)
         assert isinstance(power, PowerRestriction)
         self.freqband = freqband
         self.power = power
         self.flags = 0
+        self.cac_time = cac_time
         for flag in flags:
             if not flag in flag_definitions:
                 raise FlagError(flag)
@@ -90,7 +91,7 @@ class Permission(object):
         self.textflags = flags
 
     def _as_tuple(self):
-        return (self.freqband, self.power, self.flags)
+        return (self.freqband, self.power, self.flags, self.cac_time)
 
     def __cmp__(self, other):
         if not isinstance(other, Permission):
@@ -254,6 +255,7 @@ class DBParser(object):
         self._comments = []
 
     def _parse_country_item(self, line):
+        cac_time = 0
         if line[0] == '(':
             try:
                 band, line = line[1:].split('),', 1)
@@ -282,7 +284,14 @@ class DBParser(object):
                 flags = []
             else:
                 pname = items[0]
-                flags = items[1].split(',')
+                pcac = items[1]
+                if pcac[0] == '(':
+                    cac, flags = pcac.split('),', 1)
+                    flags = flags.split(',')
+                    cac_time = int(cac[1:])
+                else:
+                    flags = items[1].split(',')
+
             power = pname[1:]
             pname = 'UNNAMED %d' % self._lineno
             self._parse_power_def(pname, power, dupwarn=False)
@@ -303,7 +312,7 @@ class DBParser(object):
         b = self._bands[bname]
         p = self._power[pname]
         try:
-            perm = Permission(b, p, flags)
+            perm = Permission(b, p, flags, cac_time)
         except FlagError, e:
             self._syntax_error("Invalid flag '%s'" % e.flag)
         for cname, c in self._current_countries.iteritems():
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-09  8:40 ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-09  8:40 UTC (permalink / raw)
  To: wireless-regdb; +Cc: Janusz Dziedzic, linux-wireless, mcgrof

Introduce support for setting DFS CAC time
in milliseconds.

Eg.
(5250 - 5330 @ AUTO), (20), (60000), DFS

will setup CAC 60 seconds CAC time.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
 db2bin.py  |    6 +++---
 dbparse.py |   17 +++++++++++++----
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/db2bin.py b/db2bin.py
index 41d3741..f6c3bc1 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -7,7 +7,7 @@ from dbparse import DBParser
 import sys
 
 MAGIC = 0x52474442
-VERSION = 19
+VERSION = 20
 
 if len(sys.argv) < 3:
     print 'Usage: %s output-file input-file [key-file]' % sys.argv[0]
@@ -93,8 +93,8 @@ for reg_rule in rules:
     freq_range, power_rule = reg_rule.freqband, reg_rule.power
     reg_rules[reg_rule] = output.tell()
     # struct regdb_file_reg_rule
-    output.write(struct.pack('>III', freq_ranges[freq_range], power_rules[power_rule],
-                             reg_rule.flags))
+    output.write(struct.pack('>IIII', freq_ranges[freq_range], power_rules[power_rule],
+                             reg_rule.flags, reg_rule.cac_time))
 
 
 reg_rules_collections = {}
diff --git a/dbparse.py b/dbparse.py
index b735b6a..d54311f 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -77,12 +77,13 @@ class FlagError(Exception):
         self.flag = flag
 
 class Permission(object):
-    def __init__(self, freqband, power, flags):
+    def __init__(self, freqband, power, flags, cac_time):
         assert isinstance(freqband, FreqBand)
         assert isinstance(power, PowerRestriction)
         self.freqband = freqband
         self.power = power
         self.flags = 0
+        self.cac_time = cac_time
         for flag in flags:
             if not flag in flag_definitions:
                 raise FlagError(flag)
@@ -90,7 +91,7 @@ class Permission(object):
         self.textflags = flags
 
     def _as_tuple(self):
-        return (self.freqband, self.power, self.flags)
+        return (self.freqband, self.power, self.flags, self.cac_time)
 
     def __cmp__(self, other):
         if not isinstance(other, Permission):
@@ -254,6 +255,7 @@ class DBParser(object):
         self._comments = []
 
     def _parse_country_item(self, line):
+        cac_time = 0
         if line[0] == '(':
             try:
                 band, line = line[1:].split('),', 1)
@@ -282,7 +284,14 @@ class DBParser(object):
                 flags = []
             else:
                 pname = items[0]
-                flags = items[1].split(',')
+                pcac = items[1]
+                if pcac[0] == '(':
+                    cac, flags = pcac.split('),', 1)
+                    flags = flags.split(',')
+                    cac_time = int(cac[1:])
+                else:
+                    flags = items[1].split(',')
+
             power = pname[1:]
             pname = 'UNNAMED %d' % self._lineno
             self._parse_power_def(pname, power, dupwarn=False)
@@ -303,7 +312,7 @@ class DBParser(object):
         b = self._bands[bname]
         p = self._power[pname]
         try:
-            perm = Permission(b, p, flags)
+            perm = Permission(b, p, flags, cac_time)
         except FlagError, e:
             self._syntax_error("Invalid flag '%s'" % e.flag)
         for cname, c in self._current_countries.iteritems():
-- 
1.7.9.5


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [PATCH] crda: add DFS CAC time support
  2014-05-09  8:40 ` [wireless-regdb] " Janusz Dziedzic
@ 2014-05-09  8:40   ` Janusz Dziedzic
  -1 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-09  8:40 UTC (permalink / raw)
  To: wireless-regdb; +Cc: linux-wireless, mcgrof, Janusz Dziedzic

Add DFS CAC time support. Get this
value form regulatory.bin file.
Add parsers required by db2rd.

Change REGDB_VERSION while binary file
format was changed little bit (rule structure).

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
 crda.c   |    3 ++
 regdb.h  |    5 ++-
 reglib.c |  149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 reglib.h |    1 +
 4 files changed, 150 insertions(+), 8 deletions(-)

diff --git a/crda.c b/crda.c
index 4751a39..0bf83a1 100644
--- a/crda.c
+++ b/crda.c
@@ -131,6 +131,9 @@ static int put_reg_rule(const struct ieee80211_reg_rule *rule, struct nl_msg *ms
 	NLA_PUT_U32(msg, NL80211_ATTR_POWER_RULE_MAX_ANT_GAIN,	power_rule->max_antenna_gain);
 	NLA_PUT_U32(msg, NL80211_ATTR_POWER_RULE_MAX_EIRP,	power_rule->max_eirp);
 
+	if (rule->dfs_cac_ms)
+		NLA_PUT_U32(msg, NL80211_ATTR_DFS_CAC_TIME,	rule->dfs_cac_ms);
+
 	return 0;
 
 nla_put_failure:
diff --git a/regdb.h b/regdb.h
index 3ffb781..e7b7ab6 100644
--- a/regdb.h
+++ b/regdb.h
@@ -21,7 +21,7 @@
  * to have some more magic. We still consider this to be
  * "Version 1" of the file.
  */
-#define REGDB_VERSION	19
+#define REGDB_VERSION	20
 
 /*
  * The signature at the end of the file is an RSA-signed
@@ -107,6 +107,7 @@ struct regdb_file_reg_rule {
 	uint32_t	power_rule_ptr; /* pointer to a struct regdb_file_power_rule */
 	/* rule flags using enum reg_rule_flags */
 	uint32_t flags;
+	uint32_t dfs_cac_ms;
 };
 
 struct regdb_file_reg_rules_collection {
@@ -143,7 +144,7 @@ static inline void check_db_binary_structs(void)
 	CHECK_STRUCT(regdb_file_header, 20);
 	CHECK_STRUCT(regdb_file_freq_range, 12);
 	CHECK_STRUCT(regdb_file_power_rule, 8);
-	CHECK_STRUCT(regdb_file_reg_rule, 12);
+	CHECK_STRUCT(regdb_file_reg_rule, 16);
 	CHECK_STRUCT(regdb_file_reg_rules_collection, 4);
 	CHECK_STRUCT(regdb_file_reg_country, 8);
 }
diff --git a/reglib.c b/reglib.c
index 3deca4a..beddecd 100644
--- a/reglib.c
+++ b/reglib.c
@@ -326,6 +326,7 @@ static void reg_rule2rd(uint8_t *db, size_t dblen,
 	rd_power_rule->max_eirp = ntohl(power->max_eirp);
 
 	rd_reg_rule->flags = ntohl(rule->flags);
+	rd_reg_rule->dfs_cac_ms = ntohl(rule->dfs_cac_ms);
 
 	if (rd_reg_rule->flags & RRF_NO_IR_ALL)
 		rd_reg_rule->flags |= RRF_NO_IR_ALL;
@@ -734,6 +735,9 @@ static void print_reg_rule(const struct ieee80211_reg_rule *rule)
 	else
 		printf("N/A)");
 
+	if ((rule->flags & RRF_DFS) && rule->dfs_cac_ms)
+		printf(", (%u)", rule->dfs_cac_ms);
+
 	if (rule->flags & RRF_NO_OFDM)
 		printf(", NO-OFDM");
 	if (rule->flags & RRF_NO_CCK)
@@ -826,6 +830,7 @@ reglib_parse_rule_simple(char *line, struct ieee80211_reg_rule *reg_rule)
 		REGLIB_DBM_TO_MBM(max_eirp);
 
 	reg_rule->flags = 0;
+	reg_rule->dfs_cac_ms = 0;
 
 	if (debug)
 		printf("reglib_parse_rule_simple(): %d line: %s", hits, line);
@@ -861,6 +866,7 @@ reglib_parse_rule_simple_mw(char *line, struct ieee80211_reg_rule *reg_rule)
 		REGLIB_MW_TO_MBM(max_eirp);
 
 	reg_rule->flags = 0;
+	reg_rule->dfs_cac_ms = 0;
 
 	if (debug)
 		printf("reglib_parse_rule_simple_mw(): %d line: %s",
@@ -920,6 +926,8 @@ reglib_parse_rule_args(char *line, struct ieee80211_reg_rule *reg_rule)
 	for (i = 0; i < 8; i++)
 		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
 
+	reg_rule->dfs_cac_ms = 0;
+
 	if (debug)
 		printf("reglib_parse_rule_args(): %d flags: %d, line: %s",
 		       hits, reg_rule->flags, line);
@@ -982,6 +990,8 @@ reglib_parse_rule_args_mw(char *line, struct ieee80211_reg_rule *reg_rule)
 	for (i = 0; i < 8; i++)
 		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
 
+	reg_rule->dfs_cac_ms = 0;
+
 	if (debug)
 		printf("reglib_parse_rule_args_mw(): %d flags: %d, line: %s",
 		       hits, reg_rule->flags, line);
@@ -989,6 +999,130 @@ reglib_parse_rule_args_mw(char *line, struct ieee80211_reg_rule *reg_rule)
 #undef IGNORE_COMMA_OR_SPACE
 }
 
+static int
+reglib_parse_rule_args_mw_cac(char *line, struct ieee80211_reg_rule *reg_rule)
+{
+#define IGNORE_COMMA_OR_SPACE "%*[ ,]"
+	int hits;
+	char flag_list[9][100];
+	unsigned int i = 0, dfs_cac_ms;
+	char mw[3];
+	float start_freq_khz, end_freq_khz, max_bandwidth_khz, max_eirp;
+
+	for (i = 0; i < 9; i++)
+		memset(flag_list[i], 0, sizeof(flag_list[i]));
+
+	hits = sscanf(line, "\t(%f - %f @ %f), (%f %2[mW]), (%u),"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s",
+		      &start_freq_khz,
+		      &end_freq_khz,
+		      &max_bandwidth_khz,
+		      &max_eirp,
+		      mw,
+		      &dfs_cac_ms,
+		      flag_list[0],
+		      flag_list[1],
+		      flag_list[2],
+		      flag_list[3],
+		      flag_list[4],
+		      flag_list[5],
+		      flag_list[6],
+		      flag_list[7],
+		      flag_list[8]);
+
+	if (hits < 6)
+		return -EINVAL;
+
+	reg_rule->freq_range.start_freq_khz =
+		REGLIB_MHZ_TO_KHZ(start_freq_khz);
+	reg_rule->freq_range.end_freq_khz =
+		REGLIB_MHZ_TO_KHZ(end_freq_khz);
+	reg_rule->freq_range.max_bandwidth_khz =
+		REGLIB_MHZ_TO_KHZ(max_bandwidth_khz);
+	reg_rule->power_rule.max_eirp =
+		REGLIB_MW_TO_MBM(max_eirp);
+
+	for (i = 0; i < 8; i++)
+		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
+
+	reg_rule->dfs_cac_ms = dfs_cac_ms;
+
+	if (debug)
+		printf("reglib_parse_rule_args_mw_cac(): %d flags: %d, line: %s",
+		       hits, reg_rule->flags, line);
+	return 0;
+#undef IGNORE_COMMA_OR_SPACE
+}
+
+static int
+reglib_parse_rule_args_cac(char *line, struct ieee80211_reg_rule *reg_rule)
+{
+#define IGNORE_COMMA_OR_SPACE "%*[ ,]"
+	int hits;
+	char flag_list[9][100];
+	unsigned int i = 0, dfs_cac_ms;
+	float start_freq_khz, end_freq_khz, max_bandwidth_khz, max_eirp;
+
+	for (i = 0; i < 9; i++)
+		memset(flag_list[i], 0, sizeof(flag_list[i]));
+
+	hits = sscanf(line, "\t(%f - %f @ %f), (%f), (%u)"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s",
+		      &start_freq_khz,
+		      &end_freq_khz,
+		      &max_bandwidth_khz,
+		      &max_eirp,
+		      &dfs_cac_ms,
+		      flag_list[0],
+		      flag_list[1],
+		      flag_list[2],
+		      flag_list[3],
+		      flag_list[4],
+		      flag_list[5],
+		      flag_list[6],
+		      flag_list[7],
+		      flag_list[8]);
+
+	if (hits < 6)
+		return -EINVAL;
+
+	reg_rule->freq_range.start_freq_khz =
+		REGLIB_MHZ_TO_KHZ(start_freq_khz);
+	reg_rule->freq_range.end_freq_khz =
+		REGLIB_MHZ_TO_KHZ(end_freq_khz);
+	reg_rule->freq_range.max_bandwidth_khz =
+		REGLIB_MHZ_TO_KHZ(max_bandwidth_khz);
+	reg_rule->power_rule.max_eirp =
+		REGLIB_DBM_TO_MBM(max_eirp);
+
+	for (i = 0; i < 8; i++)
+		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
+
+	reg_rule->dfs_cac_ms = dfs_cac_ms;
+
+	if (debug)
+		printf("reglib_parse_rule_args_cac(): %d flags: %d, line: %s",
+		       hits, reg_rule->flags, line);
+
+	return 0;
+#undef IGNORE_COMMA_OR_SPACE
+}
 static int reglib_parse_rule(FILE *fp, struct ieee80211_reg_rule *reg_rule)
 {
 	char line[1024];
@@ -997,24 +1131,27 @@ static int reglib_parse_rule(FILE *fp, struct ieee80211_reg_rule *reg_rule)
 	int r = 0;
 	struct reglib_rule_parse_list *reglib_rule_parsers;
 	size_t size_parsers = sizeof(struct reglib_rule_parse_list) + 
-				4 * sizeof(int (*)(char *, struct ieee80211_reg_rule *));
+				6 * sizeof(int (*)(char *, struct ieee80211_reg_rule *));
 
 	reglib_rule_parsers = malloc(size_parsers);
 	if (!reglib_rule_parsers)
 		return -EINVAL;
 	memset(reglib_rule_parsers, 0, size_parsers);
 
-	reglib_rule_parsers->n_parsers = 4;
+	reglib_rule_parsers->n_parsers = 6;
+
 
 	/*
 	 * XXX: sscanf() is a bit odd with picking up mW
 	 * case over the simple one, this order however works,
 	 * gotta figure out how to be more precise.
 	 */
-	reglib_rule_parsers->rule_parsers[0] = reglib_parse_rule_args_mw;
-	reglib_rule_parsers->rule_parsers[1] = reglib_parse_rule_args;
-	reglib_rule_parsers->rule_parsers[2] = reglib_parse_rule_simple;
-	reglib_rule_parsers->rule_parsers[3] = reglib_parse_rule_simple_mw;
+	reglib_rule_parsers->rule_parsers[0] = reglib_parse_rule_args_mw_cac;
+	reglib_rule_parsers->rule_parsers[1] = reglib_parse_rule_args_cac;
+	reglib_rule_parsers->rule_parsers[2] = reglib_parse_rule_args_mw;
+	reglib_rule_parsers->rule_parsers[3] = reglib_parse_rule_args;
+	reglib_rule_parsers->rule_parsers[4] = reglib_parse_rule_simple;
+	reglib_rule_parsers->rule_parsers[5] = reglib_parse_rule_simple_mw;
 
 	memset(line, 0, sizeof(line));
 	line_p = fgets(line, sizeof(line), fp);
diff --git a/reglib.h b/reglib.h
index afd5ef6..77aa42a 100644
--- a/reglib.h
+++ b/reglib.h
@@ -28,6 +28,7 @@ struct ieee80211_reg_rule {
 	struct ieee80211_freq_range freq_range;
 	struct ieee80211_power_rule power_rule;
 	uint32_t flags;
+	uint32_t dfs_cac_ms;
 };
 
 struct ieee80211_regdomain {
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* [wireless-regdb] [PATCH] crda: add DFS CAC time support
@ 2014-05-09  8:40   ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-09  8:40 UTC (permalink / raw)
  To: wireless-regdb; +Cc: Janusz Dziedzic, linux-wireless, mcgrof

Add DFS CAC time support. Get this
value form regulatory.bin file.
Add parsers required by db2rd.

Change REGDB_VERSION while binary file
format was changed little bit (rule structure).

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
 crda.c   |    3 ++
 regdb.h  |    5 ++-
 reglib.c |  149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 reglib.h |    1 +
 4 files changed, 150 insertions(+), 8 deletions(-)

diff --git a/crda.c b/crda.c
index 4751a39..0bf83a1 100644
--- a/crda.c
+++ b/crda.c
@@ -131,6 +131,9 @@ static int put_reg_rule(const struct ieee80211_reg_rule *rule, struct nl_msg *ms
 	NLA_PUT_U32(msg, NL80211_ATTR_POWER_RULE_MAX_ANT_GAIN,	power_rule->max_antenna_gain);
 	NLA_PUT_U32(msg, NL80211_ATTR_POWER_RULE_MAX_EIRP,	power_rule->max_eirp);
 
+	if (rule->dfs_cac_ms)
+		NLA_PUT_U32(msg, NL80211_ATTR_DFS_CAC_TIME,	rule->dfs_cac_ms);
+
 	return 0;
 
 nla_put_failure:
diff --git a/regdb.h b/regdb.h
index 3ffb781..e7b7ab6 100644
--- a/regdb.h
+++ b/regdb.h
@@ -21,7 +21,7 @@
  * to have some more magic. We still consider this to be
  * "Version 1" of the file.
  */
-#define REGDB_VERSION	19
+#define REGDB_VERSION	20
 
 /*
  * The signature at the end of the file is an RSA-signed
@@ -107,6 +107,7 @@ struct regdb_file_reg_rule {
 	uint32_t	power_rule_ptr; /* pointer to a struct regdb_file_power_rule */
 	/* rule flags using enum reg_rule_flags */
 	uint32_t flags;
+	uint32_t dfs_cac_ms;
 };
 
 struct regdb_file_reg_rules_collection {
@@ -143,7 +144,7 @@ static inline void check_db_binary_structs(void)
 	CHECK_STRUCT(regdb_file_header, 20);
 	CHECK_STRUCT(regdb_file_freq_range, 12);
 	CHECK_STRUCT(regdb_file_power_rule, 8);
-	CHECK_STRUCT(regdb_file_reg_rule, 12);
+	CHECK_STRUCT(regdb_file_reg_rule, 16);
 	CHECK_STRUCT(regdb_file_reg_rules_collection, 4);
 	CHECK_STRUCT(regdb_file_reg_country, 8);
 }
diff --git a/reglib.c b/reglib.c
index 3deca4a..beddecd 100644
--- a/reglib.c
+++ b/reglib.c
@@ -326,6 +326,7 @@ static void reg_rule2rd(uint8_t *db, size_t dblen,
 	rd_power_rule->max_eirp = ntohl(power->max_eirp);
 
 	rd_reg_rule->flags = ntohl(rule->flags);
+	rd_reg_rule->dfs_cac_ms = ntohl(rule->dfs_cac_ms);
 
 	if (rd_reg_rule->flags & RRF_NO_IR_ALL)
 		rd_reg_rule->flags |= RRF_NO_IR_ALL;
@@ -734,6 +735,9 @@ static void print_reg_rule(const struct ieee80211_reg_rule *rule)
 	else
 		printf("N/A)");
 
+	if ((rule->flags & RRF_DFS) && rule->dfs_cac_ms)
+		printf(", (%u)", rule->dfs_cac_ms);
+
 	if (rule->flags & RRF_NO_OFDM)
 		printf(", NO-OFDM");
 	if (rule->flags & RRF_NO_CCK)
@@ -826,6 +830,7 @@ reglib_parse_rule_simple(char *line, struct ieee80211_reg_rule *reg_rule)
 		REGLIB_DBM_TO_MBM(max_eirp);
 
 	reg_rule->flags = 0;
+	reg_rule->dfs_cac_ms = 0;
 
 	if (debug)
 		printf("reglib_parse_rule_simple(): %d line: %s", hits, line);
@@ -861,6 +866,7 @@ reglib_parse_rule_simple_mw(char *line, struct ieee80211_reg_rule *reg_rule)
 		REGLIB_MW_TO_MBM(max_eirp);
 
 	reg_rule->flags = 0;
+	reg_rule->dfs_cac_ms = 0;
 
 	if (debug)
 		printf("reglib_parse_rule_simple_mw(): %d line: %s",
@@ -920,6 +926,8 @@ reglib_parse_rule_args(char *line, struct ieee80211_reg_rule *reg_rule)
 	for (i = 0; i < 8; i++)
 		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
 
+	reg_rule->dfs_cac_ms = 0;
+
 	if (debug)
 		printf("reglib_parse_rule_args(): %d flags: %d, line: %s",
 		       hits, reg_rule->flags, line);
@@ -982,6 +990,8 @@ reglib_parse_rule_args_mw(char *line, struct ieee80211_reg_rule *reg_rule)
 	for (i = 0; i < 8; i++)
 		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
 
+	reg_rule->dfs_cac_ms = 0;
+
 	if (debug)
 		printf("reglib_parse_rule_args_mw(): %d flags: %d, line: %s",
 		       hits, reg_rule->flags, line);
@@ -989,6 +999,130 @@ reglib_parse_rule_args_mw(char *line, struct ieee80211_reg_rule *reg_rule)
 #undef IGNORE_COMMA_OR_SPACE
 }
 
+static int
+reglib_parse_rule_args_mw_cac(char *line, struct ieee80211_reg_rule *reg_rule)
+{
+#define IGNORE_COMMA_OR_SPACE "%*[ ,]"
+	int hits;
+	char flag_list[9][100];
+	unsigned int i = 0, dfs_cac_ms;
+	char mw[3];
+	float start_freq_khz, end_freq_khz, max_bandwidth_khz, max_eirp;
+
+	for (i = 0; i < 9; i++)
+		memset(flag_list[i], 0, sizeof(flag_list[i]));
+
+	hits = sscanf(line, "\t(%f - %f @ %f), (%f %2[mW]), (%u),"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s",
+		      &start_freq_khz,
+		      &end_freq_khz,
+		      &max_bandwidth_khz,
+		      &max_eirp,
+		      mw,
+		      &dfs_cac_ms,
+		      flag_list[0],
+		      flag_list[1],
+		      flag_list[2],
+		      flag_list[3],
+		      flag_list[4],
+		      flag_list[5],
+		      flag_list[6],
+		      flag_list[7],
+		      flag_list[8]);
+
+	if (hits < 6)
+		return -EINVAL;
+
+	reg_rule->freq_range.start_freq_khz =
+		REGLIB_MHZ_TO_KHZ(start_freq_khz);
+	reg_rule->freq_range.end_freq_khz =
+		REGLIB_MHZ_TO_KHZ(end_freq_khz);
+	reg_rule->freq_range.max_bandwidth_khz =
+		REGLIB_MHZ_TO_KHZ(max_bandwidth_khz);
+	reg_rule->power_rule.max_eirp =
+		REGLIB_MW_TO_MBM(max_eirp);
+
+	for (i = 0; i < 8; i++)
+		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
+
+	reg_rule->dfs_cac_ms = dfs_cac_ms;
+
+	if (debug)
+		printf("reglib_parse_rule_args_mw_cac(): %d flags: %d, line: %s",
+		       hits, reg_rule->flags, line);
+	return 0;
+#undef IGNORE_COMMA_OR_SPACE
+}
+
+static int
+reglib_parse_rule_args_cac(char *line, struct ieee80211_reg_rule *reg_rule)
+{
+#define IGNORE_COMMA_OR_SPACE "%*[ ,]"
+	int hits;
+	char flag_list[9][100];
+	unsigned int i = 0, dfs_cac_ms;
+	float start_freq_khz, end_freq_khz, max_bandwidth_khz, max_eirp;
+
+	for (i = 0; i < 9; i++)
+		memset(flag_list[i], 0, sizeof(flag_list[i]));
+
+	hits = sscanf(line, "\t(%f - %f @ %f), (%f), (%u)"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s"
+		      IGNORE_COMMA_OR_SPACE "%s",
+		      &start_freq_khz,
+		      &end_freq_khz,
+		      &max_bandwidth_khz,
+		      &max_eirp,
+		      &dfs_cac_ms,
+		      flag_list[0],
+		      flag_list[1],
+		      flag_list[2],
+		      flag_list[3],
+		      flag_list[4],
+		      flag_list[5],
+		      flag_list[6],
+		      flag_list[7],
+		      flag_list[8]);
+
+	if (hits < 6)
+		return -EINVAL;
+
+	reg_rule->freq_range.start_freq_khz =
+		REGLIB_MHZ_TO_KHZ(start_freq_khz);
+	reg_rule->freq_range.end_freq_khz =
+		REGLIB_MHZ_TO_KHZ(end_freq_khz);
+	reg_rule->freq_range.max_bandwidth_khz =
+		REGLIB_MHZ_TO_KHZ(max_bandwidth_khz);
+	reg_rule->power_rule.max_eirp =
+		REGLIB_DBM_TO_MBM(max_eirp);
+
+	for (i = 0; i < 8; i++)
+		reg_rule->flags |= reglib_parse_rule_flag(flag_list[i]);
+
+	reg_rule->dfs_cac_ms = dfs_cac_ms;
+
+	if (debug)
+		printf("reglib_parse_rule_args_cac(): %d flags: %d, line: %s",
+		       hits, reg_rule->flags, line);
+
+	return 0;
+#undef IGNORE_COMMA_OR_SPACE
+}
 static int reglib_parse_rule(FILE *fp, struct ieee80211_reg_rule *reg_rule)
 {
 	char line[1024];
@@ -997,24 +1131,27 @@ static int reglib_parse_rule(FILE *fp, struct ieee80211_reg_rule *reg_rule)
 	int r = 0;
 	struct reglib_rule_parse_list *reglib_rule_parsers;
 	size_t size_parsers = sizeof(struct reglib_rule_parse_list) + 
-				4 * sizeof(int (*)(char *, struct ieee80211_reg_rule *));
+				6 * sizeof(int (*)(char *, struct ieee80211_reg_rule *));
 
 	reglib_rule_parsers = malloc(size_parsers);
 	if (!reglib_rule_parsers)
 		return -EINVAL;
 	memset(reglib_rule_parsers, 0, size_parsers);
 
-	reglib_rule_parsers->n_parsers = 4;
+	reglib_rule_parsers->n_parsers = 6;
+
 
 	/*
 	 * XXX: sscanf() is a bit odd with picking up mW
 	 * case over the simple one, this order however works,
 	 * gotta figure out how to be more precise.
 	 */
-	reglib_rule_parsers->rule_parsers[0] = reglib_parse_rule_args_mw;
-	reglib_rule_parsers->rule_parsers[1] = reglib_parse_rule_args;
-	reglib_rule_parsers->rule_parsers[2] = reglib_parse_rule_simple;
-	reglib_rule_parsers->rule_parsers[3] = reglib_parse_rule_simple_mw;
+	reglib_rule_parsers->rule_parsers[0] = reglib_parse_rule_args_mw_cac;
+	reglib_rule_parsers->rule_parsers[1] = reglib_parse_rule_args_cac;
+	reglib_rule_parsers->rule_parsers[2] = reglib_parse_rule_args_mw;
+	reglib_rule_parsers->rule_parsers[3] = reglib_parse_rule_args;
+	reglib_rule_parsers->rule_parsers[4] = reglib_parse_rule_simple;
+	reglib_rule_parsers->rule_parsers[5] = reglib_parse_rule_simple_mw;
 
 	memset(line, 0, sizeof(line));
 	line_p = fgets(line, sizeof(line), fp);
diff --git a/reglib.h b/reglib.h
index afd5ef6..77aa42a 100644
--- a/reglib.h
+++ b/reglib.h
@@ -28,6 +28,7 @@ struct ieee80211_reg_rule {
 	struct ieee80211_freq_range freq_range;
 	struct ieee80211_power_rule power_rule;
 	uint32_t flags;
+	uint32_t dfs_cac_ms;
 };
 
 struct ieee80211_regdomain {
-- 
1.7.9.5


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-09  8:40 ` [wireless-regdb] " Janusz Dziedzic
@ 2014-05-20  7:33   ` Luis R. Rodriguez
  -1 siblings, 0 replies; 37+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20  7:33 UTC (permalink / raw)
  To: Janusz Dziedzic; +Cc: wireless-regdb, linux-wireless

On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
<janusz.dziedzic@tieto.com> wrote:
> Introduce support for setting DFS CAC time
> in milliseconds.
>
> Eg.
> (5250 - 5330 @ AUTO), (20), (60000), DFS
>
> will setup CAC 60 seconds CAC time.

Can you elaborate whether or not this will require a bump on CRDA  and
issuing of two new wireless-regdb files for the different versions on
the commit log?

 Luis

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20  7:33   ` Luis R. Rodriguez
  0 siblings, 0 replies; 37+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20  7:33 UTC (permalink / raw)
  To: Janusz Dziedzic; +Cc: linux-wireless, wireless-regdb

On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
<janusz.dziedzic@tieto.com> wrote:
> Introduce support for setting DFS CAC time
> in milliseconds.
>
> Eg.
> (5250 - 5330 @ AUTO), (20), (60000), DFS
>
> will setup CAC 60 seconds CAC time.

Can you elaborate whether or not this will require a bump on CRDA  and
issuing of two new wireless-regdb files for the different versions on
the commit log?

 Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20  7:33   ` [wireless-regdb] " Luis R. Rodriguez
@ 2014-05-20 13:26     ` Janusz Dziedzic
  -1 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-20 13:26 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: wireless-regdb, linux-wireless

On 20 May 2014 09:33, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:
> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
> <janusz.dziedzic@tieto.com> wrote:
>> Introduce support for setting DFS CAC time
>> in milliseconds.
>>
>> Eg.
>> (5250 - 5330 @ AUTO), (20), (60000), DFS
>>
>> will setup CAC 60 seconds CAC time.
>
> Can you elaborate whether or not this will require a bump on CRDA  and
> issuing of two new wireless-regdb files for the different versions on
> the commit log?
>
Yes, sure - will add this.

BTW, probably you know, why we decide to split usermode regulatory
code into crda, regdb? This required binary interface between them and
a lot of "not needed" code? Why we don't simply zip/sign db.tx code
and parse this direrctly in crda and use just one user mode project
for that.
What was the reason for have regulatory in binary file?

BR
Janusz

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20 13:26     ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-20 13:26 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: linux-wireless, wireless-regdb

On 20 May 2014 09:33, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:
> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
> <janusz.dziedzic@tieto.com> wrote:
>> Introduce support for setting DFS CAC time
>> in milliseconds.
>>
>> Eg.
>> (5250 - 5330 @ AUTO), (20), (60000), DFS
>>
>> will setup CAC 60 seconds CAC time.
>
> Can you elaborate whether or not this will require a bump on CRDA  and
> issuing of two new wireless-regdb files for the different versions on
> the commit log?
>
Yes, sure - will add this.

BTW, probably you know, why we decide to split usermode regulatory
code into crda, regdb? This required binary interface between them and
a lot of "not needed" code? Why we don't simply zip/sign db.tx code
and parse this direrctly in crda and use just one user mode project
for that.
What was the reason for have regulatory in binary file?

BR
Janusz

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20  7:33   ` [wireless-regdb] " Luis R. Rodriguez
@ 2014-05-20 14:24     ` John W. Linville
  -1 siblings, 0 replies; 37+ messages in thread
From: John W. Linville @ 2014-05-20 14:24 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Janusz Dziedzic, wireless-regdb, linux-wireless

On Tue, May 20, 2014 at 12:33:51AM -0700, Luis R. Rodriguez wrote:
> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
> <janusz.dziedzic@tieto.com> wrote:
> > Introduce support for setting DFS CAC time
> > in milliseconds.
> >
> > Eg.
> > (5250 - 5330 @ AUTO), (20), (60000), DFS
> >
> > will setup CAC 60 seconds CAC time.
> 
> Can you elaborate whether or not this will require a bump on CRDA  and
> issuing of two new wireless-regdb files for the different versions on
> the commit log?

I would really prefer not to manage two regdb binary releases.
Fear of that is what has kept me from merging this patch.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20 14:24     ` John W. Linville
  0 siblings, 0 replies; 37+ messages in thread
From: John W. Linville @ 2014-05-20 14:24 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Janusz Dziedzic, linux-wireless, wireless-regdb

On Tue, May 20, 2014 at 12:33:51AM -0700, Luis R. Rodriguez wrote:
> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
> <janusz.dziedzic@tieto.com> wrote:
> > Introduce support for setting DFS CAC time
> > in milliseconds.
> >
> > Eg.
> > (5250 - 5330 @ AUTO), (20), (60000), DFS
> >
> > will setup CAC 60 seconds CAC time.
> 
> Can you elaborate whether or not this will require a bump on CRDA  and
> issuing of two new wireless-regdb files for the different versions on
> the commit log?

I would really prefer not to manage two regdb binary releases.
Fear of that is what has kept me from merging this patch.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20 14:24     ` [wireless-regdb] " John W. Linville
@ 2014-05-20 18:01       ` Janusz Dziedzic
  -1 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-20 18:01 UTC (permalink / raw)
  To: John W. Linville; +Cc: Luis R. Rodriguez, wireless-regdb, linux-wireless

On 20 May 2014 16:24, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, May 20, 2014 at 12:33:51AM -0700, Luis R. Rodriguez wrote:
>> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
>> <janusz.dziedzic@tieto.com> wrote:
>> > Introduce support for setting DFS CAC time
>> > in milliseconds.
>> >
>> > Eg.
>> > (5250 - 5330 @ AUTO), (20), (60000), DFS
>> >
>> > will setup CAC 60 seconds CAC time.
>>
>> Can you elaborate whether or not this will require a bump on CRDA  and
>> issuing of two new wireless-regdb files for the different versions on
>> the commit log?
>
> I would really prefer not to manage two regdb binary releases.
> Fear of that is what has kept me from merging this patch.
>
I can add support for version 19 and 20 in one crda. I am not sure
this is the best option.
BTW what about versions < 19? How do we handle this this days?

BR
Janusz

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20 18:01       ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-05-20 18:01 UTC (permalink / raw)
  To: John W. Linville; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez

On 20 May 2014 16:24, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, May 20, 2014 at 12:33:51AM -0700, Luis R. Rodriguez wrote:
>> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
>> <janusz.dziedzic@tieto.com> wrote:
>> > Introduce support for setting DFS CAC time
>> > in milliseconds.
>> >
>> > Eg.
>> > (5250 - 5330 @ AUTO), (20), (60000), DFS
>> >
>> > will setup CAC 60 seconds CAC time.
>>
>> Can you elaborate whether or not this will require a bump on CRDA  and
>> issuing of two new wireless-regdb files for the different versions on
>> the commit log?
>
> I would really prefer not to manage two regdb binary releases.
> Fear of that is what has kept me from merging this patch.
>
I can add support for version 19 and 20 in one crda. I am not sure
this is the best option.
BTW what about versions < 19? How do we handle this this days?

BR
Janusz

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20 18:01       ` [wireless-regdb] " Janusz Dziedzic
@ 2014-05-20 18:08         ` John W. Linville
  -1 siblings, 0 replies; 37+ messages in thread
From: John W. Linville @ 2014-05-20 18:08 UTC (permalink / raw)
  To: Janusz Dziedzic; +Cc: Luis R. Rodriguez, wireless-regdb, linux-wireless

On Tue, May 20, 2014 at 08:01:31PM +0200, Janusz Dziedzic wrote:
> On 20 May 2014 16:24, John W. Linville <linville@tuxdriver.com> wrote:
> > On Tue, May 20, 2014 at 12:33:51AM -0700, Luis R. Rodriguez wrote:
> >> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
> >> <janusz.dziedzic@tieto.com> wrote:
> >> > Introduce support for setting DFS CAC time
> >> > in milliseconds.
> >> >
> >> > Eg.
> >> > (5250 - 5330 @ AUTO), (20), (60000), DFS
> >> >
> >> > will setup CAC 60 seconds CAC time.
> >>
> >> Can you elaborate whether or not this will require a bump on CRDA  and
> >> issuing of two new wireless-regdb files for the different versions on
> >> the commit log?
> >
> > I would really prefer not to manage two regdb binary releases.
> > Fear of that is what has kept me from merging this patch.
> >
> I can add support for version 19 and 20 in one crda. I am not sure
> this is the best option.
> BTW what about versions < 19? How do we handle this this days?

What about older CRDA with newer wireless-regdb?  Do we need to worry about that?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20 18:08         ` John W. Linville
  0 siblings, 0 replies; 37+ messages in thread
From: John W. Linville @ 2014-05-20 18:08 UTC (permalink / raw)
  To: Janusz Dziedzic; +Cc: linux-wireless, wireless-regdb, Luis R. Rodriguez

On Tue, May 20, 2014 at 08:01:31PM +0200, Janusz Dziedzic wrote:
> On 20 May 2014 16:24, John W. Linville <linville@tuxdriver.com> wrote:
> > On Tue, May 20, 2014 at 12:33:51AM -0700, Luis R. Rodriguez wrote:
> >> On Fri, May 9, 2014 at 1:40 AM, Janusz Dziedzic
> >> <janusz.dziedzic@tieto.com> wrote:
> >> > Introduce support for setting DFS CAC time
> >> > in milliseconds.
> >> >
> >> > Eg.
> >> > (5250 - 5330 @ AUTO), (20), (60000), DFS
> >> >
> >> > will setup CAC 60 seconds CAC time.
> >>
> >> Can you elaborate whether or not this will require a bump on CRDA  and
> >> issuing of two new wireless-regdb files for the different versions on
> >> the commit log?
> >
> > I would really prefer not to manage two regdb binary releases.
> > Fear of that is what has kept me from merging this patch.
> >
> I can add support for version 19 and 20 in one crda. I am not sure
> this is the best option.
> BTW what about versions < 19? How do we handle this this days?

What about older CRDA with newer wireless-regdb?  Do we need to worry about that?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20 18:08         ` [wireless-regdb] " John W. Linville
@ 2014-05-20 18:24           ` Johannes Berg
  -1 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-05-20 18:24 UTC (permalink / raw)
  To: John W. Linville
  Cc: Janusz Dziedzic, Luis R. Rodriguez, wireless-regdb, linux-wireless

On Tue, 2014-05-20 at 14:08 -0400, John W. Linville wrote:

> > I can add support for version 19 and 20 in one crda. I am not sure
> > this is the best option.
> > BTW what about versions < 19? How do we handle this this days?
> 
> What about older CRDA with newer wireless-regdb?  Do we need to worry about that?

I think we should, but if we can't then at least can we cut to an
extensible format?

(and yeah, I know I was part of defining the format ...)

johannes


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20 18:24           ` Johannes Berg
  0 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-05-20 18:24 UTC (permalink / raw)
  To: John W. Linville
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb, Luis R. Rodriguez

On Tue, 2014-05-20 at 14:08 -0400, John W. Linville wrote:

> > I can add support for version 19 and 20 in one crda. I am not sure
> > this is the best option.
> > BTW what about versions < 19? How do we handle this this days?
> 
> What about older CRDA with newer wireless-regdb?  Do we need to worry about that?

I think we should, but if we can't then at least can we cut to an
extensible format?

(and yeah, I know I was part of defining the format ...)

johannes


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20 18:24           ` [wireless-regdb] " Johannes Berg
@ 2014-05-20 18:48             ` Luis R. Rodriguez
  -1 siblings, 0 replies; 37+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 18:48 UTC (permalink / raw)
  To: Johannes Berg
  Cc: John W. Linville, Janusz Dziedzic, wireless-regdb, linux-wireless

On Tue, May 20, 2014 at 11:24 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2014-05-20 at 14:08 -0400, John W. Linville wrote:
>
>> > I can add support for version 19 and 20 in one crda. I am not sure
>> > this is the best option.
>> > BTW what about versions < 19? How do we handle this this days?
>>
>> What about older CRDA with newer wireless-regdb?  Do we need to worry about that?
>
> I think we should, but if we can't then at least can we cut to an
> extensible format?

Janusz,

this is in short part of the work I expect to be dealt with as part of
the change. What I think we should strive for since we have control
over the format, is have extensions which upkeep old CRDA versions
working, and only if new CRDA is present would we use the new
attributes. Please see if this is possible.

  Luis

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-20 18:48             ` Luis R. Rodriguez
  0 siblings, 0 replies; 37+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 18:48 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb, John W. Linville

On Tue, May 20, 2014 at 11:24 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2014-05-20 at 14:08 -0400, John W. Linville wrote:
>
>> > I can add support for version 19 and 20 in one crda. I am not sure
>> > this is the best option.
>> > BTW what about versions < 19? How do we handle this this days?
>>
>> What about older CRDA with newer wireless-regdb?  Do we need to worry about that?
>
> I think we should, but if we can't then at least can we cut to an
> extensible format?

Janusz,

this is in short part of the work I expect to be dealt with as part of
the change. What I think we should strive for since we have control
over the format, is have extensions which upkeep old CRDA versions
working, and only if new CRDA is present would we use the new
attributes. Please see if this is possible.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-20 18:48             ` [wireless-regdb] " Luis R. Rodriguez
@ 2014-05-21 16:03               ` Johannes Berg
  -1 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-05-21 16:03 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: John W. Linville, Janusz Dziedzic, wireless-regdb, linux-wireless

On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:

> > I think we should, but if we can't then at least can we cut to an
> > extensible format?

I don't see any way to extend the format right now.

There's a wrinkle with making it more extensible too though - if we do
that then we must be extremely careful that future older crda versions
(i.e. the next version that we're about to write) will not parse a newer
extended file more permissively, so our extensions are limited anyway.

Looks like the format update really is needed, which probably means we
should change the scripts to generate two databases and change the
filename, or so?

johannes


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-21 16:03               ` Johannes Berg
  0 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-05-21 16:03 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb, John W. Linville

On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:

> > I think we should, but if we can't then at least can we cut to an
> > extensible format?

I don't see any way to extend the format right now.

There's a wrinkle with making it more extensible too though - if we do
that then we must be extremely careful that future older crda versions
(i.e. the next version that we're about to write) will not parse a newer
extended file more permissively, so our extensions are limited anyway.

Looks like the format update really is needed, which probably means we
should change the scripts to generate two databases and change the
filename, or so?

johannes


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-21 16:03               ` [wireless-regdb] " Johannes Berg
@ 2014-05-21 18:00                 ` John W. Linville
  -1 siblings, 0 replies; 37+ messages in thread
From: John W. Linville @ 2014-05-21 18:00 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Luis R. Rodriguez, Janusz Dziedzic, wireless-regdb, linux-wireless

On Wed, May 21, 2014 at 06:03:53PM +0200, Johannes Berg wrote:
> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
> 
> > > I think we should, but if we can't then at least can we cut to an
> > > extensible format?
> 
> I don't see any way to extend the format right now.
> 
> There's a wrinkle with making it more extensible too though - if we do
> that then we must be extremely careful that future older crda versions
> (i.e. the next version that we're about to write) will not parse a newer
> extended file more permissively, so our extensions are limited anyway.
> 
> Looks like the format update really is needed, which probably means we
> should change the scripts to generate two databases and change the
> filename, or so?

The 'do not parse more permissively' would seem to be a problem if
we still produce an older format too, no?  I mean, wouldn't we have
to simply drop new rules to produce an older binary?  Even worse if
we left the old binary in place, since then you could never update
any rules for old crda installations at all.

It seems like forcing a crda update to use any new format-breaking
rules might just be the right thing.  Can we make crda choke and die
loudly when it sees an unknown format?  Will the current crda do that?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-21 18:00                 ` John W. Linville
  0 siblings, 0 replies; 37+ messages in thread
From: John W. Linville @ 2014-05-21 18:00 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb, Luis R. Rodriguez

On Wed, May 21, 2014 at 06:03:53PM +0200, Johannes Berg wrote:
> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
> 
> > > I think we should, but if we can't then at least can we cut to an
> > > extensible format?
> 
> I don't see any way to extend the format right now.
> 
> There's a wrinkle with making it more extensible too though - if we do
> that then we must be extremely careful that future older crda versions
> (i.e. the next version that we're about to write) will not parse a newer
> extended file more permissively, so our extensions are limited anyway.
> 
> Looks like the format update really is needed, which probably means we
> should change the scripts to generate two databases and change the
> filename, or so?

The 'do not parse more permissively' would seem to be a problem if
we still produce an older format too, no?  I mean, wouldn't we have
to simply drop new rules to produce an older binary?  Even worse if
we left the old binary in place, since then you could never update
any rules for old crda installations at all.

It seems like forcing a crda update to use any new format-breaking
rules might just be the right thing.  Can we make crda choke and die
loudly when it sees an unknown format?  Will the current crda do that?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-21 18:00                 ` [wireless-regdb] " John W. Linville
@ 2014-05-21 19:09                   ` Johannes Berg
  -1 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-05-21 19:09 UTC (permalink / raw)
  To: John W. Linville
  Cc: Luis R. Rodriguez, Janusz Dziedzic, wireless-regdb, linux-wireless

On Wed, 2014-05-21 at 14:00 -0400, John W. Linville wrote:

> The 'do not parse more permissively' would seem to be a problem if
> we still produce an older format too, no?  I mean, wouldn't we have
> to simply drop new rules to produce an older binary?  Even worse if
> we left the old binary in place, since then you could never update
> any rules for old crda installations at all.

That's true, in a sense.

> It seems like forcing a crda update to use any new format-breaking
> rules might just be the right thing.  Can we make crda choke and die
> loudly when it sees an unknown format?  Will the current crda do that?

It will, yes. If the version number is mismatched it'll print "Invalid
database version" (to stderr) and exit.

johannes


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-05-21 19:09                   ` Johannes Berg
  0 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-05-21 19:09 UTC (permalink / raw)
  To: John W. Linville
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb, Luis R. Rodriguez

On Wed, 2014-05-21 at 14:00 -0400, John W. Linville wrote:

> The 'do not parse more permissively' would seem to be a problem if
> we still produce an older format too, no?  I mean, wouldn't we have
> to simply drop new rules to produce an older binary?  Even worse if
> we left the old binary in place, since then you could never update
> any rules for old crda installations at all.

That's true, in a sense.

> It seems like forcing a crda update to use any new format-breaking
> rules might just be the right thing.  Can we make crda choke and die
> loudly when it sees an unknown format?  Will the current crda do that?

It will, yes. If the version number is mismatched it'll print "Invalid
database version" (to stderr) and exit.

johannes


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-21 19:09                   ` [wireless-regdb] " Johannes Berg
@ 2014-06-09  7:33                     ` Janusz Dziedzic
  -1 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-06-09  7:33 UTC (permalink / raw)
  To: Johannes Berg
  Cc: John W. Linville, Luis R. Rodriguez, wireless-regdb, linux-wireless

On 21 May 2014 21:09, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2014-05-21 at 14:00 -0400, John W. Linville wrote:
>
>> The 'do not parse more permissively' would seem to be a problem if
>> we still produce an older format too, no?  I mean, wouldn't we have
>> to simply drop new rules to produce an older binary?  Even worse if
>> we left the old binary in place, since then you could never update
>> any rules for old crda installations at all.
>
> That's true, in a sense.
>
>> It seems like forcing a crda update to use any new format-breaking
>> rules might just be the right thing.  Can we make crda choke and die
>> loudly when it sees an unknown format?  Will the current crda do that?
>
> It will, yes. If the version number is mismatched it'll print "Invalid
> database version" (to stderr) and exit.
>

Why not just skip this binary interface between regdb --> crda and use
signed db.txt file?

Eg.
1) first we sign db.txt file using gpg - that will be all what
wireless-regdb will do

        cat db.txt | gpg --clearsign --default-key regdbkey_private >
db_signed.txt

As a result we will get something like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

# This is the world regulatory domain
country 00:
(2402 - 2472 @ 40), (20)
# Channel 12 - 13.
(2457 - 2482 @ 20), (20), NO-IR AUTO-BW
# Channel 14. Only JP enables this and for 802.11b only
(2474 - 2494 @ 20), (20), NO-IR
# Channel 36 - 48
(5170 - 5250 @ 80), (20), NO-IR
# NB: 5260 MHz - 5700 MHz requies DFS
# Channel 149 - 165
(5735 - 5835 @ 80), (20), NO-IR
# IEEE 802.11ad (60GHz), channels 1..3
(57240 - 63720 @ 2160), (0)

....

country ZW: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20)
(5250 - 5330 @ 80), (20), DFS
(5490 - 5710 @ 80), (27), DFS

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTkbhXAAoJEJMu885bZibypxYH+QEVe1VNDalrzS99luWrqLn1
Cfrck6l4rdb/z+Ef1lGRxjYtvad/bRTYBHLwWqJEt/R5dvf1k32sNlZU+++dBLsg
IFBHlVdYa7DQok0K0Hfw8jGU3S6+XrSnFUHhiBR0NRP/SJGzevSE+MhVNulf6bZu
/uN1nW/+VCZ46wh5EGarWO3cWFCAJKJXujPWN6Zm97ieOBtAN95BHk29h5g+aSNS
NcszEvbIy86kKquCTUWQcAgUAp0ZijlQin1NoXr87Z3k9vKSAIK4kp+8WIfnHYYE
Y3g/lOMHh6bKOKllYxBxWNZQIgLP1R2yf/qv8JyGfeQTNfNlCihIQRFQeU0Hj5U=
=pCXt
-----END PGP SIGNATURE-----

2) crda will be a script that will do something like that:

        sh gpg_verify.sh && sh show_country.sh | crda_tiny

a) gpg_verify.sh will verify db.txt signature
- gpg --default-key regdb_public --verify db_signed.txt

b) show_country.sh will print text country base on COUNTRY enviroment
eg.
janusz@dell:~/work/gpg$ COUNTRY=US ./show_country.sh
country US: DFS-FCC
(2402 - 2472 @ 40), (30)
(5170 - 5250 @ 80), (17)
(5250 - 5330 @ 80), (23), DFS
(5735 - 5835 @ 80), (30)
(57240 - 63720 @ 2160), (40)

c) crda_tiny will parse this text and will pass regdb parameters using nl80211


BR
Janusz

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-06-09  7:33                     ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-06-09  7:33 UTC (permalink / raw)
  To: Johannes Berg
  Cc: linux-wireless, wireless-regdb, John W. Linville, Luis R. Rodriguez

On 21 May 2014 21:09, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2014-05-21 at 14:00 -0400, John W. Linville wrote:
>
>> The 'do not parse more permissively' would seem to be a problem if
>> we still produce an older format too, no?  I mean, wouldn't we have
>> to simply drop new rules to produce an older binary?  Even worse if
>> we left the old binary in place, since then you could never update
>> any rules for old crda installations at all.
>
> That's true, in a sense.
>
>> It seems like forcing a crda update to use any new format-breaking
>> rules might just be the right thing.  Can we make crda choke and die
>> loudly when it sees an unknown format?  Will the current crda do that?
>
> It will, yes. If the version number is mismatched it'll print "Invalid
> database version" (to stderr) and exit.
>

Why not just skip this binary interface between regdb --> crda and use
signed db.txt file?

Eg.
1) first we sign db.txt file using gpg - that will be all what
wireless-regdb will do

        cat db.txt | gpg --clearsign --default-key regdbkey_private >
db_signed.txt

As a result we will get something like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

# This is the world regulatory domain
country 00:
(2402 - 2472 @ 40), (20)
# Channel 12 - 13.
(2457 - 2482 @ 20), (20), NO-IR AUTO-BW
# Channel 14. Only JP enables this and for 802.11b only
(2474 - 2494 @ 20), (20), NO-IR
# Channel 36 - 48
(5170 - 5250 @ 80), (20), NO-IR
# NB: 5260 MHz - 5700 MHz requies DFS
# Channel 149 - 165
(5735 - 5835 @ 80), (20), NO-IR
# IEEE 802.11ad (60GHz), channels 1..3
(57240 - 63720 @ 2160), (0)

....

country ZW: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20)
(5250 - 5330 @ 80), (20), DFS
(5490 - 5710 @ 80), (27), DFS

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTkbhXAAoJEJMu885bZibypxYH+QEVe1VNDalrzS99luWrqLn1
Cfrck6l4rdb/z+Ef1lGRxjYtvad/bRTYBHLwWqJEt/R5dvf1k32sNlZU+++dBLsg
IFBHlVdYa7DQok0K0Hfw8jGU3S6+XrSnFUHhiBR0NRP/SJGzevSE+MhVNulf6bZu
/uN1nW/+VCZ46wh5EGarWO3cWFCAJKJXujPWN6Zm97ieOBtAN95BHk29h5g+aSNS
NcszEvbIy86kKquCTUWQcAgUAp0ZijlQin1NoXr87Z3k9vKSAIK4kp+8WIfnHYYE
Y3g/lOMHh6bKOKllYxBxWNZQIgLP1R2yf/qv8JyGfeQTNfNlCihIQRFQeU0Hj5U=
=pCXt
-----END PGP SIGNATURE-----

2) crda will be a script that will do something like that:

        sh gpg_verify.sh && sh show_country.sh | crda_tiny

a) gpg_verify.sh will verify db.txt signature
- gpg --default-key regdb_public --verify db_signed.txt

b) show_country.sh will print text country base on COUNTRY enviroment
eg.
janusz@dell:~/work/gpg$ COUNTRY=US ./show_country.sh
country US: DFS-FCC
(2402 - 2472 @ 40), (30)
(5170 - 5250 @ 80), (17)
(5250 - 5330 @ 80), (23), DFS
(5735 - 5835 @ 80), (30)
(57240 - 63720 @ 2160), (40)

c) crda_tiny will parse this text and will pass regdb parameters using nl80211


BR
Janusz

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-05-21 16:03               ` [wireless-regdb] " Johannes Berg
@ 2014-06-09  8:00                 ` Felix Fietkau
  -1 siblings, 0 replies; 37+ messages in thread
From: Felix Fietkau @ 2014-06-09  8:00 UTC (permalink / raw)
  To: Johannes Berg, Luis R. Rodriguez
  Cc: John W. Linville, Janusz Dziedzic, wireless-regdb, linux-wireless

On 2014-05-21 18:03, Johannes Berg wrote:
> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
> 
>> > I think we should, but if we can't then at least can we cut to an
>> > extensible format?
> 
> I don't see any way to extend the format right now.
> 
> There's a wrinkle with making it more extensible too though - if we do
> that then we must be extremely careful that future older crda versions
> (i.e. the next version that we're about to write) will not parse a newer
> extended file more permissively, so our extensions are limited anyway.
> 
> Looks like the format update really is needed, which probably means we
> should change the scripts to generate two databases and change the
> filename, or so?
How about making the format properly extensible by reusing what we're
already doing to keep the kernel ABI stable? For example, we could store
the database in a netlink-like attribute format, with some changes to
make it fixed endian.
I'm already doing just that for a few things in OpenWrt, so I have
working C code for writing and parsing such a format.

Another nice feature would be to indicate in the attributes if crda is
required to understand them, or if it can just continue with a warning.

If done right, I think we can probably make this the last time we change
the format version.

- Felix

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-06-09  8:00                 ` Felix Fietkau
  0 siblings, 0 replies; 37+ messages in thread
From: Felix Fietkau @ 2014-06-09  8:00 UTC (permalink / raw)
  To: Johannes Berg, Luis R. Rodriguez
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb, John W. Linville

On 2014-05-21 18:03, Johannes Berg wrote:
> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
> 
>> > I think we should, but if we can't then at least can we cut to an
>> > extensible format?
> 
> I don't see any way to extend the format right now.
> 
> There's a wrinkle with making it more extensible too though - if we do
> that then we must be extremely careful that future older crda versions
> (i.e. the next version that we're about to write) will not parse a newer
> extended file more permissively, so our extensions are limited anyway.
> 
> Looks like the format update really is needed, which probably means we
> should change the scripts to generate two databases and change the
> filename, or so?
How about making the format properly extensible by reusing what we're
already doing to keep the kernel ABI stable? For example, we could store
the database in a netlink-like attribute format, with some changes to
make it fixed endian.
I'm already doing just that for a few things in OpenWrt, so I have
working C code for writing and parsing such a format.

Another nice feature would be to indicate in the attributes if crda is
required to understand them, or if it can just continue with a warning.

If done right, I think we can probably make this the last time we change
the format version.

- Felix

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-06-09  8:00                 ` [wireless-regdb] " Felix Fietkau
@ 2014-06-09 10:22                   ` Janusz Dziedzic
  -1 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-06-09 10:22 UTC (permalink / raw)
  To: Felix Fietkau
  Cc: Johannes Berg, Luis R. Rodriguez, John W. Linville,
	wireless-regdb, linux-wireless

On 9 June 2014 10:00, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2014-05-21 18:03, Johannes Berg wrote:
>> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
>>
>>> > I think we should, but if we can't then at least can we cut to an
>>> > extensible format?
>>
>> I don't see any way to extend the format right now.
>>
>> There's a wrinkle with making it more extensible too though - if we do
>> that then we must be extremely careful that future older crda versions
>> (i.e. the next version that we're about to write) will not parse a newer
>> extended file more permissively, so our extensions are limited anyway.
>>
>> Looks like the format update really is needed, which probably means we
>> should change the scripts to generate two databases and change the
>> filename, or so?
> How about making the format properly extensible by reusing what we're
> already doing to keep the kernel ABI stable? For example, we could store
> the database in a netlink-like attribute format, with some changes to
> make it fixed endian.
> I'm already doing just that for a few things in OpenWrt, so I have
> working C code for writing and parsing such a format.
>
> Another nice feature would be to indicate in the attributes if crda is
> required to understand them, or if it can just continue with a warning.
>
> If done right, I think we can probably make this the last time we change
> the format version.
>
What kind of benefit we have having binary format between crda <->
wireless-regd (nl-based or current regulatory.bin)?
This is additional code/work to do - why we need that?

BR
Janusz

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-06-09 10:22                   ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-06-09 10:22 UTC (permalink / raw)
  To: Felix Fietkau
  Cc: linux-wireless, Johannes Berg, wireless-regdb, John W. Linville,
	Luis R. Rodriguez

On 9 June 2014 10:00, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2014-05-21 18:03, Johannes Berg wrote:
>> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
>>
>>> > I think we should, but if we can't then at least can we cut to an
>>> > extensible format?
>>
>> I don't see any way to extend the format right now.
>>
>> There's a wrinkle with making it more extensible too though - if we do
>> that then we must be extremely careful that future older crda versions
>> (i.e. the next version that we're about to write) will not parse a newer
>> extended file more permissively, so our extensions are limited anyway.
>>
>> Looks like the format update really is needed, which probably means we
>> should change the scripts to generate two databases and change the
>> filename, or so?
> How about making the format properly extensible by reusing what we're
> already doing to keep the kernel ABI stable? For example, we could store
> the database in a netlink-like attribute format, with some changes to
> make it fixed endian.
> I'm already doing just that for a few things in OpenWrt, so I have
> working C code for writing and parsing such a format.
>
> Another nice feature would be to indicate in the attributes if crda is
> required to understand them, or if it can just continue with a warning.
>
> If done right, I think we can probably make this the last time we change
> the format version.
>
What kind of benefit we have having binary format between crda <->
wireless-regd (nl-based or current regulatory.bin)?
This is additional code/work to do - why we need that?

BR
Janusz

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-06-09 10:22                   ` [wireless-regdb] " Janusz Dziedzic
@ 2014-06-09 12:27                     ` Janusz Dziedzic
  -1 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-06-09 12:27 UTC (permalink / raw)
  To: Felix Fietkau
  Cc: Johannes Berg, Luis R. Rodriguez, John W. Linville,
	wireless-regdb, linux-wireless

On 9 June 2014 12:22, Janusz Dziedzic <janusz.dziedzic@tieto.com> wrote:
> On 9 June 2014 10:00, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2014-05-21 18:03, Johannes Berg wrote:
>>> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
>>>
>>>> > I think we should, but if we can't then at least can we cut to an
>>>> > extensible format?
>>>
>>> I don't see any way to extend the format right now.
>>>
>>> There's a wrinkle with making it more extensible too though - if we do
>>> that then we must be extremely careful that future older crda versions
>>> (i.e. the next version that we're about to write) will not parse a newer
>>> extended file more permissively, so our extensions are limited anyway.
>>>
>>> Looks like the format update really is needed, which probably means we
>>> should change the scripts to generate two databases and change the
>>> filename, or so?
>> How about making the format properly extensible by reusing what we're
>> already doing to keep the kernel ABI stable? For example, we could store
>> the database in a netlink-like attribute format, with some changes to
>> make it fixed endian.
>> I'm already doing just that for a few things in OpenWrt, so I have
>> working C code for writing and parsing such a format.
>>
>> Another nice feature would be to indicate in the attributes if crda is
>> required to understand them, or if it can just continue with a warning.
>>
>> If done right, I think we can probably make this the last time we change
>> the format version.
>>
> What kind of benefit we have having binary format between crda <->
> wireless-regd (nl-based or current regulatory.bin)?
> This is additional code/work to do - why we need that?
>

This is example of /sbin/crda script I have - seems works fine (small
crda_tiny also required):

#!/bin/sh
PUBKEY=/usr/lib/crda/pubkeys/regdb_pubring.gpg
REGDB=/usr/lib/crda/db.txt
CRDA_BIN=/sbin/crda_tiny
LOG=/tmp/crda.err

gpg_verify() {
    PUBKEY=$1
    REGDB=$2
    gpg --no-default-keyring --keyring $PUBKEY --verify $REGDB
}

show_country() {
    REGDB=$1
    COUNTRY=$2

    cat $REGDB \
    | sed '
        s/#.*//
        s/^[ \t]*$//
    ' \
    | awk \
        -v ctry=$COUNTRY '

        /country/{show=0}
        /BEGIN PGP SIGNATURE/{show=0}
        /country / && $2 == ctry ":" {show=1}
        show && !/^$/
   '
}

(
/bin/date
echo "$0 called with params:"
echo "COUNTRY: $COUNTRY"
echo "DB: $REGDB"
echo "PUBKEY: $PUBKEY"
echo "CRDA: $CRDA_BIN"

gpg_verify "$PUBKEY" "$REGDB" && show_country "$REGDB" "$COUNTRY" | "$CRDA_BIN"

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-06-09 12:27                     ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-06-09 12:27 UTC (permalink / raw)
  To: Felix Fietkau
  Cc: linux-wireless, Johannes Berg, wireless-regdb, John W. Linville,
	Luis R. Rodriguez

On 9 June 2014 12:22, Janusz Dziedzic <janusz.dziedzic@tieto.com> wrote:
> On 9 June 2014 10:00, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2014-05-21 18:03, Johannes Berg wrote:
>>> On Tue, 2014-05-20 at 11:48 -0700, Luis R. Rodriguez wrote:
>>>
>>>> > I think we should, but if we can't then at least can we cut to an
>>>> > extensible format?
>>>
>>> I don't see any way to extend the format right now.
>>>
>>> There's a wrinkle with making it more extensible too though - if we do
>>> that then we must be extremely careful that future older crda versions
>>> (i.e. the next version that we're about to write) will not parse a newer
>>> extended file more permissively, so our extensions are limited anyway.
>>>
>>> Looks like the format update really is needed, which probably means we
>>> should change the scripts to generate two databases and change the
>>> filename, or so?
>> How about making the format properly extensible by reusing what we're
>> already doing to keep the kernel ABI stable? For example, we could store
>> the database in a netlink-like attribute format, with some changes to
>> make it fixed endian.
>> I'm already doing just that for a few things in OpenWrt, so I have
>> working C code for writing and parsing such a format.
>>
>> Another nice feature would be to indicate in the attributes if crda is
>> required to understand them, or if it can just continue with a warning.
>>
>> If done right, I think we can probably make this the last time we change
>> the format version.
>>
> What kind of benefit we have having binary format between crda <->
> wireless-regd (nl-based or current regulatory.bin)?
> This is additional code/work to do - why we need that?
>

This is example of /sbin/crda script I have - seems works fine (small
crda_tiny also required):

#!/bin/sh
PUBKEY=/usr/lib/crda/pubkeys/regdb_pubring.gpg
REGDB=/usr/lib/crda/db.txt
CRDA_BIN=/sbin/crda_tiny
LOG=/tmp/crda.err

gpg_verify() {
    PUBKEY=$1
    REGDB=$2
    gpg --no-default-keyring --keyring $PUBKEY --verify $REGDB
}

show_country() {
    REGDB=$1
    COUNTRY=$2

    cat $REGDB \
    | sed '
        s/#.*//
        s/^[ \t]*$//
    ' \
    | awk \
        -v ctry=$COUNTRY '

        /country/{show=0}
        /BEGIN PGP SIGNATURE/{show=0}
        /country / && $2 == ctry ":" {show=1}
        show && !/^$/
   '
}

(
/bin/date
echo "$0 called with params:"
echo "COUNTRY: $COUNTRY"
echo "DB: $REGDB"
echo "PUBKEY: $PUBKEY"
echo "CRDA: $CRDA_BIN"

gpg_verify "$PUBKEY" "$REGDB" && show_country "$REGDB" "$COUNTRY" | "$CRDA_BIN"

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-06-09  7:33                     ` [wireless-regdb] " Janusz Dziedzic
@ 2014-06-10 16:45                       ` Johannes Berg
  -1 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-06-10 16:45 UTC (permalink / raw)
  To: Janusz Dziedzic
  Cc: John W. Linville, Luis R. Rodriguez, wireless-regdb, linux-wireless

On Mon, 2014-06-09 at 09:33 +0200, Janusz Dziedzic wrote:

> Why not just skip this binary interface between regdb --> crda and use
> signed db.txt file?

I fail to see how that's any better? If anything, it seems to me that it
would be *harder* to keep the database text format parseable to old CRDA
versions when making changes.

johannes


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-06-10 16:45                       ` Johannes Berg
  0 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-06-10 16:45 UTC (permalink / raw)
  To: Janusz Dziedzic
  Cc: linux-wireless, wireless-regdb, John W. Linville, Luis R. Rodriguez

On Mon, 2014-06-09 at 09:33 +0200, Janusz Dziedzic wrote:

> Why not just skip this binary interface between regdb --> crda and use
> signed db.txt file?

I fail to see how that's any better? If anything, it seems to me that it
would be *harder* to keep the database text format parseable to old CRDA
versions when making changes.

johannes


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-06-09  8:00                 ` [wireless-regdb] " Felix Fietkau
@ 2014-06-10 16:46                   ` Johannes Berg
  -1 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-06-10 16:46 UTC (permalink / raw)
  To: Felix Fietkau
  Cc: Luis R. Rodriguez, John W. Linville, Janusz Dziedzic,
	wireless-regdb, linux-wireless

On Mon, 2014-06-09 at 10:00 +0200, Felix Fietkau wrote:

> > Looks like the format update really is needed, which probably means we
> > should change the scripts to generate two databases and change the
> > filename, or so?

> How about making the format properly extensible by reusing what we're
> already doing to keep the kernel ABI stable? For example, we could store
> the database in a netlink-like attribute format, with some changes to
> make it fixed endian.
> I'm already doing just that for a few things in OpenWrt, so I have
> working C code for writing and parsing such a format.
> 
> Another nice feature would be to indicate in the attributes if crda is
> required to understand them, or if it can just continue with a warning.
> 
> If done right, I think we can probably make this the last time we change
> the format version.

Sure, that seems like a more detailed version of email :)
I don't really care about the low-level details that much.

johannes


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [wireless-regdb] [PATCH] wireless-regdb: add DFS CAC time parameter
@ 2014-06-10 16:46                   ` Johannes Berg
  0 siblings, 0 replies; 37+ messages in thread
From: Johannes Berg @ 2014-06-10 16:46 UTC (permalink / raw)
  To: Felix Fietkau
  Cc: Janusz Dziedzic, linux-wireless, wireless-regdb,
	John W. Linville, Luis R. Rodriguez

On Mon, 2014-06-09 at 10:00 +0200, Felix Fietkau wrote:

> > Looks like the format update really is needed, which probably means we
> > should change the scripts to generate two databases and change the
> > filename, or so?

> How about making the format properly extensible by reusing what we're
> already doing to keep the kernel ABI stable? For example, we could store
> the database in a netlink-like attribute format, with some changes to
> make it fixed endian.
> I'm already doing just that for a few things in OpenWrt, so I have
> working C code for writing and parsing such a format.
> 
> Another nice feature would be to indicate in the attributes if crda is
> required to understand them, or if it can just continue with a warning.
> 
> If done right, I think we can probably make this the last time we change
> the format version.

Sure, that seems like a more detailed version of email :)
I don't really care about the low-level details that much.

johannes


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb


^ permalink raw reply	[flat|nested] 37+ messages in thread

* [PATCH] wireless-regdb: add DFS CAC time parameter
  2014-02-12 18:54 [PATCH 1/4] cfg80211: regulatory, introduce DFS CAC time Janusz Dziedzic
@ 2014-02-12 18:54 ` Janusz Dziedzic
  0 siblings, 0 replies; 37+ messages in thread
From: Janusz Dziedzic @ 2014-02-12 18:54 UTC (permalink / raw)
  To: linux-wireless; +Cc: johannes, mcgrof, linville, Janusz Dziedzic

Introduce support for setting DFS CAC time
in milliseconds.

Eg.
(5250 - 5330 @ AUTO), (20), (60000), DFS

will setup CAC 60 seconds CAC time.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
 db2bin.py  |    6 +++---
 dbparse.py |   17 +++++++++++++----
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/db2bin.py b/db2bin.py
index 41d3741..f6c3bc1 100755
--- a/db2bin.py
+++ b/db2bin.py
@@ -7,7 +7,7 @@ from dbparse import DBParser
 import sys
 
 MAGIC = 0x52474442
-VERSION = 19
+VERSION = 20
 
 if len(sys.argv) < 3:
     print 'Usage: %s output-file input-file [key-file]' % sys.argv[0]
@@ -93,8 +93,8 @@ for reg_rule in rules:
     freq_range, power_rule = reg_rule.freqband, reg_rule.power
     reg_rules[reg_rule] = output.tell()
     # struct regdb_file_reg_rule
-    output.write(struct.pack('>III', freq_ranges[freq_range], power_rules[power_rule],
-                             reg_rule.flags))
+    output.write(struct.pack('>IIII', freq_ranges[freq_range], power_rules[power_rule],
+                             reg_rule.flags, reg_rule.cac_time))
 
 
 reg_rules_collections = {}
diff --git a/dbparse.py b/dbparse.py
index 7c7bc19..f79de2a 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -76,12 +76,13 @@ class FlagError(Exception):
         self.flag = flag
 
 class Permission(object):
-    def __init__(self, freqband, power, flags):
+    def __init__(self, freqband, power, flags, cac_time):
         assert isinstance(freqband, FreqBand)
         assert isinstance(power, PowerRestriction)
         self.freqband = freqband
         self.power = power
         self.flags = 0
+        self.cac_time = cac_time
         for flag in flags:
             if not flag in flag_definitions:
                 raise FlagError(flag)
@@ -89,7 +90,7 @@ class Permission(object):
         self.textflags = flags
 
     def _as_tuple(self):
-        return (self.freqband, self.power, self.flags)
+        return (self.freqband, self.power, self.flags, self.cac_time)
 
     def __cmp__(self, other):
         if not isinstance(other, Permission):
@@ -256,6 +257,7 @@ class DBParser(object):
         self._comments = []
 
     def _parse_country_item(self, line):
+        cac_time = 0
         if line[0] == '(':
             try:
                 band, line = line[1:].split('),', 1)
@@ -284,7 +286,14 @@ class DBParser(object):
                 flags = []
             else:
                 pname = items[0]
-                flags = items[1].split(',')
+                pcac = items[1]
+                if pcac[0] == '(':
+                    cac, flags = pcac.split('),', 1)
+                    flags = flags.split(',')
+                    cac_time = int(cac[1:])
+                else:
+                    flags = items[1].split(',')
+
             power = pname[1:]
             pname = 'UNNAMED %d' % self._lineno
             self._parse_power_def(pname, power, dupwarn=False)
@@ -305,7 +314,7 @@ class DBParser(object):
         b = self._bands[bname]
         p = self._power[pname]
         try:
-            perm = Permission(b, p, flags)
+            perm = Permission(b, p, flags, cac_time)
         except FlagError, e:
             self._syntax_error("Invalid flag '%s'" % e.flag)
         for cname, c in self._current_countries.iteritems():
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2014-06-10 16:47 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-09  8:40 [PATCH] wireless-regdb: add DFS CAC time parameter Janusz Dziedzic
2014-05-09  8:40 ` [wireless-regdb] " Janusz Dziedzic
2014-05-09  8:40 ` [PATCH] crda: add DFS CAC time support Janusz Dziedzic
2014-05-09  8:40   ` [wireless-regdb] " Janusz Dziedzic
2014-05-20  7:33 ` [PATCH] wireless-regdb: add DFS CAC time parameter Luis R. Rodriguez
2014-05-20  7:33   ` [wireless-regdb] " Luis R. Rodriguez
2014-05-20 13:26   ` Janusz Dziedzic
2014-05-20 13:26     ` [wireless-regdb] " Janusz Dziedzic
2014-05-20 14:24   ` John W. Linville
2014-05-20 14:24     ` [wireless-regdb] " John W. Linville
2014-05-20 18:01     ` Janusz Dziedzic
2014-05-20 18:01       ` [wireless-regdb] " Janusz Dziedzic
2014-05-20 18:08       ` John W. Linville
2014-05-20 18:08         ` [wireless-regdb] " John W. Linville
2014-05-20 18:24         ` Johannes Berg
2014-05-20 18:24           ` [wireless-regdb] " Johannes Berg
2014-05-20 18:48           ` Luis R. Rodriguez
2014-05-20 18:48             ` [wireless-regdb] " Luis R. Rodriguez
2014-05-21 16:03             ` Johannes Berg
2014-05-21 16:03               ` [wireless-regdb] " Johannes Berg
2014-05-21 18:00               ` John W. Linville
2014-05-21 18:00                 ` [wireless-regdb] " John W. Linville
2014-05-21 19:09                 ` Johannes Berg
2014-05-21 19:09                   ` [wireless-regdb] " Johannes Berg
2014-06-09  7:33                   ` Janusz Dziedzic
2014-06-09  7:33                     ` [wireless-regdb] " Janusz Dziedzic
2014-06-10 16:45                     ` Johannes Berg
2014-06-10 16:45                       ` [wireless-regdb] " Johannes Berg
2014-06-09  8:00               ` Felix Fietkau
2014-06-09  8:00                 ` [wireless-regdb] " Felix Fietkau
2014-06-09 10:22                 ` Janusz Dziedzic
2014-06-09 10:22                   ` [wireless-regdb] " Janusz Dziedzic
2014-06-09 12:27                   ` Janusz Dziedzic
2014-06-09 12:27                     ` [wireless-regdb] " Janusz Dziedzic
2014-06-10 16:46                 ` Johannes Berg
2014-06-10 16:46                   ` [wireless-regdb] " Johannes Berg
  -- strict thread matches above, loose matches on Subject: below --
2014-02-12 18:54 [PATCH 1/4] cfg80211: regulatory, introduce DFS CAC time Janusz Dziedzic
2014-02-12 18:54 ` [PATCH] wireless-regdb: add DFS CAC time parameter Janusz Dziedzic

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.