* [PATCH 12/53] wireless-regdb: PR, Puerto Rico - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:18 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and update the max EIRP. This also adds
a new DFS 5 GHz band: 5490 - 5710 MHz.
PR is a proper ISO 3166 alpha2 code for Puerto Rico,
an unincorporated territory of the United States.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index c37c3d6..867b070 100644
--- a/db.txt
+++ b/db.txt
@@ -637,9 +637,10 @@ country PT: DFS-ETSI
country PR:
(2402 - 2472 @ 40), (3, 27)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 23), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country QA:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/53] wireless-regdb: PH, Philippines - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:18 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage the existing only
5 GHz band but also adds 3 other new 5 GHz bands with
80 MHz bandwidth support.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 00e5993..c37c3d6 100644
--- a/db.txt
+++ b/db.txt
@@ -610,7 +610,10 @@ country PG:
country PH:
(2402 - 2482 @ 40), (N/A, 20)
- (5735 - 5835 @ 40), (N/A, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country PK:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/53] wireless-regdb: PE, Peru - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage the existing only
5 GHz band but also adds 3 other new 5 GHz bands with
80 MHz bandwidth support.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 570a951..00e5993 100644
--- a/db.txt
+++ b/db.txt
@@ -597,7 +597,10 @@ country PA:
country PE:
(2402 - 2482 @ 40), (N/A, 20)
- (5735 - 5835 @ 40), (N/A, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country PG:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/53] wireless-regdb: MX, Mexico - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and update the max EIRP. This also adds
a new DFS 5 GHz band: 5490 - 5710 MHz.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index 4b1cf8e..570a951 100644
--- a/db.txt
+++ b/db.txt
@@ -550,9 +550,10 @@ country MY:
country MX:
(2402 - 2472 @ 40), (3, 27)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 23), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country NL: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/53] wireless-regdb: GU, Guam - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and update the max EIRP. This also adds
a new DFS 5 GHz band: 5490 - 5710 MHz.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index 6d7a762..4b1cf8e 100644
--- a/db.txt
+++ b/db.txt
@@ -337,9 +337,10 @@ country GT:
country GU:
(2402 - 2472 @ 40), (3, 27)
- (5170 - 5250 @ 20), (3, 17)
- (5250 - 5330 @ 20), (3, 23), DFS
- (5735 - 5835 @ 20), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country HN:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/53] wireless-regdb: CO, Colombia - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and update the max EIRP. This also adds
a new DFS 5 GHz band: 5490 - 5710 MHz.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index b82b255..6d7a762 100644
--- a/db.txt
+++ b/db.txt
@@ -172,9 +172,10 @@ country CN:
country CO:
(2402 - 2472 @ 40), (3, 27)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 23), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country CR:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/53] wireless-regdb: AR, Argentina - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and increases the max EIRP on two
5 GHz bands.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index 1f16aff..b82b255 100644
--- a/db.txt
+++ b/db.txt
@@ -38,10 +38,10 @@ country AN:
country AR:
(2402 - 2482 @ 40), (N/A, 20)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 20), DFS
- (5490 - 5710 @ 40), (3, 20), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country AT: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/53] wireless-regdb: NZ, New Zealand - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and increases the max EIRP on two
5 GHz bands, decreases the max EIRP on the first
5 GHz band and adds a new band 5490 - 5710 MHz.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index bb846af..1f16aff 100644
--- a/db.txt
+++ b/db.txt
@@ -574,9 +574,10 @@ country NP:
country NZ:
(2402 - 2482 @ 40), (N/A, 30)
- (5170 - 5250 @ 20), (3, 23)
- (5250 - 5330 @ 20), (3, 23), DFS
- (5735 - 5835 @ 20), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country OM:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/53] wireless-regdb: HK, Hong Kong - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and increases the max EIRP on two
5 GHz bands.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index 37a13c6..bb846af 100644
--- a/db.txt
+++ b/db.txt
@@ -349,10 +349,10 @@ country HN:
country HK:
(2402 - 2482 @ 40), (N/A, 20)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 20), DFS
- (5490 - 5710 @ 40), (3, 20), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country HR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/53] wireless-regdb: CA, Canada - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and increases the max EIRP on two
5 GHz bands.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index a6c23bd..37a13c6 100644
--- a/db.txt
+++ b/db.txt
@@ -142,10 +142,10 @@ country BZ:
country CA:
(2402 - 2472 @ 40), (3, 27)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 20), DFS
- (5490 - 5710 @ 40), (3, 20), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country CH: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/53] wireless-regdb: BR, Brazil - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and increases the max EIRP on two
5 GHz bands.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index 0e7794e..a6c23bd 100644
--- a/db.txt
+++ b/db.txt
@@ -125,10 +125,10 @@ country BO:
country BR:
(2402 - 2482 @ 40), (N/A, 20)
- (5170 - 5250 @ 40), (3, 17)
- (5250 - 5330 @ 40), (3, 20), DFS
- (5490 - 5710 @ 40), (3, 20), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country BY:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 01/53] wireless-regdb: AU, Australia - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage on all 5 GHz
frequencies and updates the max EIRP. This also adds
a new DFS 5 GHz band: 5490 - 5710 MHz.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index c5861b8..0e7794e 100644
--- a/db.txt
+++ b/db.txt
@@ -53,9 +53,10 @@ country AT: DFS-ETSI
country AU:
(2402 - 2482 @ 40), (N/A, 20)
- (5170 - 5250 @ 40), (3, 23)
- (5250 - 5330 @ 40), (3, 23), DFS
- (5735 - 5835 @ 40), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country AW:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/53] wireless-regdb: latest updates
From: Luis R. Rodriguez @ 2013-07-17 2:17 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
I saw one comment posted about the Indonesia patch, I fixed that.
I also then ran some sanity tests with a new reglib addition
wich I recently posted. This helped find two cases which
required disabling VHT80 for two countries on a specific band.
One was for US for 5690 and another for TW for 5290. In both cases
the reason is due to the fact that the only way to use VHT80 is
to combine two frequency ranges together that are contiguous and
apply the most restrictive band rules for that range. We don't support
this yet so just disable VHT80 in both cases. In the US case this
also seems to be the preferred ruling.
This now goes out in patch form.
Luis R. Rodriguez (53):
wireless-regdb: AU, Australia - enable VHT80
wireless-regdb: BR, Brazil - enable VHT80
wireless-regdb: CA, Canada - enable VHT80
wireless-regdb: HK, Hong Kong - enable VHT80
wireless-regdb: NZ, New Zealand - enable VHT80
wireless-regdb: AR, Argentina - enable VHT80
wireless-regdb: CO, Colombia - enable VHT80
wireless-regdb: GU, Guam - enable VHT80
wireless-regdb: MX, Mexico - enable VHT80
wireless-regdb: PE, Peru - enable VHT80
wireless-regdb: PH, Philippines - enable VHT80
wireless-regdb: PR, Puerto Rico - enable VHT80
wireless-regdb: SA, Saudi Arabia - enable VHT80
wireless-regdb: SG, Singapore - enable VHT80
wireless-regdb: ZA, South Africa - enable VHT80
wireless-regdb: TH, Thailand - enable VHT80
wireless-regdb: AE, United Arab Emirates - enable VHT80
wireless-regdb: VN, Vietnam - enable VHT80
wireless-regdb: AT, Austria - enable VHT80
wireless-regdb: FR, France - enable VHT80
wireless-regdb: DE, Germany - enable VHT80
wireless-regdb: GB, United Kingdom - enable VHT80
wireless-regdb: BE, Belgium - enable VHT80
wireless-regdb: CZ, Czech Republic - enable VHT80
wireless-regdb: DK, Denmark - enable VHT80
wireless-regdb: FI, Finland - enable VHT80
wireless-regdb: GR, Greece- enable VHT80
wireless-regdb: IE, Ireland - enable VHT80
wireless-regdb: IT, Italy - enable VHT80
wireless-regdb: LU, Luxembourg - enable VHT80
wireless-regdb: NL, Netherlands - enable VHT80
wireless-regdb: PL, Poland - enable VHT80
wireless-regdb: PT, Portugal - enable VHT80
wireless-regdb: SK, Slovakia - enable VHT80
wireless-regdb: ES, Spain - enable VHT80
wireless-regdb: SE, Sweden - enable VHT80
wireless-regdb: CH, Switzerland - enable VHT80
wireless-regdb: TR, Turkey - enable VHT80
wireless-regdb: CN, China - enable VHT80
wireless-regdb: enable VHT80 and VHT160 for JP
wireless-regdb: US, United States - enable VHT80
wireless-regdb: ID, Indonesia - enable 5 GHz and VHT80
wireless-regdb: IL, Isreal - enable VHT80
wireless-regdb: KW, Kuwait - enable VHT80
wireless-regdb: MY, Malaysia - enable VHT80
wireless-regdb: MA, Morocco - enable 5 GHz and VHT80
wireless-regdb: enable HT40 in RU - Russian Federation
wireless-regdb: KR, Republic of Korea - enable VHT80
wireless-regdb: TW, Taiwan - enable VHT80
wireless-regdb: enable VHT80 when world roaming
wireless-regdb: add 802.11ad 60 GHz channels 1..3 to world regdom
wireless-regdb: CR, Costa Rica - enable VHT80
wireless-regdb: EC, Ecauador - enable VHT80
db.txt | 316 +++++++++++++++++++++++++++++++++++-----------------------------
1 file changed, 173 insertions(+), 143 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH] reglib: add reglib_is_valid_rd() and verify data upon build
From: Luis R. Rodriguez @ 2013-07-17 1:32 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This will verify the sanity of a regulatory domain upon build
time. This is useful if you are making modifications to
wireless-regdb and need to verify the regulatory domains
won't be rejected by a similar checker. In the case of the
Linux kernel regulatory domain data structures that get
a complaint would have been rejected completely.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
regdbdump.c | 5 +++++
reglib.c | 16 ++++++++++++++++
reglib.h | 10 ++++++++++
3 files changed, 31 insertions(+)
diff --git a/regdbdump.c b/regdbdump.c
index cc7eb85..bb83af9 100644
--- a/regdbdump.c
+++ b/regdbdump.c
@@ -8,6 +8,11 @@ static void reglib_regdbdump(const struct reglib_regdb_ctx *ctx)
unsigned int idx = 0;
reglib_for_each_country(rd, idx, ctx) {
+ if (!reglib_is_valid_rd(rd)) {
+ fprintf(stderr, "country %.2s: invalid\n", rd->alpha2);
+ free((struct ieee80211_regdomain *) rd);
+ continue;
+ }
reglib_print_regdom(rd);
free((struct ieee80211_regdomain *) rd);
}
diff --git a/reglib.c b/reglib.c
index 224821b..64584f4 100644
--- a/reglib.c
+++ b/reglib.c
@@ -427,6 +427,22 @@ static int is_valid_reg_rule(const struct ieee80211_reg_rule *rule)
return 1;
}
+int reglib_is_valid_rd(const struct ieee80211_regdomain *rd)
+{
+ const struct ieee80211_reg_rule *reg_rule = NULL;
+ unsigned int i;
+
+ if (!rd->n_reg_rules)
+ return 0;
+
+ for (i = 0; i < rd->n_reg_rules; i++) {
+ reg_rule = &rd->reg_rules[i];
+ if (!is_valid_reg_rule(reg_rule))
+ return 0;
+ }
+ return 1;
+}
+
/*
* Helper for reglib_intersect_rds(), this does the real
* mathematical intersection fun
diff --git a/reglib.h b/reglib.h
index 57082fe..7a586a3 100644
--- a/reglib.h
+++ b/reglib.h
@@ -150,6 +150,16 @@ reglib_get_rd_idx(unsigned int idx, const struct reglib_regdb_ctx *ctx);
const struct ieee80211_regdomain *
reglib_get_rd_alpha2(const char *alpha2, const char *file);
+/**
+ * reglib_is_valid_rd - validate regulatory domain data structure
+ *
+ * @rd: regulatory domain data structure to validate
+ *
+ * You can use this to validate regulatory domain data structures
+ * for possible inconsistencies.
+ */
+int reglib_is_valid_rd(const struct ieee80211_regdomain *rd);
+
/* reg helpers */
void reglib_print_regdom(const struct ieee80211_regdomain *rd);
struct ieee80211_regdomain *
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] reglib: Validate all structure and array lengths
From: Luis R. Rodriguez @ 2013-07-17 1:31 UTC (permalink / raw)
To: Ben Hutchings, linux-wireless
Cc: wireless-regdb@lists.infradead.org, alexandre
In-Reply-To: <1372636171.5155.56.camel@deadeye.wl.decadent.org.uk>
On Sun, Jun 30, 2013 at 4:49 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> Add checks that:
> - Signature length does not exceed the file length (this was already
> checked, but did not account for signature lengths greater than 2 GB)
> - Database length is long enough for all structures we expect in it
> - Array length calculations will not overflow
>
> To keep these checks simple, change the types of array length and index
> variables to unsigned int (must be at least 32-bit, matching the file
> format) and the types of byte-length variables to size_t.
>
> Alexandre Rebert <alexandre@cmu.edu> reported and provided a test case
> for the signature length issue; the others I found by inspection.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Thanks! Despite the fact you didn't resend for a wider review and I
would have preferred this split up into a few patches this has been
sitting on wireless-regdb for a while, so after my review I just
applied and pushed. Thanks again!
Luis
> ---
> reglib.c | 58 +++++++++++++++++++++++++++++++++++++++++-----------------
> reglib.h | 5 +++--
> 2 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/reglib.c b/reglib.c
> index c4d00f8..224821b 100644
> --- a/reglib.c
> +++ b/reglib.c
> @@ -10,6 +10,7 @@
> #include <stdbool.h>
> #include <unistd.h>
> #include <string.h>
> +#include <limits.h>
>
> #include <arpa/inet.h> /* ntohl */
>
> @@ -37,10 +38,16 @@
> #include "keys-gcrypt.c"
> #endif
>
> -void *reglib_get_file_ptr(uint8_t *db, int dblen, int structlen, uint32_t ptr)
> +void *
> +reglib_get_file_ptr(uint8_t *db, size_t dblen, size_t structlen, uint32_t ptr)
> {
> uint32_t p = ntohl(ptr);
>
> + if (structlen > dblen) {
> + fprintf(stderr, "Invalid database file, too short!\n");
> + exit(3);
> + }
> +
> if (p > dblen - structlen) {
> fprintf(stderr, "Invalid database file, bad pointer!\n");
> exit(3);
> @@ -49,6 +56,17 @@ void *reglib_get_file_ptr(uint8_t *db, int dblen, int structlen, uint32_t ptr)
> return (void *)(db + p);
> }
>
> +static size_t
> +reglib_array_len(size_t baselen, unsigned int elemcount, size_t elemlen)
> +{
> + if (elemcount > (SIZE_MAX - baselen) / elemlen) {
> + fprintf(stderr, "Invalid database file, count too large!\n");
> + exit(3);
> + }
> +
> + return baselen + elemcount * elemlen;
> +}
> +
> /*
> * reglib_verify_db_signature():
> *
> @@ -59,7 +77,7 @@ void *reglib_get_file_ptr(uint8_t *db, int dblen, int structlen, uint32_t ptr)
> */
>
> #ifdef USE_OPENSSL
> -int reglib_verify_db_signature(uint8_t *db, int dblen, int siglen)
> +int reglib_verify_db_signature(uint8_t *db, size_t dblen, size_t siglen)
> {
> RSA *rsa;
> uint8_t hash[SHA_DIGEST_LENGTH];
> @@ -118,7 +136,7 @@ out:
> #endif /* USE_OPENSSL */
>
> #ifdef USE_GCRYPT
> -int reglib_verify_db_signature(uint8_t *db, int dblen, int siglen)
> +int reglib_verify_db_signature(uint8_t *db, size_t dblen, size_t siglen)
> {
> gcry_mpi_t mpi_e, mpi_n;
> gcry_sexp_t rsa, signature, data;
> @@ -180,7 +198,7 @@ out:
> #endif /* USE_GCRYPT */
>
> #if !defined(USE_OPENSSL) && !defined(USE_GCRYPT)
> -int reglib_verify_db_signature(uint8_t *db, int dblen, int siglen)
> +int reglib_verify_db_signature(uint8_t *db, size_t dblen, size_t siglen)
> {
> return 1;
> }
> @@ -220,7 +238,7 @@ const struct reglib_regdb_ctx *reglib_malloc_regdb_ctx(const char *regdb_file)
> return NULL;
> }
>
> - ctx->header = reglib_get_file_ptr(ctx->db, ctx->dblen,
> + ctx->header = reglib_get_file_ptr(ctx->db, ctx->real_dblen,
> sizeof(struct regdb_file_header),
> 0);
> header = ctx->header;
> @@ -232,12 +250,13 @@ const struct reglib_regdb_ctx *reglib_malloc_regdb_ctx(const char *regdb_file)
> goto err_out;
>
> ctx->siglen = ntohl(header->signature_length);
> - /* The actual dblen does not take into account the signature */
> - ctx->dblen = ctx->real_dblen - ctx->siglen;
>
> - if (ctx->dblen <= sizeof(*header))
> + if (ctx->siglen > ctx->real_dblen - sizeof(*header))
> goto err_out;
>
> + /* The actual dblen does not take into account the signature */
> + ctx->dblen = ctx->real_dblen - ctx->siglen;
> +
> /* verify signature */
> if (!reglib_verify_db_signature(ctx->db, ctx->dblen, ctx->siglen))
> goto err_out;
> @@ -272,7 +291,7 @@ void reglib_free_regdb_ctx(const struct reglib_regdb_ctx *regdb_ctx)
> free(ctx);
> }
>
> -static void reg_rule2rd(uint8_t *db, int dblen,
> +static void reg_rule2rd(uint8_t *db, size_t dblen,
> uint32_t ruleptr, struct ieee80211_reg_rule *rd_reg_rule)
> {
> struct regdb_file_reg_rule *rule;
> @@ -303,18 +322,21 @@ country2rd(const struct reglib_regdb_ctx *ctx,
> {
> struct regdb_file_reg_rules_collection *rcoll;
> struct ieee80211_regdomain *rd;
> - int i, num_rules, size_of_rd;
> + unsigned int i, num_rules;
> + size_t size_of_rd;
>
> rcoll = reglib_get_file_ptr(ctx->db, ctx->dblen, sizeof(*rcoll),
> country->reg_collection_ptr);
> num_rules = ntohl(rcoll->reg_rule_num);
> /* re-get pointer with sanity checking for num_rules */
> rcoll = reglib_get_file_ptr(ctx->db, ctx->dblen,
> - sizeof(*rcoll) + num_rules * sizeof(uint32_t),
> - country->reg_collection_ptr);
> + reglib_array_len(sizeof(*rcoll), num_rules,
> + sizeof(uint32_t)),
> + country->reg_collection_ptr);
>
> - size_of_rd = sizeof(struct ieee80211_regdomain) +
> - num_rules * sizeof(struct ieee80211_reg_rule);
> + size_of_rd = reglib_array_len(sizeof(struct ieee80211_regdomain),
> + num_rules,
> + sizeof(struct ieee80211_reg_rule));
>
> rd = malloc(size_of_rd);
> if (!rd)
> @@ -468,7 +490,8 @@ struct ieee80211_regdomain *
> reglib_intersect_rds(const struct ieee80211_regdomain *rd1,
> const struct ieee80211_regdomain *rd2)
> {
> - int r, size_of_regd;
> + int r;
> + size_t size_of_regd;
> unsigned int x, y;
> unsigned int num_rules = 0, rule_idx = 0;
> const struct ieee80211_reg_rule *rule1, *rule2;
> @@ -506,8 +529,9 @@ reglib_intersect_rds(const struct ieee80211_regdomain *rd1,
> if (!num_rules)
> return NULL;
>
> - size_of_regd = sizeof(struct ieee80211_regdomain) +
> - ((num_rules + 1) * sizeof(struct ieee80211_reg_rule));
> + size_of_regd = reglib_array_len(sizeof(struct ieee80211_regdomain),
> + num_rules + 1,
> + sizeof(struct ieee80211_reg_rule));
>
> rd = malloc(size_of_regd);
> if (!rd)
> diff --git a/reglib.h b/reglib.h
> index 86087e3..57082fe 100644
> --- a/reglib.h
> +++ b/reglib.h
> @@ -112,8 +112,9 @@ static inline uint32_t reglib_min(uint32_t a, uint32_t b)
> return (a > b) ? b : a;
> }
>
> -void *reglib_get_file_ptr(uint8_t *db, int dblen, int structlen, uint32_t ptr);
> -int reglib_verify_db_signature(uint8_t *db, int dblen, int siglen);
> +void *
> +reglib_get_file_ptr(uint8_t *db, size_t dblen, size_t structlen, uint32_t ptr);
> +int reglib_verify_db_signature(uint8_t *db, size_t dblen, size_t siglen);
>
> /**
> * reglib_malloc_regdb_ctx - create a regdb context for usage with reglib
>
^ permalink raw reply
* Re: [RFC 00/53] wireless-regdb: mostly VHT80 updates
From: Luis R. Rodriguez @ 2013-07-16 23:54 UTC (permalink / raw)
To: John W. Linville
Cc: wireless-regdb@lists.infradead.org, linux-wireless,
Luis R. Rodriguez
In-Reply-To: <CAB=NE6WmcGs6u8ZCrWXcKQe=MsQk_C7R7i+x1V-cDbjQ+A8d-w@mail.gmail.com>
On Tue, Jul 16, 2013 at 1:18 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Wed, Jul 3, 2013 at 6:03 PM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
>> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>>
>> Here's a series of updates for wireless-regdb. Most of this is
>> to just enable VHT80 support to enable support for 802.11ac
>> where this has been verified to be usable. I cannot meet the
>> criteria of providing full documentation for sources for all
>> patches, only a few ones so what I recommend for the rest is
>> to let this sit on the list for a bit and I'd hope after
>> review if no one spots any issues I'd hope we can merge this.
>>
>> I reviewed the idea of vendor namespaces on wireless-regdb
>> and at least through review with pkgadd on IRC we concluded
>> its best to try to take this approach instead of encouraging
>> divergence due to any lack of full source documentation or
>> inability to provide such documentation for whatever reason.
>> This seems to be better than not getting any updates at all
>> and keeps vendors hopefully encouraged to push changes upstream.
>
> I saw one comment addressing a typo on ID, I've fixed that. If there
> are no complaints can we merge these to get VHT80?
Please hold off on these for a bit. I need to test one more thing.
Luis
^ permalink raw reply
* Re: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Luis R. Rodriguez @ 2013-07-16 20:57 UTC (permalink / raw)
To: Peer, Ilan
Cc: Spinadel, David, linux-wireless,
wireless-regdb@lists.infradead.org, Jouni Malinen, Ginsburg, Noam,
Perelmooter, Liraz, Shalev, Oz, Michael Green
In-Reply-To: <CB3B3D4774441E42AA3EA0E1BA8230A01AD2DFC5@HASMSX106.ger.corp.intel.com>
On Wed, Jul 10, 2013 at 3:47 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world regulatory
>> language bands? When I last tried to look for a clear definition I could not find
>> a clear definition of them and its why on the ath module on for QCA modules I
>> state "we call these" in reference to the UNII nomenclature. If we can get a
>> clear resource for its definition that would help here.
>>
>
> Maybe these link will help.
> http://www.gpo.gov/fdsys/pkg/CFR-2010-title47-vol1/xml/CFR-2010-title47-vol1-part15.xml#seqnum15.403
> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-13-22A1.pdf
>
> Anyway, I will use your ''we call these" notation as well :)
No no, this is good, its just United States / FCC biased and I hadn't
seen the documentation you provided before. This confirms these are
official terms but still just US / FCC biased. My point was that we
should be careful to not make global statements on regulatory code
about things that are not global. If we know only the FCC calls this
UNII well lets document that and provide the reference you supplied. I
anticipated having to deal with special case regulatory code outside
of of what CRDA / wireless-regdb provides -- given that CRDA /
wireless-regdb were meant to be more RF agnostic anyway.
Given that other vendors may also want to get the UNII band can you
stuff instead cfg80211_get_unii_band() into reg.c and do the #ifdef
properly with the Kconfig, and export it as well, as well as document
it properly providing the reference you mentioned.
>> > + * 1. Indoor only: a GO can be operational on such a channel, iff there is
>> > + * clear assessment that the platform device is indoor.
>> > + * 2. Concurrent GO: a GO can be operational on such a channel, iff there is
>> an
>> > + * additional station interface connected to an AP on this channel.
>> > + *
>> > + * TODO: The function is too permissive, as it does not verify the
>> > + platform
>> > + * device type is indeed indoor, or that the AP is indoor/AC powered.
>>
>> So to do this properly we need an eventual userspace API to throw to
>> kernelspace if we are AC powered? We'll need this to enhance this routine
>> here?
>>
>
> Not sure about this point. I prefer leaving the exact knowledge of the device type, being AC Powered or not (and which type of AC power) etc. out side of the kernel. The approach I chose with this patch was to only allow to start a GO on such a channel, making the basic verification done above, assuming that the user space component guarantees that all the full restrictions are satisfied.
Fair enough. Seems we just need to zero in now on the requirement or
not on the extra flag you suggested.
>> In the meantime, while you get all your patch sets properly developed I'd
>> recommend to define the code returning false there strictly or perhaps for any
>> flag on the channel requiring DFS / no-ibss, or passive scan. The stricter case,
>> defining false always, seems to be what you are suggesting here.
>
> I do not think that this is needed here. Returning false, means that the code should test if the PASSIVE_SCAN and NO_IBSS are not set on the channel we want to start beaconing on.
>
>> Do you have a white list that can exclude some channels for now globally or
>> somehow as all this lines up?
>>
>
> Note sure I understood what you are looking for. Can you please clarify this point?
It was unclear for what exact channels you needed to deal with here.
Given review so far wouldn't it just be DFS flagged channels on some
UNII bands ? Then again if the indoor flag needs to be pegged to to a
specific UNII band and we can do that on wireless-regdb do we even
need the UNII band check routine helper?
Luis
^ permalink raw reply
* Re: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes
From: Luis R. Rodriguez @ 2013-07-16 20:43 UTC (permalink / raw)
To: Peer, Ilan
Cc: wireless-regdb@lists.infradead.org, linux-wireless,
Spinadel, David, Ginsburg, Noam, Perelmooter, Liraz, Shalev, Oz,
Michael Green
In-Reply-To: <CB3B3D4774441E42AA3EA0E1BA8230A01AD2DF7B@HASMSX106.ger.corp.intel.com>
On Wed, Jul 10, 2013 at 3:43 AM, Peer, Ilan <ilan.peer@intel.com> wrote:
>> On Tue, Jul 2, 2013 at 5:28 AM, Ilan Peer <ilan.peer@intel.com> wrote:
>> > From: David Spinadel <david.spinadel@intel.com>
>> >
>> > The FCC are clarifying some soft configuration requirements, which
>> > among other includes the following:
>> >
>> > 1. Concurrent GO operation, where devices may support WFD in
>> > bands where an authorized master (for example with DFS and
>> > DFS and radar detection capability in the UNII band) is operating.
>>
>> Is WFD WiFi Display? Is there any strict relationship here to WFD and GO and
>> regulatory or is WFD just a use case example? Are you indicating that the FCC
>> is making special rules for cases in specific bands where GO *can* co-exist with
>> other GO devices ?
>
> WFD is WiFi direct in this context. I do not think that the FCC are making special rules only for GO specific scenarios but a more general approach where "compliance may be achieved under the guidance of an authorized master". The WFD/P2P GO case is only an example.
OK then I think cullular base station regulatory hints might be
another example. In fact I believe I am looking at the information you
might be using as reference. I am looking at public draft edit for FCC
KDB 594280:
https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
The original KDB:
http://transition.fcc.gov/oet/ea/presentations/files/apr11/3b.SoftwareConfigurationControl-RDJS.pdf
Specifically in the above document, the draft edit, I am looking at
page 12. That actually references WiFi Direct precisely and considers
the case that a GO may need to move out of its channel if its master
device its using to configure itself also switches channels. Given
that cellular base station hints could also technically be used this
also would need to be considered for cellular base stations. But also
note on page 14 it states clearly:
"Mobile Country Codes (MCC) or Mobile Network Codes
(MNC) are not acceptable for programming host
compliance"
So it seems cellular base station hints are simply not allowed by the
FCC (unless specific approval is requested / revised). Even if the FCC
allowed for it I believe an API would need to be provided should
cellular base stations have a case where they may stop operating as
well similar to DFS.
BTW in future iterations of patches I'd appreciate if you can include
the above references to documentation given that we've pulled them up
now.
>> You annotate that this is somehow related to DFS, are the GO concurrent rules
>> that the FCC is defining only applicable to DFS frequency ranges? If so would it
>> suffice to only use DFS flag ? Or are there other special cases beyond DFS
>> frequency ranges that the FCC is creating special handling?
>>
>
> DFS was given here as an example. Generally, I think that the changes that the FCC are making are targeting various scenarios and various RF devices (for example those defined in part 15 of CFR title 47).
OK thanks. Things are clear now that I see the document that you might
be referring to.
>> Apart from the FCC are you aware of special cases handling for other
>> regulatory bodies at this point?
>
> Not that I'm aware of. Adding some more people that might know more.
Hey folks, anyone? :)
>> Note that we have already these on regdb.h from CRDA:
>>
>>
>> /*
>> * The Linux map defined in <linux/uapi/nl80211.h> enum
>> nl80211_reg_rule_flags */ enum reg_rule_flags {
>> RRF_NO_OFDM = 1<<0, /* OFDM modulation not allowed */
>> RRF_NO_CCK = 1<<1, /* CCK modulation not allowed */
>> RRF_NO_INDOOR = 1<<2, /* indoor operation not allowed */
>> RRF_NO_OUTDOOR = 1<<3, /* outdoor operation not allowed */
>> RRF_DFS = 1<<4, /* DFS support is required to be
>> * used */
>> RRF_PTP_ONLY = 1<<5, /* this is only for Point To Point
>> * links */
>> RRF_PTMP_ONLY = 1<<6, /* this is only for Point To Multi
>> * Point links */
>> RRF_PASSIVE_SCAN = 1<<7, /* passive scan is required */
>> RRF_NO_IBSS = 1<<8, /* IBSS is not allowed */
>> };
>>
>> Historically we don't distinguish then a type of 802.11 device that initiates
>> radiation except for the NO_IBSS rule, but that rule can be treated more as
>> legacy given that the intent and motivation behind that was that some ODMs
>> simply preferred an interpretation of regulatory rules and we *currently* don't
>> use that in much places other than custom regulatory domains defined in the
>> kernel. The PTP_ONLY and PTMP_ONLY are example other rules that could
>> potentially have been used but to this day we haven't found a use case for it
>> given that typical 802.11 devices are PTMP.
>>
>> I mention the NO_IBSS case as I'd like to try to avoid adding GO specific flag if
>> we can figure out a way to make this more generic. At this point for example I
>> think a more appropriate flag is in place:
>>
>
> Actually, this should be a GO only flag, meaning that such relaxation should not be valid for soft AP, IBSS or mesh. The intention here is limit the extend of the cell, and prevent daisy chain scenarios (assume that you allow a soft AP on such a channel and that a client associated to it, and then that device can also start a soft AP on the channel ....). Anyway, I'll need to have another look at this (might be permissible for IBSS ...)
Based on the documentation I reviewed and your proposal it'd seem to
me that we can distinguish GO on the upper layers and determine if a
channel is DFS or not by just the DFS flag. The next hint you'd need
is if the GO got regulatory information from a master somehow, no?
That is I am not seeing a need for a new flag at this point in
wireless-regdb, given also I mentioned another type of case for
regulatory hints technically possible (cellular base station hints but
it seems only allowed with exceptional review by the FCC).
I take it what you want to enable here is GO operation on DFS channels
and use country IEs to determine if you can use GO, but if you do have
GO enabled then you'd want hooks to not daisy chain, ack?
>> > 2. Indoor operation, where in bands requiring indoor operation, the
>> > device must be programmed to detect indoor operation, or
>> > - Device must be connected to AC Power
>>
>> Does anyone know if the FCC considers "indoor" if we power a device through
>> the car on AC power through a converter ? Are we willing to ignore that corner
>> case?
>
> No. AC power means "mains" and not through portable DC converters (see slide 12 in https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn= 528122). It would be up to the user space to identify the device type etc. and identify if this a truly AC powered AP.
OK thanks for the clarification. I wonder if we can distinguish
between the two in userspace today. I'm happy to start pegging
frequency ranges as indoor-only on wireless-regdb even if we don't
have the userspace APIs to annotate when a device is indoor or not
yet. Patches welcomed then.
>> > - Device must be under the control of a local master that is acting
>>
>> Interesting, so some APIs would be defined, I take it on hostapd to do the
>> proper callbacks to 'slave' type of devices that depend on the local master(s). I
>> could envision this being implemented on hostapd by expanding the AP
>> interface type and associating 'slave' devices and callbacks for updates on AP
>> device updates (channel changes, and so on). Is this work being planned?
>
> Yes. We have plans to incorporate more logic to hostap (currently into wpa_supplicant for P2P use cases).
Sweet.
Luis
^ permalink raw reply
* Re: [RFC 00/53] wireless-regdb: mostly VHT80 updates
From: Luis R. Rodriguez @ 2013-07-16 20:18 UTC (permalink / raw)
To: John W. Linville
Cc: wireless-regdb@lists.infradead.org, linux-wireless,
Luis R. Rodriguez
In-Reply-To: <1372899889-19183-1-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jul 3, 2013 at 6:03 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>
> Here's a series of updates for wireless-regdb. Most of this is
> to just enable VHT80 support to enable support for 802.11ac
> where this has been verified to be usable. I cannot meet the
> criteria of providing full documentation for sources for all
> patches, only a few ones so what I recommend for the rest is
> to let this sit on the list for a bit and I'd hope after
> review if no one spots any issues I'd hope we can merge this.
>
> I reviewed the idea of vendor namespaces on wireless-regdb
> and at least through review with pkgadd on IRC we concluded
> its best to try to take this approach instead of encouraging
> divergence due to any lack of full source documentation or
> inability to provide such documentation for whatever reason.
> This seems to be better than not getting any updates at all
> and keeps vendors hopefully encouraged to push changes upstream.
I saw one comment addressing a typo on ID, I've fixed that. If there
are no complaints can we merge these to get VHT80?
Luis
^ permalink raw reply
* [RFC v2] wireless-regdb: ID, Indonesia - enable 5 GHz and VHT80
From: Luis R. Rodriguez @ 2013-07-16 20:07 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, pstew, Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Pursuant to:
http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf,
provide a 5GHz rule for Indonesian regulatory domain. QCA has
also verified VHT80 can be enabled. Patch originally posted by
Paul Stewart <pstew@chromium.org>, I just modified to enable 80 MHz
bandwidth.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
This v2 changes the bandwidth to 80 as was intended with the first
patch.
db.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/db.txt b/db.txt
index 0ebb934..8356d5d 100644
--- a/db.txt
+++ b/db.txt
@@ -380,7 +380,9 @@ country HU: DFS-ETSI
(57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR
country ID:
+ # ref: http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
(2402 - 2482 @ 40), (N/A, 20)
+ (5735 - 5815 @ 80), (N/A, 20)
country IE: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* Re: [BUG] 3.10 regression: hang on suspend
From: Ortwin Glück @ 2013-07-16 18:23 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Stanislaw Gruszka, linux-kernel, linux-wireless
In-Reply-To: <51E51712.4020609@broadcom.com>
Without NetworkManager, no X, on console and with plain jane wpa_supplicant I do
echo mem > /sys/power state
After that, it still responds to keyboard events: I can switch VT and type on
the consoles, but I can not login on a different VT (pressing Enter after the
username doesn't return). So I guess tasks have been frozen, but it hangs in
stopping devices.
settings for pm_test:
devices: same behviour as above
freezer: works as expected (stops tasks; sleeps; resumes tasks)
Nothing in the logs. How can I enable more log?
Ortwin
^ permalink raw reply
* Re: [PATCH 3.11] mac80211/minstrel: fix NULL pointer dereference issue
From: Johannes Berg @ 2013-07-16 14:48 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, krzysiek
In-Reply-To: <1373891706-1071-1-git-send-email-nbd@openwrt.org>
On 2013-07-15 15:35, Felix Fietkau wrote:
> When priv_sta == NULL, mi->prev_sample is dereferenced too early. Move
> the assignment further down, after the rate_control_send_low call.
Applied.
johannes
^ permalink raw reply
* Re: Power saving features for iwl4965
From: Pedro Francisco @ 2013-07-16 11:02 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <20130716102743.GA8321@redhat.com>
On Tue, Jul 16, 2013 at 11:27 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> You can provide me logs with disable_hw_scan=0, if you manage to
> trigger a Microcode error.
I can't trigger the microcode error with the debug. The firmware
however gets corrupted and reloading the module does not fix it
(firmware validation fails until I restart) -- curiously after a
'power info' RXON (? or similar, can't access the logs now) is sent to
the card.
I'll test again tomorrow.
^ permalink raw reply
* [PATCH 1/2] cfg80211: add beacon measurements command
From: Johannes Berg @ 2013-07-16 10:45 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach
In-Reply-To: <1373971517-315-1-git-send-email-johannes@sipsolutions.net>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This new nl80211 command allow a user space application to
instruct the WiFi stack to let all the beacons through so
that measurements can be conducted on these beacons (i.e.
RSSI etc...)
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 12 ++++++++++++
include/uapi/linux/nl80211.h | 10 ++++++++++
net/wireless/nl80211.c | 32 +++++++++++++++++++++++++++++++-
net/wireless/rdev-ops.h | 13 +++++++++++++
net/wireless/trace.h | 17 +++++++++++++++++
5 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index aeaf6df..019e256 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2139,6 +2139,10 @@ struct cfg80211_update_ft_ies_params {
* @crit_proto_stop: Indicates critical protocol no longer needs increased link
* reliability. This operation can not fail.
* @set_coalesce: Set coalesce parameters.
+ *
+ * @beacon_measurement: Start / stops the beacon measurement. When enabled,
+ * beacons should be let through cfg80211 to proceed to measurements (e.g.
+ * RSSI analysis).
*/
struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -2376,6 +2380,10 @@ struct cfg80211_ops {
struct wireless_dev *wdev);
int (*set_coalesce)(struct wiphy *wiphy,
struct cfg80211_coalesce *coalesce);
+
+ int (*beacon_measurement)(struct wiphy *wiphy,
+ struct wireless_dev *wdev,
+ bool state);
};
/*
@@ -2441,6 +2449,9 @@ struct cfg80211_ops {
* @WIPHY_FLAG_OFFCHAN_TX: Device supports direct off-channel TX.
* @WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL: Device supports remain-on-channel call.
* @WIPHY_FLAG_SUPPORTS_5_10_MHZ: Device supports 5 MHz and 10 MHz channels.
+ * @WIPHY_FLAG_SUPPORTS_BEACON_MEAS: Device supports beacon measurements. Should
+ * be set when the device can let all the beacon through up to cfg80211
+ * to proceed to measurements (i.e. RSSI measurements).
*/
enum wiphy_flags {
WIPHY_FLAG_CUSTOM_REGULATORY = BIT(0),
@@ -2465,6 +2476,7 @@ enum wiphy_flags {
WIPHY_FLAG_OFFCHAN_TX = BIT(20),
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL = BIT(21),
WIPHY_FLAG_SUPPORTS_5_10_MHZ = BIT(22),
+ WIPHY_FLAG_SUPPORTS_BEACON_MEAS = BIT(23),
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index eb68735..1a5edad 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -676,6 +676,9 @@
* @NL80211_CMD_GET_COALESCE: Get currently supported coalesce rules.
* @NL80211_CMD_SET_COALESCE: Configure coalesce rules or clear existing rules.
*
+ * @NL80211_CMD_BEACON_MEASUREMENT: Indicates the beacon measurement is
+ * started / stopped. Disassociation should stop the measurements.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -841,6 +844,8 @@ enum nl80211_commands {
NL80211_CMD_GET_COALESCE,
NL80211_CMD_SET_COALESCE,
+ NL80211_CMD_BEACON_MEASUREMENT,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -1469,6 +1474,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_COALESCE_RULE: Coalesce rule information.
*
+ * @NL80211_ATTR_BCON_MEAS_STATE: The state of the beacon measurements. This is
+ * a flag attribute.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1771,6 +1779,8 @@ enum nl80211_attrs {
NL80211_ATTR_COALESCE_RULE,
+ NL80211_ATTR_BCON_MEAS_STATE,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 03d4ef9..c2b43b6 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -349,6 +349,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_IE_RIC] = { .type = NLA_BINARY,
.len = IEEE80211_MAX_DATA_LEN },
[NL80211_ATTR_PEER_AID] = { .type = NLA_U16 },
+ [NL80211_ATTR_BCON_MEAS_STATE] = { .type = NLA_FLAG, },
};
/* policy for the key attributes */
@@ -8646,6 +8647,27 @@ static int nl80211_crit_protocol_stop(struct sk_buff *skb,
return 0;
}
+static int nl80211_beacon_measurement(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct wireless_dev *wdev = info->user_ptr[1];
+ bool state;
+
+
+ if (!rdev->ops->beacon_measurement ||
+ !(rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_BEACON_MEAS))
+ return -EOPNOTSUPP;
+
+ /* Relevant for associated mgd interfaces only */
+ if (wdev->iftype != NL80211_IFTYPE_STATION || !wdev->current_bss)
+ return -EOPNOTSUPP;
+
+ state = info->attrs[NL80211_ATTR_BCON_MEAS_STATE];
+
+ return rdev_beacon_measurement(rdev, wdev, state);
+}
+
#define NL80211_FLAG_NEED_WIPHY 0x01
#define NL80211_FLAG_NEED_NETDEV 0x02
#define NL80211_FLAG_NEED_RTNL 0x04
@@ -9361,7 +9383,15 @@ static struct genl_ops nl80211_ops[] = {
.flags = GENL_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WIPHY |
NL80211_FLAG_NEED_RTNL,
- }
+ },
+ {
+ .cmd = NL80211_CMD_BEACON_MEASUREMENT,
+ .doit = nl80211_beacon_measurement,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_NEED_RTNL,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 9f15f0a..e5b0efb 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -923,4 +923,17 @@ static inline void rdev_crit_proto_stop(struct cfg80211_registered_device *rdev,
trace_rdev_return_void(&rdev->wiphy);
}
+static inline int
+rdev_beacon_measurement(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev, bool state)
+{
+ int ret;
+
+ trace_rdev_beacon_measurement(&rdev->wiphy, wdev, state);
+ ret = rdev->ops->beacon_measurement(&rdev->wiphy, wdev, state);
+ trace_rdev_return_int(&rdev->wiphy, ret);
+
+ return ret;
+}
+
#endif /* __CFG80211_RDEV_OPS */
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 09af6eb..5f6e7f0 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -1841,6 +1841,23 @@ TRACE_EVENT(rdev_crit_proto_stop,
WIPHY_PR_ARG, WDEV_PR_ARG)
);
+TRACE_EVENT(rdev_beacon_measurement,
+ TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev, bool state),
+ TP_ARGS(wiphy, wdev, state),
+ TP_STRUCT__entry(
+ WIPHY_ENTRY
+ WDEV_ENTRY
+ __field(bool, state)
+ ),
+ TP_fast_assign(
+ WIPHY_ASSIGN;
+ WDEV_ASSIGN;
+ __entry->state = state;
+ ),
+ TP_printk(WIPHY_PR_FMT ", " WDEV_PR_FMT " %s",
+ WIPHY_PR_ARG, WDEV_PR_ARG, BOOL_TO_STR(__entry->state))
+);
+
/*************************************************************
* cfg80211 exported functions traces *
*************************************************************/
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] beacon measurement (beacon filtering disable)
From: Johannes Berg @ 2013-07-16 10:45 UTC (permalink / raw)
To: linux-wireless
We have beacon filtering (to reduce host wakeups) in our device,
but for some measurement/debug purposes we need to turn it off.
This adds API for it -- comments welcome.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox