[RFC] First CRDA integration work

[RFC] First CRDA integration work

[Luis R. Rodriguez]

Release, review early. First work patch for integration of
CRDA work. Nukes old regulatory work, adds CRDA-like data structures
to cfg80211, adds a world regdom and uses it by default,
and start nl80211 definitions. The fun part, nl80211_get_reg()
and nl80211_set_reg() are pending. Hoping the second
shift <cough Johannes> can take over as I'm going to bed now.

At least it compiles, and should give an idea of where this is
going. This wasn't tested either :)

CRDA stuff can be checked out from:

git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git

For those who like diagrams:

http://wireless.kernel.org/crda.png

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 include/linux/nl80211.h |   88 +++++++++++++++++++++++++++-
 net/wireless/core.c     |   33 ++++++++++-
 net/wireless/core.h     |    1 +
 net/wireless/nl80211.c  |   33 ++++++++++
 net/wireless/reg.c      |  149 +++++++++++++++++------------------------------
 net/wireless/reg.h      |   56 ++++++++++++++++++
 6 files changed, 262 insertions(+), 98 deletions(-)
 create mode 100644 net/wireless/reg.h

diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index ea6517e..aa55eb4 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -90,6 +90,20 @@
  *	or, if no MAC address given, all mesh paths, on the interface identified
  *	by %NL80211_ATTR_IFINDEX.
  *
+ * @NL80211_CMD_GET_REG: Get current regulatory domain, this is a query 
+ * 	to the kernel wireless core, the wireless core returns currently
+ * 	set alpha2 by %NL80211_ATTR_REG_ALPHA2,.
+ * @NL80211_CMD_SET_REG: Set current regulatory domain. CRDA sets this after
+ * 	being queried by the kernel. CRDA replies by sending a regulatory domain
+ * 	structure which consists of %NL80211_ATTR_REG_ALPHA set to our current alpha2
+ * 	if it found a match. It also provides %NL80211_ATTR_REG_NUM,
+ * 	%NL80211_ATTR_REG_PGP_SIGNATURE_CHECK, and a regulatory rule. The regulatory
+ * 	rule consists of set of frequency ranges given by
+ * 	%NL80211_ATTR_REG_RULE_FREQ_[START|END] with an attached power rule given
+ * 	by %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and
+ * 	%NL80211_ATTR_REG_RULE_POWER_MAX_EIRP. Each regulatory rule also has 
+ * 	an attached %NL80211_ATTR_REG_RULE_FLAGS.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -129,6 +143,9 @@ enum nl80211_commands {
 	NL80211_CMD_NEW_MPATH,
 	NL80211_CMD_DEL_MPATH,
 
+	NL80211_CMD_GET_REG,
+	NL80211_CMD_SET_REG,
+
 	/* used to define NL80211_CMD_MAX below */
 	__NL80211_CMD_AFTER_LAST,
 	NL80211_CMD_MAX = __NL80211_CMD_AFTER_LAST - 1
@@ -188,10 +205,40 @@ enum nl80211_commands {
  * 	info given for %NL80211_CMD_GET_MPATH, nested attribute described at
  *	&enum nl80211_mpath_info.
  *
- *
  * @NL80211_ATTR_MNTR_FLAGS: flags, nested element with NLA_FLAG attributes of
  *      &enum nl80211_mntr_flags.
  *
+ * @NL80211_ATTR_REG_ALPHA2: an ISO-3166-alpha2 country code for which the
+ * 	current regulatory domain should be set to or is already set to.
+ * 	For example, 'CR', for Costa Rica. This attribute is used by the kernel
+ * 	to query the CRDA userspace agent to retrieve one regulatory domain.
+ * 	This attribute can also be used by userspace to query the kernel for
+ * 	the currently set regulatory domain.
+ * @NL80211_ATTR_REG_NUM_RULES: number of regulatory rules passed
+ * @NL80211_ATTR_REG_PGP_SIGNATURE_CHECK: whether or not CRDA has blessed
+ * 	this information through a PGP signature check. If its not blessed
+ * 	we go ahead and regulatory-taint the kernel. This is obviously
+ * 	hackable but the purpose is to allow distributions to be able to use
+ * 	a CRDA with a regulatory database signed off by the community
+ * 	and get the communities' blessing on this. Vendors can also
+ * 	support their own custom databases for custom solutions (AP, military).
+ * 	Start to shift liablity to the user, where it should be.
+ * @NL80211_ATTR_REG_RULE_FLAGS: a set of flags which specify additional
+ * 	considerations for a given frequency range. These are the
+ * 	&enum nl80211_reg_rule_flags.
+ * @NL80211_ATTR_REG_RULE_FREQ_START: starting frequencry for the regulatory
+ * 	rule in KHz. This is not a center of frequency but an actual regulatory
+ * 	band edge.
+ * @NL80211_ATTR_REG_RULE_FREQ_END: ending frequency for the regulatory rule
+ * 	in KHz. This is not a center a frequency but an actual regulatory
+ * 	band edge.
+ * @NL80211_ATTR_REG_RULE_FREQ_MAX_BW: maximum allowed bandwidth for this
+ * 	frequency range, in KHz.
+ * @NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN: the maximum allowed antenna gain
+ * 	for a given frequency range. The value is in mBi (100 * dBi).
+ * @NL80211_ATTR_REG_RULE_POWER_MAX_EIRP: the maximum allowed EIRP for
+ * 	a given frequency range. The value is in mBm (100 * dBm).
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -237,6 +284,16 @@ enum nl80211_attrs {
 	NL80211_ATTR_MPATH_NEXT_HOP,
 	NL80211_ATTR_MPATH_INFO,
 
+	NL80211_ATTR_REG_RULE_ALPHA2,
+	NL80211_ATTR_REG_RULE_NUM_RULES,
+	NL80211_ATTR_REG_PGP_SIGNATURE_CHECK,
+	NL80211_ATTR_REG_RULE_FREQ_START,
+	NL80211_ATTR_REG_RULE_FREQ_END,
+	NL80211_ATTR_REG_RULE_FREQ_MAX_BW,
+	NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN,
+	NL80211_ATTR_REG_RULE_POWER_MAX_EIRP,
+	NL80211_ATTR_REG_RULE_FLAGS,
+
 	__NL80211_ATTR_AFTER_LAST,
 	NL80211_ATTR_MAX = __NL80211_ATTR_AFTER_LAST - 1
 };
@@ -433,6 +490,35 @@ enum nl80211_bitrate_attr {
 };
 
 /**
+ * enum nl80211_reg_rule_flags - regulatory rule flags. These should match
+ * 	the latest regdb.h regulatory rule flags from CRDA.
+ *
+ * @NL80211_RRF_NO_OFDM: OFDM modulation not allowed
+ * @NL80211_RRF_NO_CCK: CCK modulation not allowed
+ * @NL80211_RRF_NO_INDOOR: indoor operation not allowed
+ * @NL80211_RRF_NO_OUTDOOR: outdoor operation not allowed
+ * @NL80211_RRF_DFS: DFS support is required to be used
+ * @NL80211_RRF_PTP_ONLY: this is only for Point To Point links
+ * @NL80211_RRF_PTMP_ONLY: this is only for Point To Multi Point links
+ * @NL80211_RRF_PASSIVE_SCAN: passive scan is required
+ * @NL80211_RRF_NO_IBSS: no IBSS is allowed
+ * @NL80211_RRF_NO_HT40: HT40 is not allowed
+ */
+enum nl80211_reg_rule_flags {
+	NL80211_RRF_NO_OFDM		= 1<<0,
+	NL80211_RRF_NO_CCK		= 1<<1,
+	NL80211_RRF_NO_INDOOR		= 1<<2,
+	NL80211_RRF_NO_OUTDOOR		= 1<<3,
+	NL80211_RRF_DFS			= 1<<4,
+	NL80211_RRF_PTP_ONLY		= 1<<4,
+	NL80211_RRF_PTMP_ONLY		= 1<<4,
+	NL80211_RRF_PASSIVE_SCAN	= 1<<4,
+	NL80211_RRF_NO_IBSS		= 1<<8,
+	/* hole at 9, used to be NO_HT20  */
+	NL80211_RRF_NO_HT40		= 1<<10,
+};
+
+/**
  * enum nl80211_mntr_flags - monitor configuration flags
  *
  * Monitor configuration flags.
diff --git a/net/wireless/core.c b/net/wireless/core.c
index f1da0b9..aeefc00 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -19,6 +19,7 @@
 #include "nl80211.h"
 #include "core.h"
 #include "sysfs.h"
+#include "reg.h"
 
 /* name for sysfs, %d is appended */
 #define PHY_NAME "phy"
@@ -27,6 +28,13 @@ MODULE_AUTHOR("Johannes Berg");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("wireless configuration support");
 
+/* Central wireless core regulatory domains, we only need two,
+ * the current one and a world regulatory domain in case we have no
+ * information to give us an alpha2 */
+const struct ieee80211_regdomain *cfg80211_regdomain;
+const struct ieee80211_regdomain *cfg80211_world_regdom;
+DEFINE_MUTEX(cfg80211_reg_mutex);
+
 /* RCU might be appropriate here since we usually
  * only read the list, and that can happen quite
  * often because we need to do it for each command */
@@ -402,9 +410,30 @@ static struct notifier_block cfg80211_netdev_notifier = {
 	.notifier_call = cfg80211_netdev_notifier_call,
 };
 
+
 static int cfg80211_init(void)
 {
-	int err = wiphy_sysfs_init();
+#define	PASSIVE_AND_NO_IBSS	RRF_PASSIVE_SCAN | RRF_NO_IBSS
+	int err;
+	static const struct ieee80211_regdomain world_regdom = {
+		.n_reg_rules = 7, /* I hope we can count */
+		.pgp_signature_check = 1, /* Duh, we're already here */
+		.alpha2 =  { '0', '0' }, /* Got any better ideas? */
+		.reg_rules = {
+			REG_RULE(2402, 2472, 40, 0, 20,	RRF_PASSIVE_SCAN),
+			REG_RULE(2474, 2494, 40, 0, 20,	PASSIVE_AND_NO_IBSS),
+			REG_RULE(5160, 5240, 40, 0, 30,	PASSIVE_AND_NO_IBSS),
+			REG_RULE(5250, 5330, 40, 0, 30, PASSIVE_AND_NO_IBSS),
+			REG_RULE(5735, 5835, 40, 0, 30, PASSIVE_AND_NO_IBSS),
+			REG_RULE(5490, 5710, 40, 0, 30, PASSIVE_AND_NO_IBSS),
+			REG_RULE(5490, 5710, 40, 0, 30, PASSIVE_AND_NO_IBSS)
+		}
+	};
+
+	cfg80211_regdomain = NULL;
+	cfg80211_world_regdom = (struct ieee80211_regdomain *) &world_regdom;
+
+	err = wiphy_sysfs_init();
 	if (err)
 		goto out_fail_sysfs;
 
@@ -426,7 +455,9 @@ out_fail_notifier:
 	wiphy_sysfs_exit();
 out_fail_sysfs:
 	return err;
+#undef	PASSIVE_AND_NO_IBSS
 }
+
 subsys_initcall(cfg80211_init);
 
 static void cfg80211_exit(void)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 7a02c35..a1af113 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -11,6 +11,7 @@
 #include <net/genetlink.h>
 #include <net/wireless.h>
 #include <net/cfg80211.h>
+#include "reg.h"
 
 struct cfg80211_registered_device {
 	struct cfg80211_ops *ops;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fb75f26..9659412 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -18,6 +18,7 @@
 #include <net/cfg80211.h>
 #include "core.h"
 #include "nl80211.h"
+#include "reg.h"
 
 /* the netlink family */
 static struct genl_family nl80211_fam = {
@@ -87,6 +88,16 @@ static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
 	[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
 				.len = IEEE80211_MAX_MESH_ID_LEN },
 	[NL80211_ATTR_MPATH_NEXT_HOP] = { .type = NLA_U32 },
+
+	[NL80211_ATTR_REG_RULE_ALPHA2] = { .type = NLA_NUL_STRING, .len = 3 },
+	[NL80211_ATTR_REG_RULE_NUM_RULES] = { .type = NLA_U32 },
+	[NL80211_ATTR_REG_PGP_SIGNATURE_CHECK] = { .type = NLA_U8 },
+	[NL80211_ATTR_REG_RULE_FREQ_START] = { .type = NLA_U32 },
+	[NL80211_ATTR_REG_RULE_FREQ_END] = { .type = NLA_U32 },
+	[NL80211_ATTR_REG_RULE_FREQ_MAX_BW] = { .type = NLA_U32 },
+	[NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN] = { .type = NLA_U32 },
+	[NL80211_ATTR_REG_RULE_POWER_MAX_EIRP] = { .type = NLA_U32 },
+	[NL80211_ATTR_REG_RULE_FLAGS] = { .type = NLA_U32 },
 };
 
 /* message building helper */
@@ -1492,6 +1503,16 @@ static int nl80211_del_mpath(struct sk_buff *skb, struct genl_info *info)
 	return err;
 }
 
+static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
+{
+	return -EOPNOTSUPP;
+}
+
+static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
+{
+	return -EOPNOTSUPP;
+}
+
 static struct genl_ops nl80211_ops[] = {
 	{
 		.cmd = NL80211_CMD_GET_WIPHY,
@@ -1623,6 +1644,18 @@ static struct genl_ops nl80211_ops[] = {
 		.policy = nl80211_policy,
 		.flags = GENL_ADMIN_PERM,
 	},
+	{
+		.cmd = NL80211_CMD_GET_REG,
+		.doit = nl80211_get_reg,
+		.policy = nl80211_policy,
+		.flags = GENL_ADMIN_PERM,
+	},
+	{
+		.cmd = NL80211_CMD_SET_REG,
+		.doit = nl80211_set_reg,
+		.policy = nl80211_policy,
+		.flags = GENL_ADMIN_PERM,
+	},
 };
 
 /* multicast groups */
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 185488d..13c9efc 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2,6 +2,7 @@
  * Copyright 2002-2005, Instant802 Networks, Inc.
  * Copyright 2005-2006, Devicescape Software, Inc.
  * Copyright 2007	Johannes Berg <johannes@sipsolutions.net>
+ * Copyright 2008	Luis R. Rodriguez <lrodriguz@atheros.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -9,137 +10,93 @@
  */
 
 /*
- * This regulatory domain control implementation is highly incomplete, it
- * only exists for the purpose of not regressing mac80211.
- *
- * For now, drivers can restrict the set of allowed channels by either
- * not registering those channels or setting the IEEE80211_CHAN_DISABLED
- * flag; that flag will only be *set* by this code, never *cleared.
- *
  * The usual implementation is for a driver to read a device EEPROM to
  * determine which regulatory domain it should be operating under, then
  * looking up the allowable channels in a driver-local table and finally
  * registering those channels in the wiphy structure.
  *
- * Alternatively, drivers that trust the regulatory domain control here
- * will register a complete set of capabilities and the control code
- * will restrict the set by setting the IEEE80211_CHAN_* flags.
+ * Another set of compliance enforcement is for drivers to use their
+ * own compliance limits which can be stored on the EEPROM. The host
+ * driver or firmware may ensure these are used.
+ *
+ * In addition to all this we provide an extra layer of regulatory
+ * compliance, however, that of what is provided by CRDA. This tries
+ * to ensure we remain complaint by not letting the user up front try
+ * to set their wireless device to settings we know we shouldn't be
+ * setting to. We also disable channels on the driver which we know we
+ * shouldn't be using in current regulatory domain. This is because
+ * some drivers may have outdated EEPROMs or no regulatory control at all.
+ *
  */
 #include <linux/kernel.h>
 #include <net/wireless.h>
 #include "core.h"
 
-static char *ieee80211_regdom = "US";
-module_param(ieee80211_regdom, charp, 0444);
-MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain code");
-
-struct ieee80211_channel_range {
-	short start_freq;
-	short end_freq;
-	int max_power;
-	int max_antenna_gain;
-	u32 flags;
-};
-
-struct ieee80211_regdomain {
-	const char *code;
-	const struct ieee80211_channel_range *ranges;
-	int n_ranges;
-};
-
-#define RANGE_PWR(_start, _end, _pwr, _ag, _flags)	\
-	{ _start, _end, _pwr, _ag, _flags }
-
-
-/*
- * Ideally, in the future, these definitions will be loaded from a
- * userspace table via some daemon.
- */
-static const struct ieee80211_channel_range ieee80211_US_channels[] = {
-	/* IEEE 802.11b/g, channels 1..11 */
-	RANGE_PWR(2412, 2462, 27, 6, 0),
-	/* IEEE 802.11a, channel 36*/
-	RANGE_PWR(5180, 5180, 23, 6, 0),
-	/* IEEE 802.11a, channel 40*/
-	RANGE_PWR(5200, 5200, 23, 6, 0),
-	/* IEEE 802.11a, channel 44*/
-	RANGE_PWR(5220, 5220, 23, 6, 0),
-	/* IEEE 802.11a, channels 48..64 */
-	RANGE_PWR(5240, 5320, 23, 6, 0),
-	/* IEEE 802.11a, channels 149..165, outdoor */
-	RANGE_PWR(5745, 5825, 30, 6, 0),
-};
-
-static const struct ieee80211_channel_range ieee80211_JP_channels[] = {
-	/* IEEE 802.11b/g, channels 1..14 */
-	RANGE_PWR(2412, 2484, 20, 6, 0),
-	/* IEEE 802.11a, channels 34..48 */
-	RANGE_PWR(5170, 5240, 20, 6, IEEE80211_CHAN_PASSIVE_SCAN),
-	/* IEEE 802.11a, channels 52..64 */
-	RANGE_PWR(5260, 5320, 20, 6, IEEE80211_CHAN_NO_IBSS |
-				     IEEE80211_CHAN_RADAR),
-};
-
-#define REGDOM(_code)							\
-	{								\
-		.code = __stringify(_code),				\
-		.ranges = ieee80211_ ##_code## _channels,		\
-		.n_ranges = ARRAY_SIZE(ieee80211_ ##_code## _channels),	\
-	}
-
-static const struct ieee80211_regdomain ieee80211_regdoms[] = {
-	REGDOM(US),
-	REGDOM(JP),
-};
-
-
 static const struct ieee80211_regdomain *get_regdom(void)
 {
-	static const struct ieee80211_channel_range
-	ieee80211_world_channels[] = {
-		/* IEEE 802.11b/g, channels 1..11 */
-		RANGE_PWR(2412, 2462, 27, 6, 0),
-	};
-	static const struct ieee80211_regdomain regdom_world = REGDOM(world);
-	int i;
+	/* XXX: Query CRDA and if we don't get a response or if we don't get a
+	 * response for a specific alpha2 then use world_regdom */
 
-	for (i = 0; i < ARRAY_SIZE(ieee80211_regdoms); i++)
-		if (strcmp(ieee80211_regdom, ieee80211_regdoms[i].code) == 0)
-			return &ieee80211_regdoms[i];
+	/* use world_regdom for now to test this */
+	return cfg80211_world_regdom;
+}
 
-	return &regdom_world;
+static int freq_in_range(const struct ieee80211_freq_range *freq_range, u32 freq)
+{
+	if (freq >= freq_range->start_freq &&
+		freq <= freq_range->end_freq)
+		return 1;
+	return 0;
 }
 
+/* XXX: map the rest, add the rest  */
+static u32 map_regdom_flags(u32 rd_flags) {
+	u32 channel_flags = 0;
+	if (rd_flags & RRF_PASSIVE_SCAN)
+		channel_flags |= IEEE80211_CHAN_PASSIVE_SCAN;
+	if (rd_flags & RRF_NO_IBSS)
+		channel_flags |= IEEE80211_CHAN_NO_IBSS;
+	if (rd_flags & RRF_DFS)
+		channel_flags |= IEEE80211_CHAN_RADAR;
+	return channel_flags;
+}
 
 static void handle_channel(struct ieee80211_channel *chan,
 			   const struct ieee80211_regdomain *rd)
 {
 	int i;
 	u32 flags = chan->orig_flags;
-	const struct ieee80211_channel_range *rg = NULL;
-
-	for (i = 0; i < rd->n_ranges; i++) {
-		if (rd->ranges[i].start_freq <= chan->center_freq &&
-		    chan->center_freq <= rd->ranges[i].end_freq) {
-			rg = &rd->ranges[i];
+	const struct ieee80211_reg_rule *reg_rule = NULL;
+	const struct ieee80211_power_rule *power_rule = NULL;
+
+	for (i = 0; i < rd->n_reg_rules; i++) {
+		const struct ieee80211_reg_rule *rr;
+		const struct ieee80211_freq_range *fr = NULL;
+		const struct ieee80211_power_rule *pr = NULL;
+		rr = &rd->reg_rules[i];
+		fr = &rr->freq_range;
+		pr = &rr->power_rule;
+		if (freq_in_range(fr, chan->center_freq * 100)) {
+			reg_rule = rr;
+			power_rule = &rr->power_rule;
 			break;
 		}
 	}
 
-	if (!rg) {
+	if (!reg_rule) {
 		/* not found */
 		flags |= IEEE80211_CHAN_DISABLED;
 		chan->flags = flags;
 		return;
 	}
 
-	chan->flags = flags;
+	chan->flags = map_regdom_flags(reg_rule->flags);
 	chan->max_antenna_gain = min(chan->orig_mag,
-					 rg->max_antenna_gain);
+					 (int) power_rule->max_antenna_gain);
 	if (chan->orig_mpwr)
-		chan->max_power = min(chan->orig_mpwr, rg->max_power);
+		chan->max_power = min(chan->orig_mpwr, (int) power_rule->max_eirp);
 	else
-		chan->max_power = rg->max_power;
+		chan->max_power = power_rule->max_eirp;
 }
 
 static void handle_band(struct ieee80211_supported_band *sband,
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
new file mode 100644
index 0000000..d1e7d6e
--- /dev/null
+++ b/net/wireless/reg.h
@@ -0,0 +1,56 @@
+#ifndef __NET_WIRELESS_REG_H
+#define __NET_WIRELESS_REG_H
+
+extern const struct ieee80211_regdomain *cfg80211_regdomain;
+extern const struct ieee80211_regdomain *cfg80211_world_regdom;
+
+struct ieee80211_freq_range {
+	u32 start_freq;
+	u32 end_freq;
+	u32 max_bandwidth;
+};
+
+struct ieee80211_power_rule {
+	u32 max_antenna_gain;
+	u32 max_eirp;
+};
+
+/* These must match CRDA regdb.h reg_rule_flags. nl80211
+ * must also be synced. */
+enum reg_rule_flags {
+	RRF_NO_OFDM             = 1<<0,
+	RRF_NO_CCK              = 1<<1,
+	RRF_NO_INDOOR           = 1<<2,
+	RRF_NO_OUTDOOR          = 1<<3,
+	RRF_DFS                 = 1<<4,
+	RRF_PTP_ONLY            = 1<<5,
+	RRF_PTMP_ONLY           = 1<<6,
+	RRF_PASSIVE_SCAN        = 1<<7,
+	RRF_NO_IBSS             = 1<<8,
+	/* hole at 9 */
+	RRF_NO_HT40             = 1<<10,
+};
+
+struct ieee80211_reg_rule {
+	struct ieee80211_freq_range freq_range;
+	struct ieee80211_power_rule power_rule;
+	u32 flags;
+};
+
+struct ieee80211_regdomain {
+	u32 n_reg_rules;
+	int pgp_signature_check;
+	char alpha2[2];
+	struct ieee80211_reg_rule reg_rules[];
+};
+
+#define REG_RULE(start, end, bw, gain, eirp, reg_flags) { \
+	.freq_range.start_freq = start * 100, \
+	.freq_range.end_freq = end * 100, \
+	.freq_range.max_bandwidth = bw, \
+	.power_rule.max_antenna_gain = gain, \
+	.power_rule.max_eirp = eirp, \
+	.flags = reg_flags, \
+	}
+
+#endif  /* __NET_WIRELESS_REG_H */
-- 
1.5.4.3

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Tue, Jun 10, 2008 at 9:04 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
>
> Release, review early. First work patch for integration of
> CRDA work. Nukes old regulatory work, adds CRDA-like data structures
> to cfg80211, adds a world regdom and uses it by default,
> and start nl80211 definitions. The fun part, nl80211_get_reg()
> and nl80211_set_reg() are pending. Hoping the second
> shift <cough Johannes> can take over as I'm going to bed now.
>
> At least it compiles, and should give an idea of where this is
> going. This wasn't tested either :)
>
> CRDA stuff can be checked out from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git
>
> For those who like diagrams:
>
> http://wireless.kernel.org/crda.png

OK well it doesn't crash, lucky me. I'm on it now.

Also credit where its due: Thanks to Johannes for whipping up the
userspace API really quickly and so well :) Not to mention already
having set up mac80211 to make this patch easy :)

  Luis

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Wed, Jun 11, 2008 at 3:29 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Tue, Jun 10, 2008 at 9:04 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>>
>> Release, review early. First work patch for integration of
>> CRDA work. Nukes old regulatory work, adds CRDA-like data structures
>> to cfg80211, adds a world regdom and uses it by default,
>> and start nl80211 definitions. The fun part, nl80211_get_reg()
>> and nl80211_set_reg() are pending. Hoping the second
>> shift <cough Johannes> can take over as I'm going to bed now.
>>
>> At least it compiles, and should give an idea of where this is
>> going. This wasn't tested either :)
>>
>> CRDA stuff can be checked out from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git
>>
>> For those who like diagrams:
>>
>> http://wireless.kernel.org/crda.png
>
> OK well it doesn't crash, lucky me. I'm on it now.
>
> Also credit where its due: Thanks to Johannes for whipping up the
> userspace API really quickly and so well :) Not to mention already
> having set up mac80211 to make this patch easy :)

OK some issues: we don't handle yet the case where
power_rule->max_antenna_gain is 0 which is designed to mean "Not
available" in those cases the original antenna gain of the channel
(set by the EEPROM mapping for example) should be left alone.

Now for the netlink hooks and CRDA to query back.

  Luis

Re: [RFC] First CRDA integration work

[Johannes Berg]

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


> + * @NL80211_CMD_GET_REG: Get current regulatory domain, this is a query 
> + * 	to the kernel wireless core, the wireless core returns currently
> + * 	set alpha2 by %NL80211_ATTR_REG_ALPHA2,.

Please specify what command it comes in, probably _NEW_REG that you
haven't added.

> + * @NL80211_CMD_SET_REG: Set current regulatory domain. CRDA sets this after
                                                                sends

> + * 	being queried by the kernel.

How?

>  CRDA replies by sending a regulatory domain
> + * 	structure which consists of %NL80211_ATTR_REG_ALPHA set to our current alpha2
> + * 	if it found a match.

Why set the alpha2 again? I thought the kernel queried for that?

>  It also provides %NL80211_ATTR_REG_NUM,

What is that for?

> + * 	%NL80211_ATTR_REG_PGP_SIGNATURE_CHECK,

It's not PGP either way, and why is that required in the kernel?

>  and a regulatory rule. The regulatory
> + * 	rule consists of set of frequency ranges given by
> + * 	%NL80211_ATTR_REG_RULE_FREQ_[START|END] with an attached power rule given
> + * 	by %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and
> + * 	%NL80211_ATTR_REG_RULE_POWER_MAX_EIRP. Each regulatory rule also has 
> + * 	an attached %NL80211_ATTR_REG_RULE_FLAGS.

How are these attributes used? Nested in some array?

> + * @NL80211_ATTR_REG_ALPHA2: an ISO-3166-alpha2 country code for which the
> + * 	current regulatory domain should be set to or is already set to.
> + * 	For example, 'CR', for Costa Rica.

Heh :)

>  This attribute is used by the kernel
> + * 	to query the CRDA userspace agent to retrieve one regulatory domain.
> + * 	This attribute can also be used by userspace to query the kernel for
> + * 	the currently set regulatory domain.

???

> + * @NL80211_ATTR_REG_NUM_RULES: number of regulatory rules passed

Not necessary.

> + * @NL80211_ATTR_REG_PGP_SIGNATURE_CHECK: whether or not CRDA has blessed
> + * 	this information through a PGP signature check. If its not blessed
> + * 	we go ahead and regulatory-taint the kernel. This is obviously
> + * 	hackable but the purpose is to allow distributions to be able to use
> + * 	a CRDA with a regulatory database signed off by the community
> + * 	and get the communities' blessing on this. Vendors can also
> + * 	support their own custom databases for custom solutions (AP, military).
> + * 	Start to shift liablity to the user, where it should be.

Not PGP. It's just an RSA signature. If liability is at the user, why do
we need to know this in the kernel?

> + * @NL80211_ATTR_REG_RULE_FLAGS: a set of flags which specify additional
> + * 	considerations for a given frequency range. These are the
> + * 	&enum nl80211_reg_rule_flags.

Should we use flag attributes here nested into something? That would be
more netlink-like and allow easier expansion above 32 should it become
necessary.

> + * @NL80211_ATTR_REG_RULE_FREQ_START: starting frequencry for the regulatory
> + * 	rule in KHz. This is not a center of frequency but an actual regulatory
                                            ^^ remove
> + * 	band edge.
> + * @NL80211_ATTR_REG_RULE_FREQ_END: ending frequency for the regulatory rule
> + * 	in KHz. This is not a center a frequency but an actual regulatory
                                       ^^ remove
> + * 	band edge.
> + * @NL80211_ATTR_REG_RULE_FREQ_MAX_BW: maximum allowed bandwidth for this
> + * 	frequency range, in KHz.
> + * @NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN: the maximum allowed antenna gain
> + * 	for a given frequency range. The value is in mBi (100 * dBi).

Can be left out.

> +/* Central wireless core regulatory domains, we only need two,
> + * the current one and a world regulatory domain in case we have no
> + * information to give us an alpha2 */
> +const struct ieee80211_regdomain *cfg80211_regdomain;

const?

> +const struct ieee80211_regdomain *cfg80211_world_regdom;
> +DEFINE_MUTEX(cfg80211_reg_mutex);
> +
>  /* RCU might be appropriate here since we usually
>   * only read the list, and that can happen quite
>   * often because we need to do it for each command */
> @@ -402,9 +410,30 @@ static struct notifier_block cfg80211_netdev_notifier = {
>  	.notifier_call = cfg80211_netdev_notifier_call,
>  };
>  
> +
>  static int cfg80211_init(void)
>  {
> -	int err = wiphy_sysfs_init();
> +#define	PASSIVE_AND_NO_IBSS	RRF_PASSIVE_SCAN | RRF_NO_IBSS
> +	int err;
> +	static const struct ieee80211_regdomain world_regdom = {
> +		.n_reg_rules = 7, /* I hope we can count */

ARRAY_SIZE() helps you count.

> +		.pgp_signature_check = 1, /* Duh, we're already here */
> +		.alpha2 =  { '0', '0' }, /* Got any better ideas? */

"\0\0" so we can't actually ever use this manually?

> +		.reg_rules = {
> +			REG_RULE(2402, 2472, 40, 0, 20,	RRF_PASSIVE_SCAN),
> +			REG_RULE(2474, 2494, 40, 0, 20,	PASSIVE_AND_NO_IBSS),
> +			REG_RULE(5160, 5240, 40, 0, 30,	PASSIVE_AND_NO_IBSS),
> +			REG_RULE(5250, 5330, 40, 0, 30, PASSIVE_AND_NO_IBSS),
> +			REG_RULE(5735, 5835, 40, 0, 30, PASSIVE_AND_NO_IBSS),
> +			REG_RULE(5490, 5710, 40, 0, 30, PASSIVE_AND_NO_IBSS),
> +			REG_RULE(5490, 5710, 40, 0, 30, PASSIVE_AND_NO_IBSS)
> +		}
> +	};

#undef PASSIVE_AND_NOIBSS

why not declare this statically in the file rather than statically in
the init function?

> +	cfg80211_regdomain = NULL;
> +	cfg80211_world_regdom = (struct ieee80211_regdomain *) &world_regdom;

What's with the cast?

> --- a/net/wireless/core.h
> +++ b/net/wireless/core.h
> @@ -11,6 +11,7 @@
>  #include <net/genetlink.h>
>  #include <net/wireless.h>
>  #include <net/cfg80211.h>
> +#include "reg.h"

Hmm?
 
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -18,6 +18,7 @@
>  #include <net/cfg80211.h>
>  #include "core.h"
>  #include "nl80211.h"
> +#include "reg.h"
>  
>  /* the netlink family */
>  static struct genl_family nl80211_fam = {
> @@ -87,6 +88,16 @@ static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
>  	[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
>  				.len = IEEE80211_MAX_MESH_ID_LEN },
>  	[NL80211_ATTR_MPATH_NEXT_HOP] = { .type = NLA_U32 },
> +
> +	[NL80211_ATTR_REG_RULE_ALPHA2] = { .type = NLA_NUL_STRING, .len = 3 },

Why does it have to be a NUL-string? It is always only two bytes, so
please just do that. No need to null-terminate.

> +static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
> +static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
> +{
> +	return -EOPNOTSUPP;
> +}

-ECODEMISSING :P

> @@ -9,137 +10,93 @@
>   */
>  
>  /*
> - * This regulatory domain control implementation is highly incomplete, it
> - * only exists for the purpose of not regressing mac80211.
> - *
> - * For now, drivers can restrict the set of allowed channels by either
> - * not registering those channels or setting the IEEE80211_CHAN_DISABLED
> - * flag; that flag will only be *set* by this code, never *cleared.
> - *
>   * The usual implementation is for a driver to read a device EEPROM to
>   * determine which regulatory domain it should be operating under, then
>   * looking up the allowable channels in a driver-local table and finally
>   * registering those channels in the wiphy structure.
>   *
> - * Alternatively, drivers that trust the regulatory domain control here
> - * will register a complete set of capabilities and the control code
> - * will restrict the set by setting the IEEE80211_CHAN_* flags.

I think you shouldn't remove that but just rewrite it to make the driver
trust crda instead of this code.

> + * Another set of compliance enforcement is for drivers to use their
> + * own compliance limits which can be stored on the EEPROM. The host
> + * driver or firmware may ensure these are used.
> + *
> + * In addition to all this we provide an extra layer of regulatory
> + * compliance, however, that of what is provided by CRDA. This tries
> + * to ensure we remain complaint by not letting the user up front try
                          ^^^^^^^^^ heh

> + * to set their wireless device to settings we know we shouldn't be
> + * setting to. We also disable channels on the driver which we know we
> + * shouldn't be using in current regulatory domain. This is because
> + * some drivers may have outdated EEPROMs or no regulatory control at all.


> +static int freq_in_range(const struct ieee80211_freq_range *freq_range, u32 freq)
> +{
> +	if (freq >= freq_range->start_freq &&
> +		freq <= freq_range->end_freq)
> +		return 1;
> +	return 0;
>  }

That needs a bandwidth check I think.
 
> +++ b/net/wireless/reg.h
> @@ -0,0 +1,56 @@
> +#ifndef __NET_WIRELESS_REG_H
> +#define __NET_WIRELESS_REG_H
> +
> +extern const struct ieee80211_regdomain *cfg80211_regdomain;
> +extern const struct ieee80211_regdomain *cfg80211_world_regdom;
> +
> +struct ieee80211_freq_range {
> +	u32 start_freq;
> +	u32 end_freq;
> +	u32 max_bandwidth;
> +};
> +
> +struct ieee80211_power_rule {
> +	u32 max_antenna_gain;
> +	u32 max_eirp;
> +};
> +
> +/* These must match CRDA regdb.h reg_rule_flags. nl80211
> + * must also be synced. */

I think we should use the internal flags directly in nl80211 and have
nl80211 use flag-attributes in a nested flags attribute (see how monitor
flags work) and not rely on any shared bit meanings with userspace.

> +struct ieee80211_reg_rule {
> +	struct ieee80211_freq_range freq_range;
> +	struct ieee80211_power_rule power_rule;
> +	u32 flags;
> +};
> +
> +struct ieee80211_regdomain {
> +	u32 n_reg_rules;
> +	int pgp_signature_check;
> +	char alpha2[2];
> +	struct ieee80211_reg_rule reg_rules[];

Make that a pointer instead so we can declare the array and point to it
and use ARRAY_SIZE().

johannes

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

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Thu, Jun 12, 2008 at 01:41:46AM -0700, Johannes Berg wrote:
> 
> > + * @NL80211_CMD_GET_REG: Get current regulatory domain, this is a query 
> > + * 	to the kernel wireless core, the wireless core returns currently
> > + * 	set alpha2 by %NL80211_ATTR_REG_ALPHA2,.
> 
> Please specify what command it comes in, probably _NEW_REG that you
> haven't added.

We can probably not even add this, what do you think?

> > + * @NL80211_CMD_SET_REG: Set current regulatory domain. CRDA sets this after
>                                                                 sends
> 
> > + * 	being queried by the kernel.
> 
> How?

This should be the CMD_NEW_REG then, I called it "SET" as we can only
set one regulatory domain. Let me know your preference.

> >  CRDA replies by sending a regulatory domain
> > + * 	structure which consists of %NL80211_ATTR_REG_ALPHA set to our current alpha2
> > + * 	if it found a match.
> 
> Why set the alpha2 again? I thought the kernel queried for that?

This is in case we wanted to support letting userspace query the kernel
what alpha2 it has set. I'm OK with not supporting this though but it
seemed it may have come in handy, hopefully not for abuse for other
things.

> >  It also provides %NL80211_ATTR_REG_NUM,
> 
> What is that for?

The number of reg rules for the current regdomain. We'd convert the
array or reg rules structs to an number of attributes we are sure to
receive. The alternative I think is to pass all the data into a _DATA
type and let us parse it ourselves. I'm not sure, what do you think?

I was thinking something like this:

If NL80211_ATTR_REG_NUM == 3

Then the nested attributes will be packed like this:

reg-rule	Attribute
-----------------------------------------------------------
1		NL80211_ATTR_REG_RULE_FLAGS
1		NL80211_ATTR_REG_RULE_FREQ_START
1		NL80211_ATTR_REG_RULE_FREQ_END
1		NL80211_ATTR_REG_RULE_FREQ_MAX_BW
1		NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN
1		NL80211_ATTR_REG_RULE_POWER_MAX_EIRP

2		NL80211_ATTR_REG_RULE_FLAGS
2		NL80211_ATTR_REG_RULE_FREQ_START
2		NL80211_ATTR_REG_RULE_FREQ_END
2		NL80211_ATTR_REG_RULE_FREQ_MAX_BW
2		NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN
2		NL80211_ATTR_REG_RULE_POWER_MAX_EIRP

3		NL80211_ATTR_REG_RULE_FLAGS
3		NL80211_ATTR_REG_RULE_FREQ_START
3		NL80211_ATTR_REG_RULE_FREQ_END
3		NL80211_ATTR_REG_RULE_FREQ_MAX_BW
3		NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN
3		NL80211_ATTR_REG_RULE_POWER_MAX_EIRP
-----------------------------------------------------------

I wanted your input on this. Not sure what is best. Pleas recommend a
format.

> > + * 	%NL80211_ATTR_REG_PGP_SIGNATURE_CHECK,
> 
> It's not PGP either way, 

Excuse my crypto-fu :)

> and why is that required in the kernel?

I don't have strong reasons for this anymore. We can ignore it.

> >  and a regulatory rule. The regulatory
> > + * 	rule consists of set of frequency ranges given by
> > + * 	%NL80211_ATTR_REG_RULE_FREQ_[START|END] with an attached power rule given
> > + * 	by %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and
> > + * 	%NL80211_ATTR_REG_RULE_POWER_MAX_EIRP. Each regulatory rule also has 
> > + * 	an attached %NL80211_ATTR_REG_RULE_FLAGS.
> 
> How are these attributes used? Nested in some array?

I wasn't sure yet, I wanted your feedback, but you are giving me this
through IRC :)

> > + * @NL80211_ATTR_REG_ALPHA2: an ISO-3166-alpha2 country code for which the
> > + * 	current regulatory domain should be set to or is already set to.
> > + * 	For example, 'CR', for Costa Rica.
> 
> Heh :)
> 
> >  This attribute is used by the kernel
> > + * 	to query the CRDA userspace agent to retrieve one regulatory domain.
> > + * 	This attribute can also be used by userspace to query the kernel for
> > + * 	the currently set regulatory domain.
> 
> ???

OK well I haven't figured out how the kernel->CRDA communication would
work yet. CRDA->kernel is nl80211. You can ignore this for now.

> > + * @NL80211_ATTR_REG_NUM_RULES: number of regulatory rules passed
> 
> Not necessary.

OK.

> > + * @NL80211_ATTR_REG_PGP_SIGNATURE_CHECK: whether or not CRDA has blessed
> > + * 	this information through a PGP signature check. If its not blessed
> > + * 	we go ahead and regulatory-taint the kernel. This is obviously
> > + * 	hackable but the purpose is to allow distributions to be able to use
> > + * 	a CRDA with a regulatory database signed off by the community
> > + * 	and get the communities' blessing on this. Vendors can also
> > + * 	support their own custom databases for custom solutions (AP, military).
> > + * 	Start to shift liablity to the user, where it should be.
> 
> Not PGP. It's just an RSA signature. If liability is at the user, why do
> we need to know this in the kernel?

The original idea was to let vendors decide to be able to ignore or not
bug reports (oops) if the kernel was reguluatory tainted. But since we
are using EEPROM data we're OK without this data. It may be desirable
but I can't think of a strong reason behind this anymore.

> > + * @NL80211_ATTR_REG_RULE_FLAGS: a set of flags which specify additional
> > + * 	considerations for a given frequency range. These are the
> > + * 	&enum nl80211_reg_rule_flags.
> 
> Should we use flag attributes here nested into something? That would be
> more netlink-like and allow easier expansion above 32 should it become
> necessary.

OK.

> > + * @NL80211_ATTR_REG_RULE_FREQ_START: starting frequencry for the regulatory
> > + * 	rule in KHz. This is not a center of frequency but an actual regulatory
>                                             ^^ remove
> > + * 	band edge.
> > + * @NL80211_ATTR_REG_RULE_FREQ_END: ending frequency for the regulatory rule
> > + * 	in KHz. This is not a center a frequency but an actual regulatory
>                                        ^^ remove
> > + * 	band edge.
> > + * @NL80211_ATTR_REG_RULE_FREQ_MAX_BW: maximum allowed bandwidth for this
> > + * 	frequency range, in KHz.
> > + * @NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN: the maximum allowed antenna gain
> > + * 	for a given frequency range. The value is in mBi (100 * dBi).
> 
> Can be left out.

OK.

> > +/* Central wireless core regulatory domains, we only need two,
> > + * the current one and a world regulatory domain in case we have no
> > + * information to give us an alpha2 */
> > +const struct ieee80211_regdomain *cfg80211_regdomain;
> 
> const?

Ignore that.

> > +const struct ieee80211_regdomain *cfg80211_world_regdom;
> > +DEFINE_MUTEX(cfg80211_reg_mutex);
> > +
> >  /* RCU might be appropriate here since we usually
> >   * only read the list, and that can happen quite
> >   * often because we need to do it for each command */
> > @@ -402,9 +410,30 @@ static struct notifier_block cfg80211_netdev_notifier = {
> >  	.notifier_call = cfg80211_netdev_notifier_call,
> >  };
> >  
> > +
> >  static int cfg80211_init(void)
> >  {
> > -	int err = wiphy_sysfs_init();
> > +#define	PASSIVE_AND_NO_IBSS	RRF_PASSIVE_SCAN | RRF_NO_IBSS
> > +	int err;
> > +	static const struct ieee80211_regdomain world_regdom = {
> > +		.n_reg_rules = 7, /* I hope we can count */
> 
> ARRAY_SIZE() helps you count.

the # of rules isn't defined yet in this implementation.

> > +		.pgp_signature_check = 1, /* Duh, we're already here */
> > +		.alpha2 =  { '0', '0' }, /* Got any better ideas? */
> 
> "\0\0" so we can't actually ever use this manually?

OK.

> > +		.reg_rules = {
> > +			REG_RULE(2402, 2472, 40, 0, 20,	RRF_PASSIVE_SCAN),
> > +			REG_RULE(2474, 2494, 40, 0, 20,	PASSIVE_AND_NO_IBSS),
> > +			REG_RULE(5160, 5240, 40, 0, 30,	PASSIVE_AND_NO_IBSS),
> > +			REG_RULE(5250, 5330, 40, 0, 30, PASSIVE_AND_NO_IBSS),
> > +			REG_RULE(5735, 5835, 40, 0, 30, PASSIVE_AND_NO_IBSS),
> > +			REG_RULE(5490, 5710, 40, 0, 30, PASSIVE_AND_NO_IBSS),
> > +			REG_RULE(5490, 5710, 40, 0, 30, PASSIVE_AND_NO_IBSS)
> > +		}
> > +	};
> 
> #undef PASSIVE_AND_NOIBSS
> 
> why not declare this statically in the file rather than statically in
> the init function?

OK.

> > +	cfg80211_regdomain = NULL;
> > +	cfg80211_world_regdom = (struct ieee80211_regdomain *) &world_regdom;
> 
> What's with the cast?

Compiler was bitching. But it may have been previous to some changes I
made.

> > --- a/net/wireless/core.h
> > +++ b/net/wireless/core.h
> > @@ -11,6 +11,7 @@
> >  #include <net/genetlink.h>
> >  #include <net/wireless.h>
> >  #include <net/cfg80211.h>
> > +#include "reg.h"
> 
> Hmm?

Not needed, right.

> > --- a/net/wireless/nl80211.c
> > +++ b/net/wireless/nl80211.c
> > @@ -18,6 +18,7 @@
> >  #include <net/cfg80211.h>
> >  #include "core.h"
> >  #include "nl80211.h"
> > +#include "reg.h"
> >  
> >  /* the netlink family */
> >  static struct genl_family nl80211_fam = {
> > @@ -87,6 +88,16 @@ static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
> >  	[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
> >  				.len = IEEE80211_MAX_MESH_ID_LEN },
> >  	[NL80211_ATTR_MPATH_NEXT_HOP] = { .type = NLA_U32 },
> > +
> > +	[NL80211_ATTR_REG_RULE_ALPHA2] = { .type = NLA_NUL_STRING, .len = 3 },
> 
> Why does it have to be a NUL-string? It is always only two bytes, so
> please just do that. No need to null-terminate.

Sure.

> > +static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
> > +{
> > +	return -EOPNOTSUPP;
> > +}
> > +
> > +static int nl80211_set_reg(struct sk_buff *skb, struct genl_info *info)
> > +{
> > +	return -EOPNOTSUPP;
> > +}
> 
> -ECODEMISSING :P

Yeah yeah. Hence "early" relase.

> > @@ -9,137 +10,93 @@
> >   */
> >  
> >  /*
> > - * This regulatory domain control implementation is highly incomplete, it
> > - * only exists for the purpose of not regressing mac80211.
> > - *
> > - * For now, drivers can restrict the set of allowed channels by either
> > - * not registering those channels or setting the IEEE80211_CHAN_DISABLED
> > - * flag; that flag will only be *set* by this code, never *cleared.
> > - *
> >   * The usual implementation is for a driver to read a device EEPROM to
> >   * determine which regulatory domain it should be operating under, then
> >   * looking up the allowable channels in a driver-local table and finally
> >   * registering those channels in the wiphy structure.
> >   *
> > - * Alternatively, drivers that trust the regulatory domain control here
> > - * will register a complete set of capabilities and the control code
> > - * will restrict the set by setting the IEEE80211_CHAN_* flags.
> 
> I think you shouldn't remove that but just rewrite it to make the driver
> trust crda instead of this code.

The EEPROM lets us get a list of supported channels for a product a
customer (a vendor's customer, not a regular customer) decided to support.
If we trust CRDA we then could potentially trust a different set of channels
which the customer may not have tested his products on. They probably
will work, but the safer approach is to support only the intended
channels.

We can then trust CRDA only to disable channels, not to *enable*.

> > + * Another set of compliance enforcement is for drivers to use their
> > + * own compliance limits which can be stored on the EEPROM. The host
> > + * driver or firmware may ensure these are used.
> > + *
> > + * In addition to all this we provide an extra layer of regulatory
> > + * compliance, however, that of what is provided by CRDA. This tries
> > + * to ensure we remain complaint by not letting the user up front try
>                           ^^^^^^^^^ heh

Thanks.

> > + * to set their wireless device to settings we know we shouldn't be
> > + * setting to. We also disable channels on the driver which we know we
> > + * shouldn't be using in current regulatory domain. This is because
> > + * some drivers may have outdated EEPROMs or no regulatory control at all.
> 
> 
> > +static int freq_in_range(const struct ieee80211_freq_range *freq_range, u32 freq)
> > +{
> > +	if (freq >= freq_range->start_freq &&
> > +		freq <= freq_range->end_freq)
> > +		return 1;
> > +	return 0;
> >  }
> 
> That needs a bandwidth check I think.

Thanks.

> > +++ b/net/wireless/reg.h
> > @@ -0,0 +1,56 @@
> > +#ifndef __NET_WIRELESS_REG_H
> > +#define __NET_WIRELESS_REG_H
> > +
> > +extern const struct ieee80211_regdomain *cfg80211_regdomain;
> > +extern const struct ieee80211_regdomain *cfg80211_world_regdom;
> > +
> > +struct ieee80211_freq_range {
> > +	u32 start_freq;
> > +	u32 end_freq;
> > +	u32 max_bandwidth;
> > +};
> > +
> > +struct ieee80211_power_rule {
> > +	u32 max_antenna_gain;
> > +	u32 max_eirp;
> > +};
> > +
> > +/* These must match CRDA regdb.h reg_rule_flags. nl80211
> > + * must also be synced. */
> 
> I think we should use the internal flags directly in nl80211 and have
> nl80211 use flag-attributes in a nested flags attribute (see how monitor
> flags work) and not rely on any shared bit meanings with userspace.

Sounds good to me.

> > +struct ieee80211_reg_rule {
> > +	struct ieee80211_freq_range freq_range;
> > +	struct ieee80211_power_rule power_rule;
> > +	u32 flags;
> > +};
> > +
> > +struct ieee80211_regdomain {
> > +	u32 n_reg_rules;
> > +	int pgp_signature_check;
> > +	char alpha2[2];
> > +	struct ieee80211_reg_rule reg_rules[];
> 
> Make that a pointer instead so we can declare the array and point to it
> and use ARRAY_SIZE().

Alright.

  Luis

Re: [RFC] First CRDA integration work

[Johannes Berg]

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


> > > + * @NL80211_CMD_GET_REG: Get current regulatory domain, this is a query 
> > > + * 	to the kernel wireless core, the wireless core returns currently
> > > + * 	set alpha2 by %NL80211_ATTR_REG_ALPHA2,.
> > 
> > Please specify what command it comes in, probably _NEW_REG that you
> > haven't added.
> 
> We can probably not even add this, what do you think?

Well I think that some userspace programs like network manager want to
get a notification when for whatever reason the regdomain changes, and
they want to be able to query which one is currently set, and things
should be changeable. So you need at least three messages, NEW, GET,
SET, no?

> > >  CRDA replies by sending a regulatory domain
> > > + * 	structure which consists of %NL80211_ATTR_REG_ALPHA set to our current alpha2
> > > + * 	if it found a match.
> > 
> > Why set the alpha2 again? I thought the kernel queried for that?
> 
> This is in case we wanted to support letting userspace query the kernel
> what alpha2 it has set. I'm OK with not supporting this though but it
> seemed it may have come in handy, hopefully not for abuse for other
> things.

Yeah true, we may want to be able to force a certain regdomain.

> > >  and a regulatory rule. The regulatory
> > > + * 	rule consists of set of frequency ranges given by
> > > + * 	%NL80211_ATTR_REG_RULE_FREQ_[START|END] with an attached power rule given
> > > + * 	by %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and
> > > + * 	%NL80211_ATTR_REG_RULE_POWER_MAX_EIRP. Each regulatory rule also has 
> > > + * 	an attached %NL80211_ATTR_REG_RULE_FLAGS.
> > 
> > How are these attributes used? Nested in some array?
> 
> I wasn't sure yet, I wanted your feedback, but you are giving me this
> through IRC :)

Well, as I said, look at how wiphy band info with frequencies works.
That's how you need to do it with netlink attributes.

> > > + * @NL80211_ATTR_REG_RULE_FREQ_START: starting frequencry for the regulatory
> > > + * 	rule in KHz. This is not a center of frequency but an actual regulatory
> >                                             ^^ remove
> > > + * 	band edge.
> > > + * @NL80211_ATTR_REG_RULE_FREQ_END: ending frequency for the regulatory rule
> > > + * 	in KHz. This is not a center a frequency but an actual regulatory
> >                                        ^^ remove
> > > + * 	band edge.
> > > + * @NL80211_ATTR_REG_RULE_FREQ_MAX_BW: maximum allowed bandwidth for this
> > > + * 	frequency range, in KHz.
> > > + * @NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN: the maximum allowed antenna gain
> > > + * 	for a given frequency range. The value is in mBi (100 * dBi).
> > 
> > Can be left out.
> 
> OK.

I mean, you have to add a note that it can be left out if it's not
specified in the db.

> > > @@ -9,137 +10,93 @@
> > >   */
> > >  
> > >  /*
> > > - * This regulatory domain control implementation is highly incomplete, it
> > > - * only exists for the purpose of not regressing mac80211.
> > > - *
> > > - * For now, drivers can restrict the set of allowed channels by either
> > > - * not registering those channels or setting the IEEE80211_CHAN_DISABLED
> > > - * flag; that flag will only be *set* by this code, never *cleared.
> > > - *
> > >   * The usual implementation is for a driver to read a device EEPROM to
> > >   * determine which regulatory domain it should be operating under, then
> > >   * looking up the allowable channels in a driver-local table and finally
> > >   * registering those channels in the wiphy structure.
> > >   *
> > > - * Alternatively, drivers that trust the regulatory domain control here
> > > - * will register a complete set of capabilities and the control code
> > > - * will restrict the set by setting the IEEE80211_CHAN_* flags.
> > 
> > I think you shouldn't remove that but just rewrite it to make the driver
> > trust crda instead of this code.
> 
> The EEPROM lets us get a list of supported channels for a product a
> customer (a vendor's customer, not a regular customer) decided to support.
> If we trust CRDA we then could potentially trust a different set of channels
> which the customer may not have tested his products on. They probably
> will work, but the safer approach is to support only the intended
> channels.
> 
> We can then trust CRDA only to disable channels, not to *enable*.

That's already covered by the paragraph above it though, "[t]he usual
implementation is for a driver [...]". Hence, you want to rewrite the
second paragraph as I mentioned :)

johannes

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

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Thu, Jun 12, 2008 at 06:19:38AM -0700, Johannes Berg wrote:
> 
> > > > + * @NL80211_CMD_GET_REG: Get current regulatory domain, this is a query 
> > > > + * 	to the kernel wireless core, the wireless core returns currently
> > > > + * 	set alpha2 by %NL80211_ATTR_REG_ALPHA2,.
> > > 
> > > Please specify what command it comes in, probably _NEW_REG that you
> > > haven't added.
> > 
> > We can probably not even add this, what do you think?
> 
> Well I think that some userspace programs like network manager want to
> get a notification when for whatever reason the regdomain changes, and
> they want to be able to query which one is currently set, and things
> should be changeable. So you need at least three messages, NEW, GET,
> SET, no?

Then I see us requiring:

SET and GET, but not NEW. If only need to "set" "one" regulatory domain,
not create one and then set one. What do you think?

> > > >  CRDA replies by sending a regulatory domain
> > > > + * 	structure which consists of %NL80211_ATTR_REG_ALPHA set to our current alpha2
> > > > + * 	if it found a match.
> > > 
> > > Why set the alpha2 again? I thought the kernel queried for that?
> > 
> > This is in case we wanted to support letting userspace query the kernel
> > what alpha2 it has set. I'm OK with not supporting this though but it
> > seemed it may have come in handy, hopefully not for abuse for other
> > things.
> 
> Yeah true, we may want to be able to force a certain regdomain.

Huh? I was talking about querying from userspace to the kernel for the
currently set alpha2, in case userspace may want to know what the kernel
last used to ask CRDA for a regdomain.

How did this change to being able to fore a certain regdomain?

Anyway, the only valid case where I see us needing to set a regdomain
manaullay is if an access point doesn't have an 802.11d country
information element. Which BTW -- soon we'll have to decide how we want
to implement, as we could either respect the IE with the channels passed
or just ask CRDA for the alpha2 given.

> > > >  and a regulatory rule. The regulatory
> > > > + * 	rule consists of set of frequency ranges given by
> > > > + * 	%NL80211_ATTR_REG_RULE_FREQ_[START|END] with an attached power rule given
> > > > + * 	by %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and
> > > > + * 	%NL80211_ATTR_REG_RULE_POWER_MAX_EIRP. Each regulatory rule also has 
> > > > + * 	an attached %NL80211_ATTR_REG_RULE_FLAGS.
> > > 
> > > How are these attributes used? Nested in some array?
> > 
> > I wasn't sure yet, I wanted your feedback, but you are giving me this
> > through IRC :)
> 
> Well, as I said, look at how wiphy band info with frequencies works.
> That's how you need to do it with netlink attributes.

OK.

> > > > + * @NL80211_ATTR_REG_RULE_FREQ_START: starting frequencry for the regulatory
> > > > + * 	rule in KHz. This is not a center of frequency but an actual regulatory
> > >                                             ^^ remove
> > > > + * 	band edge.
> > > > + * @NL80211_ATTR_REG_RULE_FREQ_END: ending frequency for the regulatory rule
> > > > + * 	in KHz. This is not a center a frequency but an actual regulatory
> > >                                        ^^ remove
> > > > + * 	band edge.
> > > > + * @NL80211_ATTR_REG_RULE_FREQ_MAX_BW: maximum allowed bandwidth for this
> > > > + * 	frequency range, in KHz.
> > > > + * @NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN: the maximum allowed antenna gain
> > > > + * 	for a given frequency range. The value is in mBi (100 * dBi).
> > > 
> > > Can be left out.
> > 
> > OK.
> 
> I mean, you have to add a note that it can be left out if it's not
> specified in the db.

N/A think right. Yeah sure, I'll update it. Which reminds me I have to
hanlde that in reg.c, I didn't yet.

> > > > @@ -9,137 +10,93 @@
> > > >   */
> > > >  
> > > >  /*
> > > > - * This regulatory domain control implementation is highly incomplete, it
> > > > - * only exists for the purpose of not regressing mac80211.
> > > > - *
> > > > - * For now, drivers can restrict the set of allowed channels by either
> > > > - * not registering those channels or setting the IEEE80211_CHAN_DISABLED
> > > > - * flag; that flag will only be *set* by this code, never *cleared.
> > > > - *
> > > >   * The usual implementation is for a driver to read a device EEPROM to
> > > >   * determine which regulatory domain it should be operating under, then
> > > >   * looking up the allowable channels in a driver-local table and finally
> > > >   * registering those channels in the wiphy structure.
> > > >   *
> > > > - * Alternatively, drivers that trust the regulatory domain control here
> > > > - * will register a complete set of capabilities and the control code
> > > > - * will restrict the set by setting the IEEE80211_CHAN_* flags.
> > > 
> > > I think you shouldn't remove that but just rewrite it to make the driver
> > > trust crda instead of this code.
> > 
> > The EEPROM lets us get a list of supported channels for a product a
> > customer (a vendor's customer, not a regular customer) decided to support.
> > If we trust CRDA we then could potentially trust a different set of channels
> > which the customer may not have tested his products on. They probably
> > will work, but the safer approach is to support only the intended
> > channels.
> > 
> > We can then trust CRDA only to disable channels, not to *enable*.
> 
> That's already covered by the paragraph above it though, "[t]he usual
> implementation is for a driver [...]". Hence, you want to rewrite the
> second paragraph as I mentioned :)

OK.

  Luis

Re: [RFC] First CRDA integration work

[Johannes Berg]

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


> > Well I think that some userspace programs like network manager want to
> > get a notification when for whatever reason the regdomain changes, and
> > they want to be able to query which one is currently set, and things
> > should be changeable. So you need at least three messages, NEW, GET,
> > SET, no?
> 
> Then I see us requiring:
> 
> SET and GET, but not NEW. If only need to "set" "one" regulatory domain,
> not create one and then set one. What do you think?

Which message are you going to use to notify userspace that it changed?
I'd say "NEW".

> > > This is in case we wanted to support letting userspace query the kernel
> > > what alpha2 it has set. I'm OK with not supporting this though but it
> > > seemed it may have come in handy, hopefully not for abuse for other
> > > things.
> > 
> > Yeah true, we may want to be able to force a certain regdomain.
> 
> Huh? I was talking about querying from userspace to the kernel for the
> currently set alpha2, in case userspace may want to know what the kernel
> last used to ask CRDA for a regdomain.
> 
> How did this change to being able to fore a certain regdomain?

Never mind.

> Anyway, the only valid case where I see us needing to set a regdomain
> manaullay is if an access point doesn't have an 802.11d country
> information element. Which BTW -- soon we'll have to decide how we want
> to implement, as we could either respect the IE with the channels passed
> or just ask CRDA for the alpha2 given.

Yeah, I dunno, either option seems possible. Maybe both? That is, ask
the crda and then restrict to what the AP said (since that'll only be
useful anyway) but then.. Hmm could get into trouble that way if AP is
then on an unsupported channel ;)

johannes

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

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Thu, Jun 12, 2008 at 06:57:49AM -0700, Johannes Berg wrote:
> 
> > > Well I think that some userspace programs like network manager want to
> > > get a notification when for whatever reason the regdomain changes, and
> > > they want to be able to query which one is currently set, and things
> > > should be changeable. So you need at least three messages, NEW, GET,
> > > SET, no?
> > 
> > Then I see us requiring:
> > 
> > SET and GET, but not NEW. If only need to "set" "one" regulatory domain,
> > not create one and then set one. What do you think?
> 
> Which message are you going to use to notify userspace that it changed?
> I'd say "NEW".

Oh well I hand't thought about that yet. OK.

> > > > This is in case we wanted to support letting userspace query the kernel
> > > > what alpha2 it has set. I'm OK with not supporting this though but it
> > > > seemed it may have come in handy, hopefully not for abuse for other
> > > > things.
> > > 
> > > Yeah true, we may want to be able to force a certain regdomain.
> > 
> > Huh? I was talking about querying from userspace to the kernel for the
> > currently set alpha2, in case userspace may want to know what the kernel
> > last used to ask CRDA for a regdomain.
> > 
> > How did this change to being able to fore a certain regdomain?
> 
> Never mind.
> 
> > Anyway, the only valid case where I see us needing to set a regdomain
> > manaullay is if an access point doesn't have an 802.11d country
> > information element. Which BTW -- soon we'll have to decide how we want
> > to implement, as we could either respect the IE with the channels passed
> > or just ask CRDA for the alpha2 given.
> 
> Yeah, I dunno, either option seems possible. Maybe both?

Just so you know, considerations against trusting APs are some APs
may have outdated reg information. But then again some APs may also have
very custom and specific regdomains -- think military, etc. So yeah
perhaps both would be good and have this be configurable.

> That is, ask
> the crda and then restrict to what the AP said 

Not sure I follow. The way I was thinking of it is this:

When you receive an 802.11d country IE from an AP, you eithere say:

"Sir, yes Sir!" -- and build a regdom based on that.

Or:

"Eh, you look old, what do you know!" -- and use only the alpha2 from the
IE, then ask CRDA for the reg info for this country and get that into
the kernel.

Another consideration is -- what is following the specification? I
realize we don't have to follow the specification down to every word but
I do think following the country IE and respecting it might have been
the whole point.

> (since that'll only be
> useful anyway) but then.. Hmm could get into trouble that way if AP is
> then on an unsupported channel ;)

Sure can run into trouble -- if the EEPROM says you don't have that channel
we should respect it, technically. So the 802.11d will only be useful to
also build the regdomain.

Of course, some drivers may choose to just use the CRDA info to build
their channels dynamically. They can take their pick, but vendors want
to trust their EEPROM as that is what is supported.

  Luis

RE: [RFC] First CRDA integration work

[Joerg Pommnitz]

Hello Luis,
I did not read the complete patch but closely looked at the CRDA design picture. I have a comment:
The company I work for has special regulatory approval to use amplified WLAN on certain channels (up to 4W). The nodes additionally have non-amplified WLAN adapters that fall under the normal regulatory requirements. It would be nice if your work allowed to specify such cases, e.g. have different regulatory restrictions for differen cards in the same machine. In our case we would like to restrict the amplified interface to the channels it is allowed to run on.

-- 
Regards
       Joerg


      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Wed, Jun 11, 2008 at 1:28 AM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
> Hello Luis,
> I did not read the complete patch but closely looked at the CRDA design picture. I have a comment:
> The company I work for has special regulatory approval to use amplified WLAN on certain channels (up to 4W). The nodes additionally have non-amplified WLAN adapters that fall under the normal regulatory requirements. It would be nice if your work allowed to specify such cases, e.g. have different regulatory restrictions for differen cards in the same machine. In our case we would like to restrict the amplified interface to the channels it is allowed to run on.

Hm, interesting. Well you can simply use a custom db.txt with a custom
PGP private key to sign it and also provide your customers with a
custom CRDA which uses this. All you'd have to do is modify the keys
and db.txt. This of course doesn't work to help comply if you have
extra regulatory efforts on the drivers using the EEPROM of firmware
so the next best thing would be to add a struct ieee80211_regdomain to
each struct wiphy. I considered this too but this starts to move away
from the centralized scheme. Its good you mention this case though.
Can you elaborate a bit more on it. Why do you need two separate WLAN
devices on one node where each one of them is using very different
regulatory rules? Do they both use the same frequency ranges?

  Luis

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Wed, Jun 11, 2008 at 3:09 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Jun 11, 2008 at 1:28 AM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
>> Hello Luis,
>> I did not read the complete patch but closely looked at the CRDA design picture. I have a comment:
>> The company I work for has special regulatory approval to use amplified WLAN on certain channels (up to 4W). The nodes additionally have non-amplified WLAN adapters that fall under the normal regulatory requirements. It would be nice if your work allowed to specify such cases, e.g. have different regulatory restrictions for differen cards in the same machine. In our case we would like to restrict the amplified interface to the channels it is allowed to run on.
>
> Hm, interesting. Well you can simply use a custom db.txt with a custom
> PGP private key to sign it and also provide your customers with a
> custom CRDA which uses this. All you'd have to do is modify the keys
> and db.txt. This of course doesn't work to help comply if you have

I meant to say if you don't have.

> extra regulatory efforts on the drivers using the EEPROM of firmware
> so the next best thing would be to add a struct ieee80211_regdomain to
> each struct wiphy. I considered this too but this starts to move away
> from the centralized scheme. Its good you mention this case though.
> Can you elaborate a bit more on it. Why do you need two separate WLAN
> devices on one node where each one of them is using very different
> regulatory rules? Do they both use the same frequency ranges?

  Luis

Re: [RFC] First CRDA integration work

[Joerg Pommnitz]

--- Luis R. Rodriguez <lrodriguez@atheros.com> wrote am Mi, 11.6.2008:

> Can you elaborate a bit more on it. Why do you need two
> separate WLAN
> devices on one node where each one of them is using very
> different
> regulatory rules?

The interface connected to the amplifier provides long range communication (up to 5km) on reserved channels. The nodes work as routers/APs that provide access to "normal" WLAN devices (this is where the second wireless device comes into play). So:
* two WLAN devices: 1x long range with amplifier, 1x short range as AP
* different regulatory settings: the regulatory rules for the device with amplifier differ from those without amplifier.

> Do they both use the same frequency
> ranges?

This is not required. Currently both use channels in the 2.4GHz range, but there is a very good chance that we will move into the 5GHz range for the amplified backbone (yes, we know that this will come at a cost).

>   Luis

Thanks for taking an interest
  Joerg


      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

Re: [RFC] First CRDA integration work

[Luis R. Rodriguez]

On Wed, Jun 11, 2008 at 1:38 PM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
> --- Luis R. Rodriguez <lrodriguez@atheros.com> wrote am Mi, 11.6.2008:
>
>> Can you elaborate a bit more on it. Why do you need two
>> separate WLAN
>> devices on one node where each one of them is using very
>> different
>> regulatory rules?
>
> The interface connected to the amplifier provides long range communication (up to 5km) on reserved channels. The nodes work as routers/APs that provide access to "normal" WLAN devices (this is where the second wireless device comes into play). So:
> * two WLAN devices: 1x long range with amplifier, 1x short range as AP
> * different regulatory settings: the regulatory rules for the device with amplifier differ from those without amplifier.

OK then yes the current CRDA design covers this. You have a PtP link
(long range 4W) and a PtMP setup (the AP). You can define PtP rules
which are different from PtMP rules. We however still need to then
make mac80211 aware of these differences of type of links. But yes,
the design covers it.

Check out

regdb.h from CRDA, we have RRF_PTP_ONLY and RRF_PTMP_ONLY flags.

So you can just define your own rules with your own db.txt. You know
what you're getting into. Not everyone is allowed to output at 4W so
you can define your own db.txt and sign it yourself.

>> Do they both use the same frequency
>> ranges?
>
> This is not required. Currently both use channels in the 2.4GHz range, but there is a very good chance that we will move into the 5GHz range for the amplified backbone (yes, we know that this will come at a cost).
>
>>   Luis
>
> Thanks for taking an interest

Thanks for reviewing.

  Luis