Re: [PATCH] wireless-regdb: add URLs in README

[Seth Forshee]

On Fri, Nov 09, 2018 at 06:10:03PM +0100, Xose Vazquez Perez wrote:
> Cc: Seth Forshee 
> Cc: WIRELESS ML 
> Cc: REGDB ML 
> Signed-off-by: Xose Vazquez Perez 

Applied, thanks!

Re: [PATCH] wireless-regdb: delete outdated comment for DE

[Seth Forshee]

On Fri, Nov 09, 2018 at 11:24:20AM +0100, Xose Vazquez Perez wrote:
> d46d731c made it obsolete.
> 
> Cc: Sven Eckelmann 
> Cc: Seth Forshee 
> Cc: WIRELESS ML 
> Cc: REGDB ML 
> Signed-off-by: Xose Vazquez Perez 

Applied, thanks!

[ANN] wireless-regdb: master-2018-10-24

[Seth Forshee]

A new release of wireless-regdb (master-2018-10-24) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2018.10.24.tar.gz

The short log of changes since the 2018-09-07 release is below.

Thanks,
Seth

---

Hauke Mehrtens (1):
  wireless-regdb: remove dependency to python attr

Seth Forshee (1):
  wireless-regdb: update regulatory database based on preceding changes

Sven Eckelmann (2):
  wireless-regdb: Sync FR with ETSI EN 301 893 V2.1.1 (2017-05)
  wireless-regdb: Sync DE with ETSI EN 301 893 V2.1.1 (2017-05)

Re: [PATCH] wireless-regdb: remove dependency to python attr

[Seth Forshee]

Please remember to Cc wireless-re...@lists.infradead.org for regdb
changes, adding now.

On Sat, Oct 06, 2018 at 06:02:54PM +0200, Hauke Mehrtens wrote:
> Commit 8607edfdb6568 ("wireless-regdb: Parse wmm rule data") introduced
> a dependency to the python module attr which is not included by default
> in all python installations. Replace the code with manually coding the
> constructor instead of using attr. This makes the code also work on
> systems without attr.
> 
> I would like to avoid an additional dependency in OpenWrt where we
> compile the regulatory database inside of the build system.
> 
> Signed-off-by: Hauke Mehrtens 

I had wonderd if this would turn out to be a problem for someone.
Applied, thanks!

> ---
>  dbparse.py | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/dbparse.py b/dbparse.py
> index 5fe752b..993f757 100755
> --- a/dbparse.py
> +++ b/dbparse.py
> @@ -5,7 +5,6 @@ from functools import total_ordering
>  import sys, math
>  from math import ceil, log
>  from collections import defaultdict, OrderedDict
> -import attr
>  
>  # must match  enum nl80211_reg_rule_flags
>  
> @@ -32,16 +31,17 @@ dfs_regions = {
>  
>  @total_ordering
>  
> -@attr.s(frozen=True, cmp=False)
>  class WmmRule(object):
> -vo_c = attr.ib()
> -vi_c = attr.ib()
> -be_c = attr.ib()
> -bk_c = attr.ib()
> -vo_ap = attr.ib()
> -vi_ap = attr.ib()
> -be_ap = attr.ib()
> -bk_ap = attr.ib()
> +
> +def __init__(self, vo_c, vi_c, be_c, bk_c, vo_ap, vi_ap, be_ap, bk_ap):
> +self.vo_c = vo_c
> +self.vi_c = vi_c
> +self.be_c = be_c
> +self.bk_c = bk_c
> +self.vo_ap = vo_ap
> +self.vi_ap = vi_ap
> +self.be_ap = be_ap
> +self.bk_ap = bk_ap
>  
>  def _as_tuple(self):
>  return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
> -- 
> 2.11.0
> 

Re: [PATCH 1/2] wireless-regdb: Sync FR with ETSI EN 301 893 V2.1.1 (2017-05)

[Seth Forshee]

On Mon, Sep 17, 2018 at 09:42:11AM +0200, Sven Eckelmann wrote:
> The documents
> https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf
> and
> https://www.anfr.fr/fileadmin/mediatheque/documents/controle/20171127ANFR_-_ficheRLAN_5GHz.pdf
> show that the limits for the 5GHz bands are out of date:
> 
> * frequencies don't match the official limits
> * 5150 - 5350 MHz is not for outdoor usage
> * 5150 - 5250 MHz only usage is allowed to use up to 23 dBm (200 mW) even
>   without TPC
> 
> Signed-off-by: Sven Eckelmann 

Applied both patches, thanks!

Seth

[ANN] wireless-regdb: master-2018-09-07

[Seth Forshee]

A new release of wireless-regdb (master-2018-09-07) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2018.09.07.tar.gz

The short log of changes since the 2018-05-31 release is below.

Thanks,
Seth

---

Henrik Laxhuber (1):
  wireless-regdb: update regulatory rules for Switzerland (CH), and 
Liechtenstein (LI) on 5GHz

Jukka Pirinen (1):
  Update regulatory rules for Finland (FI) on 5GHz (SRD devices)

Seth Forshee (1):
  wireless-regdb: update regulatory database based on preceding changes

Xose Vazquez Perez (1):
  wireless-regdb: update source of info for CU and ES

bkil (1):
  wireless-regdb: update rules for Hungary (HU) on 2.4/5/60G, 5725-5875MHz

Re: [PATCH] wireless-regdb: update source of info for CU and ES

[Seth Forshee]

On Fri, Sep 07, 2018 at 06:28:41PM +0200, Xose Vazquez Perez wrote:
> Cc: Seth Forshee 
> Cc: WIRELESS ML 
> Cc: REGDB ML 
> Signed-off-by: Xose Vazquez Perez 

Applied, thanks!

Re: [PATCH] wireless-regdb: update regulatory rules for Switzerland (CH), and Liechtenstein (LI) on 5GHz

[Seth Forshee]

On Fri, Sep 07, 2018 at 07:32:56AM -0500, Seth Forshee wrote:
> On Thu, Sep 06, 2018 at 04:13:22PM +0200, Henrik Laxhuber wrote:
> > Update to reflect the current data published in the 'National Frequency
> > Allocation Strategy Table' [0] for Switzerland and Liechtenstein, which
> > at the time of writing points to the documents [1] and [2].
> > 
> > [0] https://www.ofcomnet.ch/#/fatTable
> > [1] https://www.ofcomnet.ch/api/rir/1010/05
> > [2] https://www.ofcomnet.ch/api/rir/1010/04
> > 
> > Signed-off-by: Henrik Laxhuber 
> > ---
> >  db.txt | 19 +++
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/db.txt b/db.txt
> > index 8cf7dee..69cea85 100644
> > --- a/db.txt
> > +++ b/db.txt
> > @@ -265,10 +265,14 @@ country CF: DFS-FCC
> >  (5490 - 5730 @ 40), (24), DFS
> >  (5735 - 5835 @ 40), (30)
> > 
> > +# Source:
> > +# https://www.ofcomnet.ch/#/fatTable
> > +# Note that the maximum transmitter power can be doubled for 5250-5710MHz
> > if
> > +# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
> >  country CH: DFS-ETSI
> >  (2402 - 2482 @ 40), (20)
> > -    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> > -    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> > +    (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> 
> Maybe you missed this in my last reply, I had suggested this range can
> be 5150-5250 as in the document you linked to. If you agree with this
> change I can make it when I apply the patch.

Applied with this change here and in the rules for Liechtenstein.
Thanks!

Re: [PATCH] wireless-regdb: update regulatory rules for Switzerland (CH), and Liechtenstein (LI) on 5GHz

[Seth Forshee]

On Thu, Sep 06, 2018 at 04:13:22PM +0200, Henrik Laxhuber wrote:
> Update to reflect the current data published in the 'National Frequency
> Allocation Strategy Table' [0] for Switzerland and Liechtenstein, which
> at the time of writing points to the documents [1] and [2].
> 
> [0] https://www.ofcomnet.ch/#/fatTable
> [1] https://www.ofcomnet.ch/api/rir/1010/05
> [2] https://www.ofcomnet.ch/api/rir/1010/04
> 
> Signed-off-by: Henrik Laxhuber 
> ---
>  db.txt | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 8cf7dee..69cea85 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -265,10 +265,14 @@ country CF: DFS-FCC
>  (5490 - 5730 @ 40), (24), DFS
>  (5735 - 5835 @ 40), (30)
> 
> +# Source:
> +# https://www.ofcomnet.ch/#/fatTable
> +# Note that the maximum transmitter power can be doubled for 5250-5710MHz
> if
> +# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
>  country CH: DFS-ETSI
>  (2402 - 2482 @ 40), (20)
> -    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> -    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> +    (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI

Maybe you missed this in my last reply, I had suggested this range can
be 5150-5250 as in the document you linked to. If you agree with this
change I can make it when I apply the patch.

Thanks,
Seth

> +    (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>  (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
>  # 60 GHz band channels 1-4, ref: Etsi En 302 567
>  (57000 - 66000 @ 2160), (40)
> @@ -743,11 +747,18 @@ country LC: DFS-ETSI
>  (5490 - 5710 @ 160), (30), DFS
>  (5735 - 5815 @ 80), (30)
> 
> +
> +# Source:
> +# https://www.ofcomnet.ch/#/fatTable
> +# Note that the maximum transmitter power can be doubled for 5250-5710MHz
> if
> +# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
>  country LI: DFS-ETSI
>  (2402 - 2482 @ 40), (20)
> -    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> -    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> +    (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> +    (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>  (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
> +    # 60 GHz band channels 1-4, ref: Etsi En 302 567
> +    (57000 - 66000 @ 2160), (40)
> 
>  country LK: DFS-FCC
>  (2402 - 2482 @ 40), (20)
> -- 
> 2.18.0

Re: [PATCH] Update regulatory rules for Finland (FI) on 5GHz (SRD devices)

[Seth Forshee]

On Thu, Sep 06, 2018 at 04:59:15PM +0300, Jukka Pirinen wrote:
> Viestintävirasto 15 AM/2018 M
> Section 10 Non-specific short range devices
> https://www.finlex.fi/data/normit/32670/Regulation_15AM.pdf
> 
> Signed-off-by: Jukka Pirinen 

Applied, thanks!

Re: wireless-regdb: Update regulatory rules for Finland (FI) on 5GHz (SRD devices)

[Seth Forshee]

On Tue, Aug 28, 2018 at 01:32:25PM +0300, Jukka Pirinen wrote:
> Viestintävirasto 15 AM/2018 M
> 
> Section 10 Non-specific short range devices
> https://www.finlex.fi/data/normit/32670/Regulation_15AM.pdf

Thanks for the patch. It looks like it should be fine to add that range,
but there are a couple of problems. First, your patch has tabs replaced
with spaces and so it does not apply. Second, you must include a
Signed-off-by tag as specified in the CONTRIBUTING file.

Thanks,
Seth

> 
> 
> diff --git a/db.txt b/db.txt
> index 8cf7dee..7abb064 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -460,6 +460,8 @@ country FI: DFS-ETSI
> (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
> (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
> +# short range devices (ETSI EN 300 440-1)
> +(5725 - 5875 @ 80), (25 mW)
> # 60 GHz band channels 1-4, ref: Etsi En 302 567
> (57000 - 66000 @ 2160), (40)

Re: wireless-regdb: Update regulatory rules for Switzerland (CH), and Liechtenstein (LI) on 5GHz

[Seth Forshee]

On Sat, Aug 18, 2018 at 02:01:50PM +0200, Henrik Laxhuber wrote:
> [ My previous message didn't go through because I hadn't signed up to ]
> [   the wireless-regdb mailing list; I apologise if anyone receives   ]
> [ this message twice  ]

Thanks for the patch. However you forgot to include a Signed-off-by tag
(see the CONTRIBUTING file). Please also only include a description of
the patch in the commit message, any additional comments/questions can
be included in a cover letter.

Also one small comment about the changes below.

> As far as I could tell, the regulatory information for Switzerland and
> Liechtenstein did not match the information published by the national
> regulator. I have gone ahead and updated the information according to
> the 'National Frequency Allocation Strategy Table' [0] for both
> countries.
> 
> On a somewhat related note, are there any plans to properly support TPC?
> There are quite a few entries in the database where maximum transmission
> power could be increased when TPC is in use. Being able to set a
> different maximum antenna gain and/or EIRP when TCP is in use could be
> helpful in these cases. I guess what's holding this back is lacking
> driver support?

I haven't heard of any plans for supporting TPC in the kernel.

> PS: Since [0] can be cumbersome to navigate, I am also providing the
> direct links to the applicable tables. It's possible that these links
> will rot:
> 5150 - 5350 MHz: [1]
> 5470 - 5725 MHz: [2]
> 
> [0] https://www.ofcomnet.ch/#/fatTable
> [1] https://www.ofcomnet.ch/api/rir/1010/05
> [2] https://www.ofcomnet.ch/api/rir/1010/04
> ---
>  db.txt | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 8cf7dee..69cea85 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -265,10 +265,14 @@ country CF: DFS-FCC
>  (5490 - 5730 @ 40), (24), DFS
>  (5735 - 5835 @ 40), (30)
> 
> +# Source:
> +# https://www.ofcomnet.ch/#/fatTable
> +# Note that the maximum transmitter power can be doubled for 5250-5710MHz
> if
> +# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
>  country CH: DFS-ETSI
>  (2402 - 2482 @ 40), (20)
> -    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> -    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> +    (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI

This should also be changed to 5150-5250.

Thanks,
Seth

> +    (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>  (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
>  # 60 GHz band channels 1-4, ref: Etsi En 302 567
>  (57000 - 66000 @ 2160), (40)
> @@ -743,11 +747,18 @@ country LC: DFS-ETSI
>  (5490 - 5710 @ 160), (30), DFS
>  (5735 - 5815 @ 80), (30)
> 
> +
> +# Source:
> +# https://www.ofcomnet.ch/#/fatTable
> +# Note that the maximum transmitter power can be doubled for 5250-5710MHz
> if
> +# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
>  country LI: DFS-ETSI
>  (2402 - 2482 @ 40), (20)
> -    (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> -    (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> +    (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> +    (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>  (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
> +    # 60 GHz band channels 1-4, ref: Etsi En 302 567
> +    (57000 - 66000 @ 2160), (40)
> 
>  country LK: DFS-FCC
>  (2402 - 2482 @ 40), (20)
> -- 
> 2.18.0
> 

Re: [PATCH v2] wireless-regdb: update rules for Hungary (HU) on 2.4/5/60G, 5725-5875MHz

[Seth Forshee]

On Mon, Aug 13, 2018 at 07:40:19AM -0500, Seth Forshee wrote:
> On Sat, Jun 30, 2018 at 10:40:34PM +0200, bkil wrote:
> > * 2400-2483.5M: extend bounds
> > * 5150-5250M: extend bounds, add NO-OUTDOOR, no TPC so +3dB
> > * 5250-5350M: extend bounds, add NO-OUTDOOR
> > * 5470-5725M: extend bounds
> > * 5725-5875M: introduce, as EU SRD provisions have been implemented
> > * 57-66G: add NO-OUTDOOR
> > 
> > Freely available online references have been added hosted by the regulatory
> > body in Hungary, the National Media and Infocommunications Authority.
> > 
> > To refer to a specific section, you can grep for the frequency in question.
> > 
> > Translation key:
> > "Csak beltéri" / "Épületen belüli használatra korlátozott" = indoor only;
> > "Kültéri és beltéri" = both indoor and outdoor;
> > "Nem működő TPC esetén a maximális teljesítményjellemzők 3 dB-lel
> > csökkennek." = reduce max power specs by 3dB in case of no TPC;
> > "Rögzített kültéri telepítés nem megengedett" = no fixed outdoor install
> > 
> > Signed-off-by: bkil 
> 
> Applied, thanks!

Replied to the wrong message in the thread, to be clear what I applied
was the v3 patch.

Re: [PATCH v2] wireless-regdb: update rules for Hungary (HU) on 2.4/5/60G, 5725-5875MHz

[Seth Forshee]

On Sat, Jun 30, 2018 at 10:40:34PM +0200, bkil wrote:
> * 2400-2483.5M: extend bounds
> * 5150-5250M: extend bounds, add NO-OUTDOOR, no TPC so +3dB
> * 5250-5350M: extend bounds, add NO-OUTDOOR
> * 5470-5725M: extend bounds
> * 5725-5875M: introduce, as EU SRD provisions have been implemented
> * 57-66G: add NO-OUTDOOR
> 
> Freely available online references have been added hosted by the regulatory
> body in Hungary, the National Media and Infocommunications Authority.
> 
> To refer to a specific section, you can grep for the frequency in question.
> 
> Translation key:
> "Csak beltéri" / "Épületen belüli használatra korlátozott" = indoor only;
> "Kültéri és beltéri" = both indoor and outdoor;
> "Nem működő TPC esetén a maximális teljesítményjellemzők 3 dB-lel
> csökkennek." = reduce max power specs by 3dB in case of no TPC;
> "Rögzített kültéri telepítés nem megengedett" = no fixed outdoor install
> 
> Signed-off-by: bkil 

Applied, thanks!

Re: [PATCH v2] wireless-regdb: update rules for Hungary (HU) on 2.4/5/60G, 5725-5875MHz

[Seth Forshee]

On Sat, Jun 30, 2018 at 10:40:34PM +0200, bkil wrote:
> * 2400-2483.5M: extend bounds
> * 5150-5250M: extend bounds, add NO-OUTDOOR, no TPC so +3dB
> * 5250-5350M: extend bounds, add NO-OUTDOOR
> * 5470-5725M: extend bounds
> * 5725-5875M: introduce, as EU SRD provisions have been implemented
> * 57-66G: add NO-OUTDOOR
> 
> Freely available online references have been added hosted by the regulatory
> body in Hungary, the National Media and Infocommunications Authority.
> 
> To refer to a specific section, you can grep for the frequency in question.
> 
> Translation key:
> "Csak beltéri" / "Épületen belüli használatra korlátozott" = indoor only;
> "Kültéri és beltéri" = both indoor and outdoor;
> "Nem működő TPC esetén a maximális teljesítményjellemzők 3 dB-lel
> csökkennek." = reduce max power specs by 3dB in case of no TPC;
> "Rögzített kültéri telepítés nem megengedett" = no fixed outdoor install
> 
> Signed-off-by: bkil 

Apologies, I had started reviewing this a while back, but got distracted
and forgot to come back to it.

The changes look okay as far as I can tell. However the patch itself
seems to be corrupt -- one line is wrapped, and there are whitespace
problems. This is probably due to your mail client, I suggest using
git-send-email.

Can you try re-sending?

Thanks,
Seth

> ---
>  db.txt | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 8963c01..cadfe77 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -581,13 +581,24 @@ country HT: DFS-FCC
>   (5490 - 5730 @ 160), (24), DFS
>   (5735 - 5835 @ 80), (30)
> 
> +# 
> http://stir.nmhh.hu/?oldal=dokumentumGeneralo_rendeletelem_id=3=1
> +# 
> http://english.nmhh.hu/cikk/297/Eljarasi_tajekoztato_a_24_GHzes_es_az_5_GHzes_savban_mukodo_berendezesek_engedelyezeserol
> +# http://nmhh.hu/dokumentum/319/kis_hatotavolsagu_eszkozok_srdk.pdf
>  country HU: DFS-ETSI
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> - (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
> - # 60 GHz band channels 1-4, ref: Etsi En 302 567
> - (57000 - 66000 @ 2160), (40)
> + # ref: 2006/771/EK, (EU) 2017/1483, MSZ EN 300 328
> + # additionally: 100mW @ 10MHz channels, 50mW @ 5MHz (max. 10mW/MHz)
> + (2400 - 2483.5 @ 40), (20)
> + # ref: 2005/513/EK
> + # note: TPC not needed @ 5150-5250
> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> + # note: max would be +3dB with TPC @ 5250-5725
> + (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
> + (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
> + # ref: Short Range Devices (SRD) - 2006/771/EK, (EU) 2017/1483, MSZ
> EN 300 440, MSZ EN 302 064
> + (5725 - 5875 @ 80), (25 mW)
> + # 60 GHz band channels 1-4, "Fixed outdoor installation not allowed"
> + # ref: 2006/771/EK, (EU) 2017/1483, MSZ EN 302 567
> + (57000 - 66000 @ 2160), (40), NO-OUTDOOR
> 
>  country ID: DFS-JP
>   # ref: 
> http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
> -- 
> 2.7.4

[ANN] wireless-regdb: master-2018-05-31

[Seth Forshee]

A new release of wireless-regdb (master-2018-05-31) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2018.05.31.tar.gz

The short log of changes since the 2018-05-09 release is below.

Thanks,
Seth

---

Seth Forshee (6):
  wireless-regdb: Add 5725-5875 MHz rule for France (FR)
  wireless-regdb: Update rules for Panama (PA) and add 60 GHz rule
  wireless-regdb: Fix comparison of WmmRule with NoneType in python 3
  wireless-regdb: Fix iteration in create_wmms() for python 3
  wireless-regdb: Fix power limit in 5725-5785 GHz rule for France
  wireless-regdb: update regulatory database based on preceding changes

Re: [PATCH] wireless-regdb: Fix comparison of WmmRule with NoneType in python 3

[Seth Forshee]

On Fri, May 18, 2018 at 09:47:01AM -0500, Seth Forshee wrote:
> Python 3 gives errors as a result of the changes to add wmm
> rules since Permission.wmmrule can be set to None:
> 
>  TypeError: '<' not supported between instances of 'WmmRule' and 'NoneType'
> 
> To fix this, supply compairson methods for WmmRule instead of
> using the ones provided by attrs. Doing this means we also need
> to supply a __hash__ method.
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Applied.

Re: [PATCH] wireless-regdb: Update rules for Panama (PA) and add 60 GHz rule

[Seth Forshee]

On Fri, May 18, 2018 at 09:46:41AM -0500, Seth Forshee wrote:
> Updates are based on the information in
> http://www.asep.gob.pa/images/telecomunicaciones/Anexos/PNAF-dic2015.pdf.
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Applied.

[PATCH] wireless-regdb: Fix iteration in create_wmms() for python 3

[Seth Forshee]

The iteration in this function is over countries.itervalues(),
which is not compatible with python 3. Switch to iterating over
contries.values() instead.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db2fw.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db2fw.py b/db2fw.py
index 269325604ea3..0c0f030c0c63 100755
--- a/db2fw.py
+++ b/db2fw.py
@@ -29,7 +29,7 @@ def create_collections(countries):
 
 def create_wmms(countries):
 result = {}
-for c in countries.itervalues():
+for c in countries.values():
 for rule in c.permissions:
 if rule.wmmrule is not None:
 result[rule.wmmrule] = 1
-- 
2.17.0

[PATCH] wireless-regdb: Fix comparison of WmmRule with NoneType in python 3

[Seth Forshee]

Python 3 gives errors as a result of the changes to add wmm
rules since Permission.wmmrule can be set to None:

 TypeError: '<' not supported between instances of 'WmmRule' and 'NoneType'

To fix this, supply compairson methods for WmmRule instead of
using the ones provided by attrs. Doing this means we also need
to supply a __hash__ method.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 dbparse.py | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/dbparse.py b/dbparse.py
index 5cb8b3f13266..5fe752b4ff31 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -32,7 +32,7 @@ dfs_regions = {
 
 @total_ordering
 
-@attr.s(frozen=True)
+@attr.s(frozen=True, cmp=False)
 class WmmRule(object):
 vo_c = attr.ib()
 vi_c = attr.ib()
@@ -47,6 +47,22 @@ class WmmRule(object):
 return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
 self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap)
 
+def __eq__(self, other):
+if other is None:
+return False
+return (self._as_tuple() == other._as_tuple())
+
+def __ne__(self, other):
+return not (self == other)
+
+def __lt__(self, other):
+if other is None:
+return False
+return (self._as_tuple() < other._as_tuple())
+
+def __hash__(self):
+return hash(self._as_tuple())
+
 class FreqBand(object):
 def __init__(self, start, end, bw, comments=None):
 self.start = start
-- 
2.17.0

[PATCH] wireless-regdb: Update rules for Panama (PA) and add 60 GHz rule

[Seth Forshee]

Updates are based on the information in
http://www.asep.gob.pa/images/telecomunicaciones/Anexos/PNAF-dic2015.pdf.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/db.txt b/db.txt
index ed461a35b770..e3bbd374d096 100644
--- a/db.txt
+++ b/db.txt
@@ -963,11 +963,15 @@ country OM: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
 
+# Source:
+# http://www.asep.gob.pa/images/telecomunicaciones/Anexos/PNAF-dic2015.pdf
 country PA: DFS-FCC
-   (2402 - 2472 @ 40), (30)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (23), DFS, AUTO-BW
-   (5735 - 5835 @ 80), (30)
+   (2400 - 2483.5 @ 40), (36)
+   (5150 - 5250 @ 80), (36), AUTO-BW
+   (5250 - 5350 @ 80), (30), AUTO-BW
+   (5470 - 5725 @ 160), (30)
+   (5725 - 5850 @ 80), (36)
+   (57000 - 64000 @ 2160), (43)
 
 country PE: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.17.0

[PATCH] wireless-regdb: Add 5725-5875 MHz rule for France (FR)

[Seth Forshee]

Based on [1] and [2], use of short range devices in this range
is now permitted in France. Add a rule for this range, using the
power limit of 25 dBm as specified in these documents and in
ETSI EN 300 440.

[1] https://www.arcep.fr/uploads/tx_gsavis/14-1263.pdf
[2] https://www.arcep.fr/uploads/tx_gsavis/14-1263.pdf

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/db.txt b/db.txt
index fd73049596f2..eeff196e4aac 100644
--- a/db.txt
+++ b/db.txt
@@ -475,6 +475,8 @@ country FR: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+# short range devices (ETSI EN 300 440)
+   (5725 - 5875 @ 80), (25)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
-- 
2.17.0

[PATCH] iw: support reloading the regulatory database

[Seth Forshee]

Add a "iw reg reload" command, useful for testing new regulatory
databases.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 reg.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/reg.c b/reg.c
index cee0b5e8cedb..cadff3884c04 100644
--- a/reg.c
+++ b/reg.c
@@ -259,3 +259,13 @@ COMMAND(reg, get, NULL, NL80211_CMD_GET_REG, 0, CIB_PHY, 
handle_reg_get,
"Print out the devices' current regulatory domain information.");
 HIDDEN(reg, dump, NULL, NL80211_CMD_GET_REG, NLM_F_DUMP, CIB_NONE,
handle_reg_dump);
+
+static int handle_reg_reload(struct nl80211_state *state,
+struct nl_msg *msg,
+int argc, char **argv,
+enum id_input id)
+{
+   return 0;
+}
+COMMAND(reg, reload, NULL, NL80211_CMD_RELOAD_REGDB, 0, CIB_NONE,
+   handle_reg_reload, "Reload the kernel's regulatory database.");
-- 
2.17.0

[ANN] wireless-regdb: master-2018-05-09

[Seth Forshee]

A new release of wireless-regdb (master-2018-05-09) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2018.05.09.tar.gz

The short log of changes since the 2017-12-23 release is below.

Thanks,
Seth

---

Haim Dreyfuss (2):
  wireless-regdb: Add wmm rule for EEA and EFTA countries
  wireless-regdb: Parse wmm rule data

Matthias Schiffer (2):
  wireless-regdb: do not rely on sorting of dict keys in conversion scripts
  wireless-regdb: make scripts compatible with Python 3

Seth Forshee (2):
  wireless-regdb: Update rules for QA and add 5 GHz and 60 GHz rules
  wireless-regdb: update regulatory database based on preceding changes

Re: [PATCH v2 1/2] wireless-regdb: Add wmm rule for EEA and EFTA countries

[Seth Forshee]

On Thu, May 03, 2018 at 06:58:22PM +0300, Haim Dreyfuss wrote:
> The ETSI EN 301 893 v211 (2017-05) standard defines a new channel
> access mechanism that all devices (WLAN and LAA) need to comply with.
> In previous versions the device was allowed by ETSI to implement
> 802.11 channel access mechanism based on a set of priority classes
> which are taken from 802.11.
> According to the new standard there might be some exception
> which require the EEA and the EFTA countries, which adhere
> ETSI rules, to follow more restrictive rules.
> In order to comply with the new standard introduced by ETSI, add
> wmmrule global item with the new ETSI channel mechanism rules.
> Also add wmmrule flag to EEA and EFTA countries.
> 
> Signed-off-by: Haim Dreyfuss 

That's looking better. I did some light testing and nothing blew up with
4.15 or 4.17.

Applied both patches, thanks!

Re: [wireless-regdb] [PATCH 2/2] wireless-regdb: Parse wmm rule data

[Seth Forshee]

On Tue, May 01, 2018 at 11:19:21PM +0200, Johannes Berg wrote:
> On Tue, 2018-05-01 at 15:02 -0500, Seth Forshee wrote:
> > 
> > > +import attr
> > 
> > I'm a little hesitant to add use of non-standard libraries if it isn't
> > necessary, as some distros have traditionally built the regdb from
> > source (not sure how practical that is after the db-as-firmware changes
> > though). Do we lose anything critical if we don't use attr?
> 
> I probably suggested the use of attr. It's super useful, for things like
> this:
> 
> > > +@attr.s(frozen=True)
> > > +class WmmRule(object):
> > > +vo_c = attr.ib()
> > > +vi_c = attr.ib()
> > > +be_c = attr.ib()
> > > +bk_c = attr.ib()
> > > +vo_ap = attr.ib()
> > > +vi_ap = attr.ib()
> > > +be_ap = attr.ib()
> > > +bk_ap = attr.ib()
> > > +
> > > +def _as_tuple(self):
> > > +return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
> > > +self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap)
> 
> Spelling this out as a real object with all the __repr__ and comparisons
> etc. gets far more verbose.
> 
> While we can get rid of it in theory, it's a ~100KiB package without any
> further dependencies, and the code is better off for it.
> 
> Ultimately it's your decision, but I suspect that python is already such
> a big dependency that adding this library is in the noise.

I'm more thinking that for e.g. Debian if attr is installed via pip and
not a distro package then that might be a problem for their package
builds. But let's go ahead and leave it, if there's fallout we can
figure that out later.

Thanks,
Seth

Re: [PATCH 2/2] wireless-regdb: Parse wmm rule data

[Seth Forshee]

On Tue, May 01, 2018 at 04:36:12PM +0300, Haim Dreyfuss wrote:
> Add code to parse wmm rule data.
> Also write it to the the regulatory.db fw file
> 
> Signed-off-by: Haim Dreyfuss 

This patch doesn't seem to be based off the tip of master and has
conflicts. Generally they look easy to resolve, but I also have a few
other comments, below.

> ---
>  db2fw.py   |  31 +++--
>  dbparse.py | 111 
> +++--
>  2 files changed, 136 insertions(+), 6 deletions(-)
> 
> diff --git a/db2fw.py b/db2fw.py
> index 7b2b141..6d0ae5f 100755
> --- a/db2fw.py
> +++ b/db2fw.py
> @@ -5,6 +5,7 @@ import struct
>  import hashlib
>  from dbparse import DBParser
>  import sys
> +from math import log
>  
>  MAGIC = 0x52474442
>  VERSION = 20
> @@ -26,6 +27,13 @@ def create_collections(countries):
>  result[(c.permissions, c.dfs_region)] = 1
>  return result.keys()
>  
> +def create_wmms(countries):
> +result = {}
> +for c in countries.itervalues():
> +for rule in c.permissions:
> +if rule.wmmrule is not None:
> +result[rule.wmmrule] = 1
> +return result.keys()

See recent updates for python 3, should use list(result) instead.

>  def be32(output, val):
>  output.write(struct.pack('>I', val))
> @@ -63,6 +71,8 @@ rules = create_rules(countries)
>  rules.sort(cmp=lambda x, y: cmp(x.freqband, y.freqband))
>  collections = create_collections(countries)
>  collections.sort(cmp=lambda x, y: cmp(x[0][0].freqband, y[0][0].freqband))
> +wmms = create_wmms(countries)
> +wmms.sort(cmp=lambda x, y: cmp(x.vo_c, y.vo_c))

See the recent patch "wireless-regdb: do not rely on sorting of dict
keys in conversion scripts". Let's do likewise to ensure sort order is
consistent across python versions.

>  
>  output = StringIO()
>  
> @@ -79,10 +89,19 @@ for alpha2 in countrynames:
>  country_ptrs[alpha2] = PTR(output)
>  output.write('\x00' * 4)
>  
> +wmmdb = {}
> +for w in wmms:
> +assert output.tell() & 3 == 0
> +wmmdb[w] = output.tell() >> 2
> +for r in w._as_tuple():
> +ecw = int(log(r[0] + 1, 2)) << 4 | int(log(r[1] + 1, 2))
> +ac = (ecw, r[2],r[3])
> +output.write(struct.pack('>BBH', *ac))
> +
>  reg_rules = {}
>  flags = 0
>  for reg_rule in rules:
> -freq_range, power_rule = reg_rule.freqband, reg_rule.power
> +freq_range, power_rule, wmm_rule = reg_rule.freqband, reg_rule.power, 
> reg_rule.wmmrule
>  reg_rules[reg_rule] = output.tell()
>  assert power_rule.max_ant_gain == 0
>  flags = 0
> @@ -102,13 +121,19 @@ for reg_rule in rules:
>  cac_timeout = 0 # TODO
>  if not (flags & 1<<2):
>  cac_timeout = 0
> -if cac_timeout:
> +if cac_timeout or wmm_rule:
> +rule_len += 2
> +if wmm_rule is not None:
>  rule_len += 2
>  output.write(struct.pack('>BBHIII', rule_len, flags, power_rule.max_eirp 
> * 100,
>   freq_range.start * 1000, freq_range.end * 1000, 
> freq_range.maxbw * 1000,
>   ))
> -if cac_timeout:
> +if rule_len > 16:
>  output.write(struct.pack('>H', cac_timeout))
> +
> +if rule_len > 18:
> +be16(output, wmmdb[wmm_rule])
> +
>  while rule_len % 4:
>  output.write('\0')
>  rule_len += 1
> diff --git a/dbparse.py b/dbparse.py
> index b735b6a..409fbb8 100755
> --- a/dbparse.py
> +++ b/dbparse.py
> @@ -1,6 +1,9 @@
>  #!/usr/bin/env python
>  
>  import sys, math
> +from math import ceil, log
> +from collections import defaultdict, OrderedDict
> +import attr

I'm a little hesitant to add use of non-standard libraries if it isn't
necessary, as some distros have traditionally built the regdb from
source (not sure how practical that is after the db-as-firmware changes
though). Do we lose anything critical if we don't use attr?

>  
>  # must match  enum nl80211_reg_rule_flags
>  
> @@ -25,6 +28,21 @@ dfs_regions = {
>  'DFS-JP':3,
>  }
>  
> +@attr.s(frozen=True)
> +class WmmRule(object):
> +vo_c = attr.ib()
> +vi_c = attr.ib()
> +be_c = attr.ib()
> +bk_c = attr.ib()
> +vo_ap = attr.ib()
> +vi_ap = attr.ib()
> +be_ap = attr.ib()
> +bk_ap = attr.ib()
> +
> +def _as_tuple(self):
> +return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
> +self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap)
> +
>  class FreqBand(object):
>  def __init__(self, start, end, bw, comments=None):
>  self.start = start
> @@ -77,11 +95,13 @@ class FlagError(Exception):
>  self.flag = flag
>  
>  class Permission(object):
> -def __init__(self, freqband, power, flags):
> +def __init__(self, freqband, power, flags, wmmrule):
>  assert isinstance(freqband, FreqBand)
>  assert isinstance(power, PowerRestriction)
> +assert isinstance(wmmrule, WmmRule) or wmmrule is None
>  self.freqband = 

Re: [PATCH v2 2/2] wireless-regdb: make scripts compatible with Python 3

[Seth Forshee]

On Thu, Mar 22, 2018 at 03:44:00PM +0100, Matthias Schiffer wrote:
> On 03/22/2018 03:05 PM, Seth Forshee wrote:
> > On Sun, Feb 04, 2018 at 12:36:54AM +0100, Matthias Schiffer wrote:
> >> When playing with the generation scripts for OpenWrt development, I noticed
> >> that these scripts still required Python 2. Future-proof them by replacing
> >> deprecated functions with new Python 3 compatible variants. The result
> >> works with both Python 2.7 and Python 3.x; older Python 2.x releases are
> >> not supported anymore.
> >>
> >> regulatory.db and regulatory.bin are unchanged and reproducible across
> >> Python versions. Note that there is no stable release of m2crypto for
> >> Python 3 yet; I used the current development branch for testing.
> > 
> > I can't say I'm all that knowledgable about Python 2 to Python 3
> > conversion, but as far as I can tell this looks okay. It does seem to
> > work for me running with both Python 2 and Python 3.
> > 
> > One question below though, mostly just to satisfy my curiousity.
> > 
> >> Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
> >> ---
> >>
> >> v2: explicitly open input file with UTF-8 encoding; otherwise the scripts
> >> will fail without a UTF-8 locale set in the environment
> >>
> >>
> >>  db2bin.py  | 22 -
> >>  db2fw.py   | 28 +++---
> >>  dbparse.py | 81 
> >> +-
> >>  3 files changed, 74 insertions(+), 57 deletions(-)
> >>
> >> diff --git a/db2bin.py b/db2bin.py
> >> index ae5f064..28cd7d2 100755
> >> --- a/db2bin.py
> >> +++ b/db2bin.py
> >> @@ -1,6 +1,6 @@
> >>  #!/usr/bin/env python
> >>  
> >> -from cStringIO import StringIO
> >> +from io import BytesIO, open
> >>  import struct
> >>  import hashlib
> >>  from dbparse import DBParser
> >> @@ -10,21 +10,21 @@ MAGIC = 0x52474442
> >>  VERSION = 19
> >>  
> >>  if len(sys.argv) < 3:
> >> -print 'Usage: %s output-file input-file [key-file]' % sys.argv[0]
> >> +print('Usage: %s output-file input-file [key-file]' % sys.argv[0])
> >>  sys.exit(2)
> >>  
> >>  def create_rules(countries):
> >>  result = {}
> >> -for c in countries.itervalues():
> >> +for c in countries.values():
> >>  for rule in c.permissions:
> >>  result[rule] = 1
> >> -return result.keys()
> >> +return list(result)
> > 
> > Here and elsewhere, to get a list of the keys from a dictionary, we use
> > list(dict). Experimentally I find this works, but I haven't been able to
> > find anything which actually tells me that this is the defined behavior,
> > and examples seem to prefer list(dict.keys()). I'm curious why this is
> > guaranteed to provide a lsit of dictionary keys, and why you've done
> > that rather than list(dict.keys()) (I'll grant that the scripts
> > elsewhere use list(dict), so maybe you were just being consistent with
> > that).
> 
> list(dict) is the recommended syntax in
> http://python-future.org/compatible_idioms.html#dict-keys-values-items-as-a-list

Thanks for the explanation. I've applied both patches.

Seth

Re: [PATCH v2 2/2] wireless-regdb: make scripts compatible with Python 3

[Seth Forshee]

On Sun, Feb 04, 2018 at 12:36:54AM +0100, Matthias Schiffer wrote:
> When playing with the generation scripts for OpenWrt development, I noticed
> that these scripts still required Python 2. Future-proof them by replacing
> deprecated functions with new Python 3 compatible variants. The result
> works with both Python 2.7 and Python 3.x; older Python 2.x releases are
> not supported anymore.
> 
> regulatory.db and regulatory.bin are unchanged and reproducible across
> Python versions. Note that there is no stable release of m2crypto for
> Python 3 yet; I used the current development branch for testing.

I can't say I'm all that knowledgable about Python 2 to Python 3
conversion, but as far as I can tell this looks okay. It does seem to
work for me running with both Python 2 and Python 3.

One question below though, mostly just to satisfy my curiousity.

> Signed-off-by: Matthias Schiffer 
> ---
> 
> v2: explicitly open input file with UTF-8 encoding; otherwise the scripts
> will fail without a UTF-8 locale set in the environment
> 
> 
>  db2bin.py  | 22 -
>  db2fw.py   | 28 +++---
>  dbparse.py | 81 
> +-
>  3 files changed, 74 insertions(+), 57 deletions(-)
> 
> diff --git a/db2bin.py b/db2bin.py
> index ae5f064..28cd7d2 100755
> --- a/db2bin.py
> +++ b/db2bin.py
> @@ -1,6 +1,6 @@
>  #!/usr/bin/env python
>  
> -from cStringIO import StringIO
> +from io import BytesIO, open
>  import struct
>  import hashlib
>  from dbparse import DBParser
> @@ -10,21 +10,21 @@ MAGIC = 0x52474442
>  VERSION = 19
>  
>  if len(sys.argv) < 3:
> -print 'Usage: %s output-file input-file [key-file]' % sys.argv[0]
> +print('Usage: %s output-file input-file [key-file]' % sys.argv[0])
>  sys.exit(2)
>  
>  def create_rules(countries):
>  result = {}
> -for c in countries.itervalues():
> +for c in countries.values():
>  for rule in c.permissions:
>  result[rule] = 1
> -return result.keys()
> +return list(result)

Here and elsewhere, to get a list of the keys from a dictionary, we use
list(dict). Experimentally I find this works, but I haven't been able to
find anything which actually tells me that this is the defined behavior,
and examples seem to prefer list(dict.keys()). I'm curious why this is
guaranteed to provide a lsit of dictionary keys, and why you've done
that rather than list(dict.keys()) (I'll grant that the scripts
elsewhere use list(dict), so maybe you were just being consistent with
that).

>  def create_collections(countries):
>  result = {}
> -for c in countries.itervalues():
> +for c in countries.values():
>  result[c.permissions] = 1
> -return result.keys()
> +return list(result)
>  
>  
>  def be32(output, val):
> @@ -49,9 +49,9 @@ class PTR(object):
>  return self._offset
>  
>  p = DBParser()
> -countries = p.parse(file(sys.argv[2]))
> +countries = p.parse(open(sys.argv[2], 'r', encoding='utf-8'))
>  
> -countrynames = countries.keys()
> +countrynames = list(countries)
>  countrynames.sort()
>  
>  power = []
> @@ -67,7 +67,7 @@ rules.sort()
>  collections = create_collections(countries)
>  collections.sort()
>  
> -output = StringIO()
> +output = BytesIO()
>  
>  # struct regdb_file_header
>  be32(output, MAGIC)
> @@ -118,7 +118,7 @@ reg_country_ptr.set()
>  for alpha2 in countrynames:
>  coll = countries[alpha2]
>  # struct regdb_file_reg_country
> -output.write(struct.pack('>ccxBI', str(alpha2[0]), str(alpha2[1]), 
> coll.dfs_region, reg_rules_collections[coll.permissions]))
> +output.write(struct.pack('>BBxBI', alpha2[0], alpha2[1], 
> coll.dfs_region, reg_rules_collections[coll.permissions]))
>  
>  
>  if len(sys.argv) > 3:
> @@ -143,5 +143,5 @@ if len(sys.argv) > 3:
>  else:
>  siglen.set(0)
>  
> -outfile = open(sys.argv[1], 'w')
> +outfile = open(sys.argv[1], 'wb')
>  outfile.write(output.getvalue())
> diff --git a/db2fw.py b/db2fw.py
> index 630e4d6..91b88d3 100755
> --- a/db2fw.py
> +++ b/db2fw.py
> @@ -1,6 +1,6 @@
>  #!/usr/bin/env python
>  
> -from cStringIO import StringIO
> +from io import BytesIO, open
>  import struct
>  import hashlib
>  from dbparse import DBParser
> @@ -10,21 +10,21 @@ MAGIC = 0x52474442
>  VERSION = 20
>  
>  if len(sys.argv) < 3:
> -print 'Usage: %s output-file input-file' % sys.argv[0]
> +print('Usage: %s output-file input-file' % sys.argv[0])
>  sys.exit(2)
>  
>  def create_rules(countries):
>  result = {}
> -for c in countries.itervalues():
> +for c in countries.values():
>  for rule in c.permissions:
>  result[rule] = 1
> -return result.keys()
> +return list(result)
>  
>  def create_collections(countries):
>  result = {}
> -for c in countries.itervalues():
> +for c in countries.values():
>  result[(c.permissions, c.dfs_region)] = 1
> -return result.keys()
> +

Re: [PATCH v2 11/13] cfg80211: read wmm rules from regulatory database

[Seth Forshee]

On Mon, Feb 19, 2018 at 02:30:33PM +0100, Johannes Berg wrote:
> On Mon, 2018-02-19 at 14:48 +0200, Luca Coelho wrote:
> > From: Haim Dreyfuss 
> > 
> > ETSI EN 301 893 v211 (2017-05) standard defines a new channel access
> > mechanism that all devices (WLAN and LAA) need to comply with.
> > The regulatory database can now be loaded into the kernel and also
> > has the option to load optional data.
> > In order to be able to comply with ETSI standard, we add wmm_rule into
> > regulatory rule and add the option to read its value from the regulatory
> > database.
> 
> Seth, this is going to come with an update to the regdb as well. I'd
> appreciate if you could take a look.

I think it looks okay, but I guess there will be new patches so I will
take another look then. Is there an example of the db.txt updates for
the WMM rules?

Seth

[ANN] wireless-regdb: master-2017-12-23

[Seth Forshee]

A new release of wireless-regdb (master-2017-12-23) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2017.12.23.tar.gz

Note that this is the first release to include the new regulatory
database format, supporting direct loading of the database by the
kernel. The short log of changes since the 2017-03-07 release is below.

Thanks,
Seth

---

Andreas Mohr (1):
  wireless-regdb: reduce power level limit of KR (Korea) 802.11b/g/n to the 
certification-requested "20mW" (13dBm).

Aron Rosenberg (1):
  Set NO-OUTDOOR Flag on Canada 5Ghz 5150 to 5250

Chen-Yu Tsai (2):
  wireless-regdb: Update regulatory document references for Taiwan (TW)
  wireless-regdb: Add 60 GHz rule for Taiwan (TW)

Edwin Steele (1):
  wireless-regdb: Update rules for Turkey 5ghz

Johannes Berg (1):
  regdb: write firmware file format (version code 20)

Seth Forshee (8):
  wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)
  wireless-regdb: Update rules for Denmark (DK)
  wireless-regdb: Restore generation of old format database files
  wireless-regdb: Add sforshee's x509 certificate
  wireless-regdb: Better support for generating public certificates
  wireless-regdb: Install regulatory.db and regulatory.db.p7s to 
/lib/firmware
  wireless-regdb: Document regulatory.db in the manual page
  wireless-regdb: update regulatory database based on preceding changes

Sven Eckelmann (1):
  wireless-regdb: Update regulatory rules for Singapore (SG)

Xose Vazquez Perez (1):
  wireless-regdb: add Short Range Devices (SRD) (ETSI EN 300 440) for Spain

Re: [PATCH] wireless-regdb: Update rules for Denmark (DK)

[Seth Forshee]

On Fri, Dec 22, 2017 at 10:38:08AM -0600, Seth Forshee wrote:
> Refresh the frequency ranges and power limits based on the
> following sources:
> 
>  
> https://erhvervsstyrelsen.dk/sites/default/files/007_interface-datanet_5-6_ghz.pdf.pdf
>  https://erhvervsstyrelsen.dk/sites/default/files/radiograenseflader-63.pdf
> 
> Cc: Per Mejdal Rasmussen <p...@its.aau.dk>
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Applied.

[PATCH] wireless-regdb: Update rules for Denmark (DK)

[Seth Forshee]

Refresh the frequency ranges and power limits based on the
following sources:

 
https://erhvervsstyrelsen.dk/sites/default/files/007_interface-datanet_5-6_ghz.pdf.pdf
 https://erhvervsstyrelsen.dk/sites/default/files/radiograenseflader-63.pdf

Cc: Per Mejdal Rasmussen <p...@its.aau.dk>
Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/db.txt b/db.txt
index 10c84ee1ca5d..990abf997a12 100644
--- a/db.txt
+++ b/db.txt
@@ -371,13 +371,16 @@ country DE: DFS-ETSI
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
 
+# Sources:
+# 5GHz: 
https://erhvervsstyrelsen.dk/sites/default/files/007_interface-datanet_5-6_ghz.pdf.pdf
+# 60GHz: 
https://erhvervsstyrelsen.dk/sites/default/files/radiograenseflader-63.pdf
 country DK: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5490 - 5710 @ 160), (27), DFS
-   # 60 GHz band channels 1-4, ref: Etsi En 302 567
-   (57000 - 66000 @ 2160), (40)
+   (2400 - 2483.5 @ 40), (20)
+   (5150 - 5250 @ 80), (23), AUTO-BW
+   (5250 - 5350 @ 80), (20), DFS, AUTO-BW
+   (5470 - 5725 @ 160), (27), DFS
+   # 60 GHz band channels 1-4 (ETSI EN 302 567)
+   (57000 - 66000 @ 2160), (40), NO-OUTDOOR
 
 # Source:
 # 
http://www.ntrcdom.org/index.php?option=com_content=category=blog=10=55
-- 
2.14.1

[PATCH 2/6] wireless-regdb: Restore generation of old format database files

[Seth Forshee]

Johannes removed generation and installation of these files when
adding support for the new database format. We need to keep
generating these files to support distros still using CRDA, so
restore support for building and installing these files in the
makefile.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 Makefile | 35 +++
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index e708982a453d..9532c29a1dc2 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,7 @@
 # Install prefix
 PREFIX ?= /usr
+CRDA_PATH ?= $(PREFIX)/lib/crda
+CRDA_KEY_PATH ?= $(CRDA_PATH)/pubkeys
 
 MANDIR ?= $(PREFIX)/share/man/
 
@@ -28,26 +30,33 @@ REGDB_AUTHOR ?= $(shell if [ -f $(DISTRO_PRIVKEY) ]; then \
fi)
 
 REGDB_PRIVKEY ?= ~/.wireless-regdb-$(REGDB_AUTHOR).key.priv.pem
+REGDB_PUBKEY ?= $(REGDB_AUTHOR).key.pub.pem
 REGDB_PUBCERT ?= $(REGDB_AUTHOR).x509.pem
 
+REGDB_UPSTREAM_PUBKEY ?= sforshee.key.pub.pem
+
 REGDB_CHANGED = $(shell $(SHA1SUM) -c --status sha1sum.txt >/dev/null 2>&1; \
 if [ $$? -ne 0 ]; then \
-echo maintainer-clean $(REGDB_PUBCERT); \
+echo maintainer-clean $(REGDB_PUBKEY) $(REGDB_PUBCERT); \
 fi)
 
 .PHONY: all clean mrproper install maintainer-clean install-distro-key
 
-all: $(REGDB_CHANGED) regulatory.db.p7s sha1sum.txt
+all: $(REGDB_CHANGED) regulatory.bin sha1sum.txt regulatory.db.p7s
 
 clean:
@rm -f *.pyc *.gz
 
 maintainer-clean: clean
-   @rm -f regulatory.db regulatory.db.p7s
+   @rm -f regulatory.bin regulatory.db regulatory.db.p7s
 
 mrproper: clean maintainer-clean
-   @echo Removed public key, regulatory.db* and compressed man pages
-   @rm -f $(REGDB_PUBCERT) .custom
+   @echo Removed public key, regulatory.bin, regulatory.db* and compressed 
man pages
+   @rm -f $(REGDB_PUBKEY) $(REGDB_PUBCERT) .custom
+
+regulatory.bin: db.txt $(REGDB_PRIVKEY) $(REGDB_PUBKEY)
+   @echo Generating $@ digitally signed by $(REGDB_AUTHOR)...
+   ./db2bin.py regulatory.bin db.txt $(REGDB_PRIVKEY)
 
 regulatory.db: db.txt db2fw.py
@echo "Generating $@"
@@ -64,6 +73,10 @@ regulatory.db.p7s: regulatory.db $(REGDB_PRIVKEY) 
$(REGDB_PUBCERT)
 sha1sum.txt: db.txt
sha1sum $< > $@
 
+$(REGDB_PUBKEY): $(REGDB_PRIVKEY)
+   @echo "Generating public key for $(REGDB_AUTHOR)..."
+   openssl rsa -in $(REGDB_PRIVKEY) -out $(REGDB_PUBKEY) -pubout -outform 
PEM
+
 $(REGDB_PUBCERT): $(REGDB_PRIVKEY)
@echo "Generating certificate for $(REGDB_AUTHOR)..."
@openssl req -config regulatory.openssl.conf \
@@ -103,7 +116,13 @@ install-distro-key: maintainer-clean $(DISTRO_PRIVKEY)
 #  make maintainer-clean
 #  make
 #  sudo make install
-install: regulatory.db.5.gz
-   install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.db
+install: regulatory.bin.5.gz regulatory.db.5.gz
+   install -m 755 -d $(DESTDIR)/$(CRDA_PATH)
+   install -m 755 -d $(DESTDIR)/$(CRDA_KEY_PATH)
+   if [ -f .custom ]; then \
+   install -m 644 -t $(DESTDIR)/$(CRDA_KEY_PATH)/ $(shell cat 
.custom); \
+   fi
+   install -m 644 -t $(DESTDIR)/$(CRDA_KEY_PATH)/ $(REGDB_UPSTREAM_PUBKEY)
+   install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.bin regulatory.db
install -m 755 -d $(DESTDIR)/$(MANDIR)/man5/
-   install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.db.5.gz
+   install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.bin.5.gz
-- 
2.14.1

[PATCH 0/6] wireless-regdb: Support for new binary database format

[Seth Forshee]

This series starts with Johannes' patch for generating regulatory
databases using the new format and adds various fixes and pieces which
were missing such as installation to the firmware path, manual page
updates, etc. It also restores support for the older database format to
maintain compatibility with using CRDA on older kernels.

I've tested the results with 4.15 and things look to be working. I want
to apply this in the next couple of days and get a new release out, so
please let me know soon if you seen any issues.

Thanks,
Seth

Johannes Berg (1):
  regdb: write firmware file format (version code 20)

Seth Forshee (5):
  wireless-regdb: Restore generation of old format database files
  wireless-regdb: Add sforshee's x509 certificate
  wireless-regdb: Better support for generating public certificates
  wireless-regdb: Install regulatory.db and regulatory.db.p7s to
/lib/firmware
  wireless-regdb: Document regulatory.db in the manual page

 Makefile  |  37 +++
 README|   4 +-
 db2fw.py  | 133 ++
 gen-pubcert.sh|  18 
 regulatory.bin.5  |  32 +
 regulatory.db.5   |   1 +
 sforshee.x509.pem |  17 +++
 7 files changed, 220 insertions(+), 22 deletions(-)
 create mode 100755 db2fw.py
 create mode 100755 gen-pubcert.sh
 create mode 100644 regulatory.db.5
 create mode 100644 sforshee.x509.pem

[PATCH 6/6] wireless-regdb: Document regulatory.db in the manual page

[Seth Forshee]

Add information about regulatory.db to the regulatory.bin man
page, and alias the regulatory.db man page to refer to the page
for regulatory.bin.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 Makefile |  2 +-
 regulatory.bin.5 | 32 ++--
 regulatory.db.5  |  1 +
 3 files changed, 24 insertions(+), 11 deletions(-)
 create mode 100644 regulatory.db.5

diff --git a/Makefile b/Makefile
index 1e8e84c64149..2f1ed93e0e15 100644
--- a/Makefile
+++ b/Makefile
@@ -126,4 +126,4 @@ install: regulatory.bin.5.gz regulatory.db.5.gz
install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.bin
install -m 644 -t $(DESTDIR)/$(FIRMWARE_PATH) regulatory.db 
regulatory.db.p7s
install -m 755 -d $(DESTDIR)/$(MANDIR)/man5/
-   install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.bin.5.gz
+   install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.bin.5.gz 
regulatory.db.5.gz
diff --git a/regulatory.bin.5 b/regulatory.bin.5
index 430c65c9ce6d..b1862cd1756d 100644
--- a/regulatory.bin.5
+++ b/regulatory.bin.5
@@ -1,6 +1,6 @@
-.TH regulatory.bin 5 "23 January 2009" "regulatory.bin" "Linux"
+.TH regulatory.bin 5 "21 December 2017" "regulatory.bin" "Linux"
 .SH NAME
-regulatory.bin \- The Linux wireless regulatory database
+regulatory.bin, regulatory.db \- The Linux wireless regulatory database
 
 .ad l
 .in +8
@@ -9,24 +9,36 @@ regulatory.bin \- The Linux wireless regulatory database
 .SS
 .SH Description
 .B regulatory.bin
-is the file used by the Linux wireless subsystem to keep its regulatory
-database information. It is read by
+and
+.B regulatory.db
+are the files used by the Linux wireless subsystem to keep its regulatory
+database information.
+.PP
+.B regulatory.bin
+is read by
 .B crda
 upon the Linux kernel's request for regulatory information for a specific
-ISO / IEC 3166 alpha2 country code. The regulatory database is kept in
-a small binary format for size and code efficiency. The
+ISO / IEC 3166 alpha2 country code.
+.PP
+.B regulatory.db
+is a newer, extensible database format which (since Linux 4.15) is read
+by the kernel directly as a firmware file.
+
+The regulatory database is kept in a small binary format for size and code
+efficiency. The
 .B regulatory.bin
 file can be parsed and read in human format by using the
 .B regdbdump
-command. The
-.B regulatory.bin
-file should be updated upon regulatory changes or corrections.
+command. The regulatory database files should be updated upon regulatory
+changes or corrections.
 
 .SH Upkeeping
 The regulatory database is maintained by the community as such
 you are encouraged to send any corrections or updates to the
-linux-wireless mailing list:
+linux-wireless and wireless-regdb mailing lists:
 .B linux-wireless@vger.kernel.org
+and
+.B wireless-re...@lists.infradead.org
 
 .SH SEE ALSO
 .BR regdbdump (8)
diff --git a/regulatory.db.5 b/regulatory.db.5
new file mode 100644
index ..6c8aae374621
--- /dev/null
+++ b/regulatory.db.5
@@ -0,0 +1 @@
+.so man5/regulatory.bin.5.gz
-- 
2.14.1

[PATCH 5/6] wireless-regdb: Install regulatory.db and regulatory.db.p7s to /lib/firmware

[Seth Forshee]

regulatory.db is being installed to the CRDA path, however the
kernel expects it to be in /lib/firmware. Install it to the
proper location. Also install the detached signature, which is
needed for the kernel to check verify the database authenticity.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 044251f64785..1e8e84c64149 100644
--- a/Makefile
+++ b/Makefile
@@ -2,6 +2,7 @@
 PREFIX ?= /usr
 CRDA_PATH ?= $(PREFIX)/lib/crda
 CRDA_KEY_PATH ?= $(CRDA_PATH)/pubkeys
+FIRMWARE_PATH ?= /lib/firmware
 
 MANDIR ?= $(PREFIX)/share/man/
 
@@ -117,10 +118,12 @@ install-distro-key: maintainer-clean $(DISTRO_PRIVKEY)
 install: regulatory.bin.5.gz regulatory.db.5.gz
install -m 755 -d $(DESTDIR)/$(CRDA_PATH)
install -m 755 -d $(DESTDIR)/$(CRDA_KEY_PATH)
+   install -m 755 -d $(DESTDIR)/$(FIRMWARE_PATH)
if [ -f .custom ]; then \
install -m 644 -t $(DESTDIR)/$(CRDA_KEY_PATH)/ $(shell cat 
.custom); \
fi
install -m 644 -t $(DESTDIR)/$(CRDA_KEY_PATH)/ $(REGDB_UPSTREAM_PUBKEY)
-   install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.bin regulatory.db
+   install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.bin
+   install -m 644 -t $(DESTDIR)/$(FIRMWARE_PATH) regulatory.db 
regulatory.db.p7s
install -m 755 -d $(DESTDIR)/$(MANDIR)/man5/
install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.bin.5.gz
-- 
2.14.1

[PATCH 1/6] regdb: write firmware file format (version code 20)

[Seth Forshee]

From: Johannes Berg <johannes.b...@intel.com>

TODO: clean up the Makefile stuff ...

Signed-off-by: Johannes Berg <johannes.b...@intel.com>
Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 Makefile |  53 -
 README   |   4 +-
 db2fw.py | 133 +++
 3 files changed, 160 insertions(+), 30 deletions(-)
 create mode 100755 db2fw.py

diff --git a/Makefile b/Makefile
index 907ff282fc92..e708982a453d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,5 @@
 # Install prefix
 PREFIX ?= /usr
-CRDA_PATH ?= $(PREFIX)/lib/crda
-CRDA_KEY_PATH ?= $(CRDA_PATH)/pubkeys
 
 MANDIR ?= $(PREFIX)/share/man/
 
@@ -30,39 +28,47 @@ REGDB_AUTHOR ?= $(shell if [ -f $(DISTRO_PRIVKEY) ]; then \
fi)
 
 REGDB_PRIVKEY ?= ~/.wireless-regdb-$(REGDB_AUTHOR).key.priv.pem
-REGDB_PUBKEY ?= $(REGDB_AUTHOR).key.pub.pem
-
-REGDB_UPSTREAM_PUBKEY ?= sforshee.key.pub.pem
+REGDB_PUBCERT ?= $(REGDB_AUTHOR).x509.pem
 
 REGDB_CHANGED = $(shell $(SHA1SUM) -c --status sha1sum.txt >/dev/null 2>&1; \
 if [ $$? -ne 0 ]; then \
-echo maintainer-clean $(REGDB_PUBKEY); \
+echo maintainer-clean $(REGDB_PUBCERT); \
 fi)
 
 .PHONY: all clean mrproper install maintainer-clean install-distro-key
 
-all: $(REGDB_CHANGED) regulatory.bin sha1sum.txt
+all: $(REGDB_CHANGED) regulatory.db.p7s sha1sum.txt
 
 clean:
@rm -f *.pyc *.gz
 
 maintainer-clean: clean
-   @rm -f regulatory.bin
+   @rm -f regulatory.db regulatory.db.p7s
 
 mrproper: clean maintainer-clean
-   @echo Removed public key, regulatory.bin and compresed man pages
-   @rm -f $(REGDB_PUBKEY) .custom
+   @echo Removed public key, regulatory.db* and compressed man pages
+   @rm -f $(REGDB_PUBCERT) .custom
+
+regulatory.db: db.txt db2fw.py
+   @echo "Generating $@"
+   ./db2fw.py regulatory.db db.txt
 
-regulatory.bin: db.txt $(REGDB_PRIVKEY) $(REGDB_PUBKEY)
-   @echo Generating $@ digitally signed by $(REGDB_AUTHOR)...
-   ./db2bin.py regulatory.bin db.txt $(REGDB_PRIVKEY)
+regulatory.db.p7s: regulatory.db $(REGDB_PRIVKEY) $(REGDB_PUBCERT)
+   @echo "Signing regulatory.db (by $(REGDB_AUTHOR))..."
+   @openssl smime -sign \
+   -signer $(REGDB_PUBCERT) \
+   -inkey $(REGDB_PRIVKEY) \
+   -in $< -nosmimecap -binary \
+   -outform DER -out $@
 
 sha1sum.txt: db.txt
sha1sum $< > $@
 
-$(REGDB_PUBKEY): $(REGDB_PRIVKEY)
-   @echo "Generating public key for $(REGDB_AUTHOR)..."
-   openssl rsa -in $(REGDB_PRIVKEY) -out $(REGDB_PUBKEY) -pubout -outform 
PEM
+$(REGDB_PUBCERT): $(REGDB_PRIVKEY)
+   @echo "Generating certificate for $(REGDB_AUTHOR)..."
+   @openssl req -config regulatory.openssl.conf \
+   -key $(REGDB_PRIVKEY) -days 36500 -utf8 -nodes -batch \
+   -x509 -outform PEM -out $(REGDB_PUBCERT)
@echo $(REGDB_PUBKEY) > .custom
 
 
@@ -97,16 +103,7 @@ install-distro-key: maintainer-clean $(DISTRO_PRIVKEY)
 #  make maintainer-clean
 #  make
 #  sudo make install
-install: regulatory.bin.5.gz
-   install -m 755 -d $(DESTDIR)/$(CRDA_PATH)
-   install -m 755 -d $(DESTDIR)/$(CRDA_KEY_PATH)
-   if [ -f .custom ]; then \
-   install -m 644 -t $(DESTDIR)/$(CRDA_KEY_PATH)/ $(shell cat 
.custom); \
-   fi
-   install -m 644 -t $(DESTDIR)/$(CRDA_KEY_PATH)/ $(REGDB_UPSTREAM_PUBKEY)
-   install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.bin
+install: regulatory.db.5.gz
+   install -m 644 -t $(DESTDIR)/$(CRDA_PATH)/ regulatory.db
install -m 755 -d $(DESTDIR)/$(MANDIR)/man5/
-   install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.bin.5.gz
-
-uninstall:
-   rm -rf $(DESTDIR)/$(CRDA_PATH)/
+   install -m 644 -t $(DESTDIR)/$(MANDIR)/man5/ regulatory.db.5.gz
diff --git a/README b/README
index 065b67241c41..4028223725da 100644
--- a/README
+++ b/README
@@ -18,8 +18,8 @@ python module is used by the web viewer (Regulatory.py) which 
is
 implemented as a MoinMoin macro (and used on http://wireless.kernel.org)
 to allow viewing the database for verification.
 
-The dbparse module is also used by db2bin.py, the `compiler', which
-compiles and signs the binary database.
+The dbparse module is also used by db2bin.py and db2fw.py, the `compilers'
+that compile the database to its binary formats.
 
 For more information, please see the CRDA git repository:
 
diff --git a/db2fw.py b/db2fw.py
new file mode 100755
index ..7b2b14151e69
--- /dev/null
+++ b/db2fw.py
@@ -0,0 +1,133 @@
+#!/usr/bin/env python
+
+from cStringIO import StringIO
+import struct
+import hashlib
+from dbparse import DBParser
+import sys
+
+MAGIC = 0x52474442
+VERSION = 20
+
+if len(sys.argv) < 3:
+print 'Usage: %s output-file input-file' % sys.argv[0]
+sys.exit(2)

[PATCH 3/6] wireless-regdb: Add sforshee's x509 certificate

[Seth Forshee]

Add a x509 certificate for sforshee.key.pub.pem. This is the same
certificate which is shipped in the kernel for validating
regulatory database files.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 sforshee.x509.pem | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 sforshee.x509.pem

diff --git a/sforshee.x509.pem b/sforshee.x509.pem
new file mode 100644
index ..ebd01606d057
--- /dev/null
+++ b/sforshee.x509.pem
@@ -0,0 +1,17 @@
+-BEGIN CERTIFICATE-
+MIICpDCCAYwCCQCyjd9HrvnOpzANBgkqhkiG9w0BAQsFADATMREwDwYDVQQDDAhz
+Zm9yc2hlZTAgFw0xNzEwMDYxOTQwMzVaGA8yMTE3MDkxMjE5NDAzNVowEzERMA8G
+A1UEAwwIc2ZvcnNoZWUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
+QOOcKIQ5A/I512YsQTgVrH6lg3ElfpB8aN1vP9nXWTiffGpSwgMqLX5m9B6zEnAg
+W9SXMj1xizsbCBcUa2HEV4uWFhz9JNULCfloEYT7ylEM0UUZ2hBEitn+dqn9YC0Y
+CyiVsi3qiJi40VYh8FMf8QJv6Uabk18okA+sNvpoI3FXVvbM0999Ktkbc0XruieF
+73p/pcuAxzA20lPu7Kwe5zHxNqKcY8ZlW38ldWih6tN+AFyaXtggGDJ3BykSZh42
+c+eXBEE3sbFyK/ShKSB8lnkLK9DY3shsP5P7xe54UhEVG3r24miZ5/tGFoTjx6Hm
+4NJG1eHEX6Bm9NrE/5UdAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAIcD2vKCwt2v
+fEQvhtNfTJNIuf4HF7sh9yUjTqoiDBa5c66dRnx12cNJV0e/M7eX7PVAdcBGIvCg
+XZx5E6H/uKMve44GP8i25Goo8jRcIz8ywOatD6zPVXRHc9MBhbcLIlYkfZ8JqQ6G
+njdbnG0C2YzIUGriWfMWBuqyQrVY/rrRgVca77I4iFj2qsQui1on5KXopMpnXKxy
+Z8NvE8MtNXnXiuf11CEwStX2o9l5VvIPEPd90FGTL0f4fUsKhFUSCn1OOx8rL/wo
+s2k04YCAu+KvudYw8R1UhyOZn1EDTEV9AmVzq/3PlMwNOmD9PBQvFjOpIR/LULGP
+A+6gZqkWeRQ=
+-END CERTIFICATE-
-- 
2.14.1

[PATCH 4/6] wireless-regdb: Better support for generating public certificates

[Seth Forshee]

The current makefile rule for the public certificate calls for an
openssl config file which is not provided. Let's put the pubcert
generation into a script named gen-pubcert.sh and embed the
openssl configuration file there.

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 Makefile   |  4 +---
 gen-pubcert.sh | 18 ++
 2 files changed, 19 insertions(+), 3 deletions(-)
 create mode 100755 gen-pubcert.sh

diff --git a/Makefile b/Makefile
index 9532c29a1dc2..044251f64785 100644
--- a/Makefile
+++ b/Makefile
@@ -79,9 +79,7 @@ $(REGDB_PUBKEY): $(REGDB_PRIVKEY)
 
 $(REGDB_PUBCERT): $(REGDB_PRIVKEY)
@echo "Generating certificate for $(REGDB_AUTHOR)..."
-   @openssl req -config regulatory.openssl.conf \
-   -key $(REGDB_PRIVKEY) -days 36500 -utf8 -nodes -batch \
-   -x509 -outform PEM -out $(REGDB_PUBCERT)
+   ./gen-pubcert.sh $(REGDB_PRIVKEY) $(REGDB_PUBCERT)
@echo $(REGDB_PUBKEY) > .custom
 
 
diff --git a/gen-pubcert.sh b/gen-pubcert.sh
new file mode 100755
index ..1a4d57999e5d
--- /dev/null
+++ b/gen-pubcert.sh
@@ -0,0 +1,18 @@
+#!/bin/bash
+
+if [[ $# -ne 2 ]]; then
+   echo "Usage: $0 priv-key out-file"
+   exit 1
+fi
+
+openssl req -new -key "$1" -days 36500 -utf8 -nodes -batch \
+   -x509 -outform PEM -out "$2" \
+   -config <(cat <<-EOF
+   [ req ]
+   distinguished_name = req_distinguished_name
+   string_mask = utf8only
+   prompt = no
+   [ req_distinguished_name ]
+   commonName = sforshee
+   EOF
+   )
-- 
2.14.1

Re: [PATCH v2 3/4] cfg80211: reg: remove support for built-in regdb

[Seth Forshee]

On Mon, Nov 13, 2017 at 10:23:09AM +0100, Johannes Berg wrote:
> On Mon, 2017-11-13 at 10:19 +0100, Benjamin Beichler wrote:
> > 
> > Is there already an example regulatory.db file available? 
> 
> There isn't yet, Seth?

Not yet. I've done some work on the patch you sent to make it generate
db files in both formats, not sure I'm ready to start actually releasing
files in the new format yet though. I suppose I could push it to a
testing branch with a signed regulatory.db file.

Seth

Re: [PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

[Seth Forshee]

On Fri, Oct 20, 2017 at 10:06:51AM -0500, Seth Forshee wrote:
> Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> based on the documents at [1] and [2].
> 
> v2: Also add DFS region
> 
> [1] 
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> [2] http://adilet.zan.kz/rus/docs/P01379_
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Applied.

Re: [PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

[Seth Forshee]

On Tue, Oct 31, 2017 at 11:39:13PM +0600, WoWz89 wrote:
> Здравствуйте, Seth.
> 
> Вы писали 20 октября 2017 г., 21:06:51:
> 
> > Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> > based on the documents at [1] and [2].
> 
> > v2: Also add DFS region
> Good afternoon, when will the update ?

I'm planning to get anything pending applied and a new release out in
the next couple of days.

[PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

[Seth Forshee]

Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
based on the documents at [1] and [2].

v2: Also add DFS region

[1] 
http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
[2] http://adilet.zan.kz/rus/docs/P01379_

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 9d129f2e542b..10c84ee1ca5d 100644
--- a/db.txt
+++ b/db.txt
@@ -691,8 +691,14 @@ country KY: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
 
-country KZ:
+# Source:
+# 
http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
+# http://adilet.zan.kz/rus/docs/P01379_
+country KZ: DFS-ETSI
(2402 - 2482 @ 40), (20)
+   (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
+   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
+   (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
 
 country LB: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.14.1

Re: [wireless-regdb] [PATCH] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

[Seth Forshee]

On Fri, Oct 20, 2017 at 09:48:25AM +1030, Ryan Mounce wrote:
> This is missing the DFS domain, which is almost certainly DFS-ETSI as
> KZ is in ITU region 1.

D'oh, I did forget that, good catch. I'll send out an update.

> 
> Regards,
> Ryan Mounce
> 
> On 20 October 2017 at 08:08, Seth Forshee <seth.fors...@canonical.com> wrote:
> > Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> > based on the documents at [1] and [2].
> >
> > [1] 
> > http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> > [2] http://adilet.zan.kz/rus/docs/P01379_
> >
> > Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
> > ---
> >  db.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/db.txt b/db.txt
> > index e48f9a619651..96d8fda44284 100644
> > --- a/db.txt
> > +++ b/db.txt
> > @@ -689,8 +689,14 @@ country KY: DFS-FCC
> > (5490 - 5730 @ 160), (24), DFS
> > (5735 - 5835 @ 80), (30)
> >
> > +# Source:
> > +# 
> > http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> > +# http://adilet.zan.kz/rus/docs/P01379_
> >  country KZ:
> > (2402 - 2482 @ 40), (20)
> > +   (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
> > +   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
> > +   (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
> >
> >  country LB: DFS-FCC
> > (2402 - 2482 @ 40), (20)
> > --
> > 2.14.1
> >
> >
> > ___
> > wireless-regdb mailing list
> > wireless-re...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: wireless-regdb: Update regulatory rules for Kazakhstan (KZ) on 5GHz

[Seth Forshee]

On Fri, Oct 20, 2017 at 05:56:35AM +0300, Андрей Иванов wrote:
> Thank you very much, I'm so glad. Last question how many days this patch will 
> appear here :  
> https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt
>   

I'll probably leave the patch out a few working days to see if anyone
has feedback. Given that today's Friday that means probably mid next
week.

Re: [PATCH] wireless-regdb: add Short Range Devices (SRD) (ETSI EN 300 440) for Spain

[Seth Forshee]

On Sun, Oct 15, 2017 at 03:46:37PM +0200, Xose Vazquez Perez wrote:
> UN - 130 Dispositivos de corto alcance en 5 GHz :
> https://www.boe.es/buscar/act.php?id=BOE-A-2013-4845=1=20150410
> 
> Cc: Seth Forshee <seth.fors...@canonical.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: wireless-re...@lists.infradead.org
> Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>

Applied, thanks!

Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Seth Forshee]

On Tue, Sep 26, 2017 at 03:54:45PM -0400, Seth Forshee wrote:
> On Thu, Aug 24, 2017 at 11:17:44AM -0500, Seth Forshee wrote:
> > On Thu, Aug 24, 2017 at 09:13:42AM +0200, Sven Eckelmann wrote:
> > > On Mittwoch, 23. August 2017 15:52:40 CEST Seth Forshee wrote:
> > > [...]
> > > > > +# Source
> > > > > +# 
> > > > > https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
> > > > > +# page 12-14
> > > > > +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is 
> > > > > implemented.
> > > [...]
> > > > > + # 5470 - 5725 is only allowed when TPC is implemented
> > > > > + # (5470 - 5725 @ 160), (30), DFS
> > > > 
> > > > I'm not sure that the lack of a specific provision for operating without
> > > > TPC in this range means that it cannot be used. As I understand it, TPC
> > > > would only result in a reduction in EIRP of 3 dB, so as long as we use
> > > > a power limit of half of the maximum allowed we will be safe.
> > > > 
> > > > If this is incorrect I'd appreciate it if someone more knowledgable on
> > > > the topic could chime in.
> > > 
> > > I would also be happy about feedback regarding this part. But my current 
> > > settings are based on the document [1] mentioned in this change.
> > > 
> > > Let us look at the range 5250 – 5350 on page 13. There are two entries 
> > > for the 
> > > same frequency range.
> > > 
> > >  * 28:
> > >- up to 200 mW
> > >- requires TPC for 5250 – 5350 Mhz
> > >  * 29:
> > >- up to 100 mW
> > >- requires *no* TPC for 5250 – 5350 Mhz
> > > 
> > > This is exactly the 3(.01029995...) dB difference which you've talked 
> > > about. 
> > > Now to the frequency range 5470 - 5725 MHz on page 14. 
> > > 
> > >  * 30:
> > >- up to 1000 mW
> > >- requires TPC for 5470 - 5725 MHz
> > > 
> > > There is no extra exception rule for non-TPC mode.
> > > 
> > > Now let us check what IEEE 802.11h-2003 [2] says about TPC.
> > 
> > 
> > 
> > > My current change now assumes following strict interpretation:
> > > 
> > >  * Singapore provides a mitigation factor of 3 dB for 5250 – 5350 Mhz 
> > > (see 
> > >table entry 28 + 29)
> > >  * Singapore provides now mitigation factor for 5470 - 5725 MHz and 
> > > requires 
> > >TPC
> > > 
> > > I am currently unsure whether it is now valid to say that the default 
> > > mitigation factor would be 3 dB and thus there is an implicit table entry 
> > > (let 
> > > us call it 30b) which would be:
> > > 
> > >  * 30b:
> > >- up to 500 mW
> > >- requires *no* TPC for 5470 - 5725 MHz
> > > 
> > > Countries like AU or regions like ETSI (ETSI EN 301 893) seem to have 
> > > this 
> > > mitigation factor always specified in their rules. But Singapore is 
> > > missing it 
> > > for this specific frequency range.
> > 
> > So on the one hand I'm in agreement, it would be good to know where the
> > 3 dB attenuation comes from and whether it's really universal. So far
> > it's been something I've taken on faith from folks a lot more familiar
> > with the subject than me.
> > 
> > However, it seems the same lack of information would also anyone who
> > does want to support TPC. The information about how much to attenuate
> > must either be provided on a per-regulatory-domain basis or else it must
> > be standardized somehow. If it's the former then it seems odd that
> > Singapore does not include this information.
> > 
> > Hopefully someone more knowledgable will chime in to help us understand
> > better.
> 
> I was going through old messages in my inbox and realized that we've
> never done anything about this. Unless someone speaks up soon I guess
> I'll play it safe apply the patch as is, with the range commented out.

Applied, thanks!

[PATCH] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

[Seth Forshee]

Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
based on the documents at [1] and [2].

[1] 
http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
[2] http://adilet.zan.kz/rus/docs/P01379_

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/db.txt b/db.txt
index e48f9a619651..96d8fda44284 100644
--- a/db.txt
+++ b/db.txt
@@ -689,8 +689,14 @@ country KY: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
 
+# Source:
+# 
http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
+# http://adilet.zan.kz/rus/docs/P01379_
 country KZ:
(2402 - 2482 @ 40), (20)
+   (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
+   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
+   (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
 
 country LB: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.14.1

Re: wireless-regdb: Update regulatory rules for Kazakhstan (KZ) on 5GHz

[Seth Forshee]

On Thu, Oct 19, 2017 at 07:54:14PM +0300, Андрей Иванов wrote:
> Hello again perirenal forums and laws of Kazakhstan on the 5GHz and 
> everywhere one answer permitted use indoors frequency 5150-5350 and 5470-5725 
> MHz details there is no law painted as is done in other countries. Please add 
> to this range in Kazakhstan is possible in the future and will develop in 
> more detail the law on wi-fi 5 GHz, but currently it is what it is.

So, based on the doucment you linked to and one given earlier
(http://adilet.zan.kz/rus/docs/P01379_) I'll send a paatch to allow
5150-5350 adn 5470-5725 MHz. However I think the power limit for all the
rules needs to be limited to 100mW instead of 1W as you had in some of
them, and we need to add the NO-OUTDOOR flag.

One of the documents also refers to ITU Resolution 229 with regard to
the 5GHz ranges, so I do think DFS is necessary in some of the ranges.

I'll follow up with a patch shortly.

> >Четверг, 19 октября 2017, 8:28 +06:00 от Андрей Иванов <wow...@mail.ru>:
> >
> >Yes, I saw the frequencies wrong, but according to the documentation, you 
> >can add support for the frequencies 5150-5350 and 5470-5725 MHz, so that the 
> >phones on the Androyd started seeing Wi-fi 5GHz? or are our legislative acts 
> >not extinguishing you?
> >
> >I'm just not strong in all of your terms, but my phone does not see wi-fi 
> >5GHz and with support we figured out that due to the fact that it does not 
> >exist in wireless-regdb it will not see it.
> >
> >
> >>Четверг, 19 октября 2017, 0:49 +06:00 от Seth Forshee < 
> >>seth.fors...@canonical.com >:
> >>
> >>On Wed, Oct 18, 2017 at 07:44:54PM +0300, Андрей Иванов wrote:
> >>> 
> >>> In accordance with the communications act ( in the attachment) official 
> >>> source the government website 
> >>> mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> >>> on page 16 in paragraph 23 outlines that we can use frequency 
> >>> 5150–5350МГц 5470-5725 MHz indoor. It's an official order approved by the 
> >>> government also exert its scan where you can see all the printing and 
> >>> painting reference on the Internet  
> >>> http://adilet.zan.kz/rus/origins/V1500010730  
> >>
> >>Any reason you dropped the mailing lists from your reply?
> >>
> >>A few notes/questions:
> >>
> >>1. We'll need to add the NO-OUTDOOR flag to the 5150-5350 and 5470-5725
> >>   MHz ranges.
> >>
> >>2. I don't see anything about using DFS in the ranges where you have
> >>   that. It's not unreasonable that this would be required, but I'm
> >>   wondering whether I'm missing that or if there's someplace else which
> >>   specifies this is needed?
> >>
> >>3. I don't see anything about using frequencies above 5725 MHz.
> >>
> >>4. The regulatory db is for unlicensed spectrum only. I'm reading a
> >>   google translation of the document so I'm having a hard time being
> >>   sure of what it says, but I do see a lot of references to permits or
> >>   licenses. Can the spectrum you're trying to add be used without
> >>   obtaining a permit or license?
> >>
> >>Thanks,
> >>Seth
> >>
> >>> 
> >>> >Среда, 18 октября 2017, 19:50 +06:00 от Seth Forshee < 
> >>> >seth.fors...@canonical.com >:
> >>> >
> >>> >On Wed, Oct 18, 2017 at 02:26:17PM +0300, Андрей Иванов wrote:
> >>> >> Please add support for 5 GHz in Kazakhstan
> >>> >> (5170 - 5250 @ 80), (20), AUTO-BW
> >>> >>(5250 - 5330 @ 80), (20), DFS, AUTO-BW
> >>> >>(5650 - 5730 @ 80), (30), DFS
> >>> >>(5735 - 5835 @ 80), (30)
> >>> >
> >>> >We got a very similar submission not that long ago, and I had some
> >>> >questions which were never answered.
> >>> >
> >>> > http://lists.infradead.org/pipermail/wireless-regdb/2017-August/001086.html
> >>> >
> >>> >That one provided a link to some documentation for Kazakhstan, but the
> >>> >information there seemed incomplete to me. Can you answer the questions
> >>> >I asked there, or provide a link to a more complete source of
> >>> >information for the regulations in Kazakhstan?
> >>> >
> >>> >Thanks,
> >>> >Seth
> >>> 
> >>> 
> >>> С уважением,
> >>> Андрей Ивaнoв
> >>
> >>
> >>
> >
> >
> >С уважением,
> >Андрей Ивaнoв
> 
> 
> С уважением,
> Андрей Ивaнoв

Re: wireless-regdb: Update regulatory rules for Kazakhstan (KZ) on 5GHz

[Seth Forshee]

On Wed, Oct 18, 2017 at 02:26:17PM +0300, Андрей Иванов wrote:
> Please add support for 5 GHz in Kazakhstan
> (5170 - 5250 @ 80), (20), AUTO-BW
>   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
>   (5650 - 5730 @ 80), (30), DFS
>   (5735 - 5835 @ 80), (30)

We got a very similar submission not that long ago, and I had some
questions which were never answered.

http://lists.infradead.org/pipermail/wireless-regdb/2017-August/001086.html

That one provided a link to some documentation for Kazakhstan, but the
information there seemed incomplete to me. Can you answer the questions
I asked there, or provide a link to a more complete source of
information for the regulations in Kazakhstan?

Thanks,
Seth

Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Seth Forshee]

On Thu, Aug 24, 2017 at 11:17:44AM -0500, Seth Forshee wrote:
> On Thu, Aug 24, 2017 at 09:13:42AM +0200, Sven Eckelmann wrote:
> > On Mittwoch, 23. August 2017 15:52:40 CEST Seth Forshee wrote:
> > [...]
> > > > +# Source
> > > > +# 
> > > > https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
> > > > +# page 12-14
> > > > +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is 
> > > > implemented.
> > [...]
> > > > +   # 5470 - 5725 is only allowed when TPC is implemented
> > > > +   # (5470 - 5725 @ 160), (30), DFS
> > > 
> > > I'm not sure that the lack of a specific provision for operating without
> > > TPC in this range means that it cannot be used. As I understand it, TPC
> > > would only result in a reduction in EIRP of 3 dB, so as long as we use
> > > a power limit of half of the maximum allowed we will be safe.
> > > 
> > > If this is incorrect I'd appreciate it if someone more knowledgable on
> > > the topic could chime in.
> > 
> > I would also be happy about feedback regarding this part. But my current 
> > settings are based on the document [1] mentioned in this change.
> > 
> > Let us look at the range 5250 – 5350 on page 13. There are two entries for 
> > the 
> > same frequency range.
> > 
> >  * 28:
> >- up to 200 mW
> >- requires TPC for 5250 – 5350 Mhz
> >  * 29:
> >- up to 100 mW
> >- requires *no* TPC for 5250 – 5350 Mhz
> > 
> > This is exactly the 3(.01029995...) dB difference which you've talked 
> > about. 
> > Now to the frequency range 5470 - 5725 MHz on page 14. 
> > 
> >  * 30:
> >- up to 1000 mW
> >- requires TPC for 5470 - 5725 MHz
> > 
> > There is no extra exception rule for non-TPC mode.
> > 
> > Now let us check what IEEE 802.11h-2003 [2] says about TPC.
> 
> 
> 
> > My current change now assumes following strict interpretation:
> > 
> >  * Singapore provides a mitigation factor of 3 dB for 5250 – 5350 Mhz (see 
> >table entry 28 + 29)
> >  * Singapore provides now mitigation factor for 5470 - 5725 MHz and 
> > requires 
> >TPC
> > 
> > I am currently unsure whether it is now valid to say that the default 
> > mitigation factor would be 3 dB and thus there is an implicit table entry 
> > (let 
> > us call it 30b) which would be:
> > 
> >  * 30b:
> >- up to 500 mW
> >- requires *no* TPC for 5470 - 5725 MHz
> > 
> > Countries like AU or regions like ETSI (ETSI EN 301 893) seem to have this 
> > mitigation factor always specified in their rules. But Singapore is missing 
> > it 
> > for this specific frequency range.
> 
> So on the one hand I'm in agreement, it would be good to know where the
> 3 dB attenuation comes from and whether it's really universal. So far
> it's been something I've taken on faith from folks a lot more familiar
> with the subject than me.
> 
> However, it seems the same lack of information would also anyone who
> does want to support TPC. The information about how much to attenuate
> must either be provided on a per-regulatory-domain basis or else it must
> be standardized somehow. If it's the former then it seems odd that
> Singapore does not include this information.
> 
> Hopefully someone more knowledgable will chime in to help us understand
> better.

I was going through old messages in my inbox and realized that we've
never done anything about this. Unless someone speaks up soon I guess
I'll play it safe apply the patch as is, with the range commented out.

Seth

Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Seth Forshee]

On Thu, Aug 24, 2017 at 09:13:42AM +0200, Sven Eckelmann wrote:
> On Mittwoch, 23. August 2017 15:52:40 CEST Seth Forshee wrote:
> [...]
> > > +# Source
> > > +# 
> > > https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
> > > +# page 12-14
> > > +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented.
> [...]
> > > + # 5470 - 5725 is only allowed when TPC is implemented
> > > + # (5470 - 5725 @ 160), (30), DFS
> > 
> > I'm not sure that the lack of a specific provision for operating without
> > TPC in this range means that it cannot be used. As I understand it, TPC
> > would only result in a reduction in EIRP of 3 dB, so as long as we use
> > a power limit of half of the maximum allowed we will be safe.
> > 
> > If this is incorrect I'd appreciate it if someone more knowledgable on
> > the topic could chime in.
> 
> I would also be happy about feedback regarding this part. But my current 
> settings are based on the document [1] mentioned in this change.
> 
> Let us look at the range 5250 – 5350 on page 13. There are two entries for 
> the 
> same frequency range.
> 
>  * 28:
>- up to 200 mW
>- requires TPC for 5250 – 5350 Mhz
>  * 29:
>- up to 100 mW
>- requires *no* TPC for 5250 – 5350 Mhz
> 
> This is exactly the 3(.01029995...) dB difference which you've talked about. 
> Now to the frequency range 5470 - 5725 MHz on page 14. 
> 
>  * 30:
>- up to 1000 mW
>- requires TPC for 5470 - 5725 MHz
> 
> There is no extra exception rule for non-TPC mode.
> 
> Now let us check what IEEE 802.11h-2003 [2] says about TPC.



> My current change now assumes following strict interpretation:
> 
>  * Singapore provides a mitigation factor of 3 dB for 5250 – 5350 Mhz (see 
>table entry 28 + 29)
>  * Singapore provides now mitigation factor for 5470 - 5725 MHz and requires 
>TPC
> 
> I am currently unsure whether it is now valid to say that the default 
> mitigation factor would be 3 dB and thus there is an implicit table entry 
> (let 
> us call it 30b) which would be:
> 
>  * 30b:
>- up to 500 mW
>- requires *no* TPC for 5470 - 5725 MHz
> 
> Countries like AU or regions like ETSI (ETSI EN 301 893) seem to have this 
> mitigation factor always specified in their rules. But Singapore is missing 
> it 
> for this specific frequency range.

So on the one hand I'm in agreement, it would be good to know where the
3 dB attenuation comes from and whether it's really universal. So far
it's been something I've taken on faith from folks a lot more familiar
with the subject than me.

However, it seems the same lack of information would also anyone who
does want to support TPC. The information about how much to attenuate
must either be provided on a per-regulatory-domain basis or else it must
be standardized somehow. If it's the former then it seems odd that
Singapore does not include this information.

Hopefully someone more knowledgable will chime in to help us understand
better.

Thanks,
Seth

Re: [PATCH 1/2] wireless-regdb: Update regulatory document references for Taiwan (TW)

[Seth Forshee]

On Tue, Aug 08, 2017 at 11:38:03AM +0800, Chen-Yu Tsai wrote:
> Taiwan's Ministry of Transportation and Communications updated its
> frequency allocation rules again on 2017/02/22. The amended articles
> are not related to this database, but the link should be kept up to
> date, as the old one is no longer accessible.
> 
> Taiwan's regulatory body, NCC, published its updated technical
> regulatory standard for low-power radio frequency devices, LP0002.
> The URL has not changed. The new standard opens up more bandwidth
> for 5g U-NII WiFi and 60g WiGig devices. Transmission power for
> 5.25 ~ 5.35 GHz is also increased, but this was already covered
> in commit 9a618d9b5fb2 ("wireless-regdb: Update 5 GHz rules for
> Taiwan (TW) to follow US").
> 
> This patch updates the link and comments for the rules and standards,
> and also adds inline comments referencing the governing section of the
> LP0002 standard for each band.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied both patches, thanks!

Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Seth Forshee]

On Mon, Aug 07, 2017 at 10:19:50AM +0200, Sven Eckelmann wrote:
> 2.4GHz and the lower 5GHz band can now be use with up to 23dBm. But the DFS
> channels in general require TPC to be usable. Only 5150 - 5250 has an
> exception which allows the use of it without TPC when reducing the power to
> 20 dBm.
> 
> Signed-off-by: Sven Eckelmann 

Thanks for the patch, and apologies for the slow response. One comment
below.

> ---
> Please check this twice because this is my first attempt in converting an
> official regulatory document to an wireless-regdb entry.
> 
>  db.txt | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 0bc068e..df30f37 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -1078,12 +1078,17 @@ country SE: DFS-ETSI
>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
>   (57000 - 66000 @ 2160), (40)
>  
> +# Source
> +# 
> https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
> +# page 12-14
> +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented.
>  country SG: DFS-FCC
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (17), AUTO-BW
> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> - (5490 - 5730 @ 160), (24), DFS
> - (5735 - 5835 @ 80), (30)
> + (2400 - 2483.5 @ 40), (23)
> + (5150 - 5250 @ 80), (23), AUTO-BW
> + (5250 - 5350 @ 80), (20), DFS, AUTO-BW
> + # 5470 - 5725 is only allowed when TPC is implemented
> + # (5470 - 5725 @ 160), (30), DFS

I'm not sure that the lack of a specific provision for operating without
TPC in this range means that it cannot be used. As I understand it, TPC
would only result in a reduction in EIRP of 3 dB, so as long as we use
a power limit of half of the maximum allowed we will be safe.

If this is incorrect I'd appreciate it if someone more knowledgable on
the topic could chime in.

Thanks,
Seth

Re: Update regulatory rules for Kazakhstan (KZ) on 5GHz

[Seth Forshee]

On Mon, Jul 03, 2017 at 12:50:55PM -0500, Seth Forshee wrote:
> On Mon, Jun 26, 2017 at 10:00:13AM +0600, Vasiliy Safronov wrote:
> > Please add support 5ghz for Kazakhstan.
> > In Kazakhstan there are no restrictions up to 100mW
> > country KZ: DFS-ETSI
> >  (2402 - 2482 @ 40), (20)
> >  (5170 - 5250 @ 80), (20), AUTO-BW
> >  (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> >  (5650 - 5730 @ 80), (30), DFS
> >  (5735 - 5835 @ 80), (30)
> > 
> > http://adilet.zan.kz/rus/docs/P01379_
> > S 5.282 etc
> 
> Thanks for the submission, and apologies for the slow response. I've
> been trying to find some time to validate the changes against the
> document you linked to but haven't managed to get it done yet. I hope to
> be able to take a look at this soon.

Once again sorry for the delay.

I've spent some time trying to look over the document (rather a Google
translation of the document to English). I'm not confident I understand
it completely, and I'm also not entirely confident of the values you
provided. If you could explain how you arrived at those values and
answer some questions it might help.

The document has two tables for each band. The first table seems to be
the ITU regulations for the band in all three regions, and the second is
specific to Kazakhstan. If I rely on the latter then I must conclude
that the 5 GHz band shouldn't be included. Am I misinterpreting
something?

I also haven't been able to determine the basis for your power limits,
can you plese specify where these came from?

Thanks,
Seth

Re: Update regulatory rules for Kazakhstan (KZ) on 5GHz

[Seth Forshee]

On Mon, Jun 26, 2017 at 10:00:13AM +0600, Vasiliy Safronov wrote:
> Please add support 5ghz for Kazakhstan.
> In Kazakhstan there are no restrictions up to 100mW
> country KZ: DFS-ETSI
>  (2402 - 2482 @ 40), (20)
>  (5170 - 5250 @ 80), (20), AUTO-BW
>  (5250 - 5330 @ 80), (20), DFS, AUTO-BW
>  (5650 - 5730 @ 80), (30), DFS
>  (5735 - 5835 @ 80), (30)
> 
> http://adilet.zan.kz/rus/docs/P01379_
> S 5.282 etc

Thanks for the submission, and apologies for the slow response. I've
been trying to find some time to validate the changes against the
document you linked to but haven't managed to get it done yet. I hope to
be able to take a look at this soon.

Thanks,
Seth

[ANN] wireless-regdb: master-2017-03-07

[Seth Forshee]

A new release of wireless-regdb (master-2017-03-07) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2017.03.07.tar.gz

The short log of changes since the 2016-06-10 release is below.

Thanks,
Seth

---

Jouni Malinen (1):
  wireless-regdb: Remove DFS requirement for India (IN)

Ryan Mounce (1):
  wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

Seth Forshee (2):
  wireless-regdb: Update 5 GHz rules for Canada
  wireless-regdb: update regulatory.bin based on preceding changes

Re: [PATCH v3] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Sat, Feb 25, 2017 at 01:40:27PM +1030, Ryan Mounce wrote:
> Sourced from the current legislation at
> https://www.legislation.gov.au/Details/F2016C00432
> 
> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> 
> Frequency ranges and EIRP limits for all ranges have been updated to
> match items 59-63, 65 in the linked document. As the rules for AU have
> never previously mirrored local regulations, changes include a
> significant increase in the allowable 2.4GHz EIRP and smaller increases
> in most other bands.
> 
> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> bands) the lower, more restrictive band has been rounded up by 5MHz.
> 
> Signed-off-by: Ryan Mounce 

Applied, thanks.

Re: [PATCH v3] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Sat, Feb 25, 2017 at 01:40:27PM +1030, Ryan Mounce wrote:
> Sourced from the current legislation at
> https://www.legislation.gov.au/Details/F2016C00432
> 
> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> 
> Frequency ranges and EIRP limits for all ranges have been updated to
> match items 59-63, 65 in the linked document. As the rules for AU have
> never previously mirrored local regulations, changes include a
> significant increase in the allowable 2.4GHz EIRP and smaller increases
> in most other bands.
> 
> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> bands) the lower, more restrictive band has been rounded up by 5MHz.
> 
> Signed-off-by: Ryan Mounce 

This looks good to me. I'll give it a few more days to see if anyone
else has comments.

Thanks,
Seth

Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Fri, Feb 24, 2017 at 01:20:24PM +1030, Ryan Mounce wrote:
> On 24 February 2017 at 02:05, Seth Forshee <seth.fors...@canonical.com> wrote:
> > On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote:
> >> Sourced from the current legislation at
> >> https://www.legislation.gov.au/Details/F2016C00432
> >>
> >> The current rules exceed legal limits between 5250-5330MHz, and permit
> >> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> >>
> >> Frequency ranges and EIRP limits for all ranges have been updated to
> >> match items 59-63, 65 in the linked document. As the rules for AU have
> >> never previously mirrored local regulations, changes include a
> >> significant increase in the allowable 2.4GHz EIRP and smaller increases
> >> in most other bands.
> >>
> >> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> >> bands) the lower, more restrictive band has been rounded up by 5MHz.
> >>
> >> Signed-off-by: Ryan Mounce <r...@mounce.com.au>
> >> ---
> >>  db.txt | 15 ++-
> >>  1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/db.txt b/db.txt
> >> index 05108e0..00e81b6 100644
> >> --- a/db.txt
> >> +++ b/db.txt
> >> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
> >>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
> >>   (57000 - 66000 @ 2160), (40)
> >>
> >> +# Source:
> >> +# https://www.legislation.gov.au/Details/F2016C00432
> >> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
> >>  country AU: DFS-ETSI
> >> - (2402 - 2482 @ 40), (20)
> >> - (5170 - 5250 @ 80), (17), AUTO-BW
> >> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> >> - (5490 - 5710 @ 160), (24), DFS
> >> - (5735 - 5835 @ 80), (30)
> >> + (2400 - 2483.5 @ 40), (36)
> >
> > The mention of ETSI EN 300 328 in item 55 (a) leads me to believe that
> > this is the limit we should be using, i.e. 500 mW. It is a bit confusing
> > though since it seems like such devices would also fall under "digital
> > modulation transmitters."
> 
> Item 55 applies only to frequency hopping transmitters e.g. Bluetooth.
> As a local, I can say with some degree of certainty that 4W/36dBm is
> the correct 2.4GHz ISM EIRP for Australia. It is advertised as the
> EIRP in the 802.11d IE of commercial devices e.g. Cisco Aironet APs
> and widely deployed ISP gateways in Australia, among other devices
> that have received relevant approvals.

Okay, looking at that section again that makes sense.

> >> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> >
> > This looks correct.
> >
> >> + (5250 - 5350 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
> >
> > Since this range requires TPC we need to set the power limit at 100 mW.
> >
> >> + (5470 - 5600 @ 80), (30), DFS
> >> + (5650 - 5730 @ 80), (30), DFS
> >
> > These ranges also require TPC so we need to set the limit at 500 mW.
> 
> I was unsure about this one. Setting this to 27dBm also affects the
> 802.11d country information IE, however when the DFS flag is set a 3dB
> 802.11h power constraint IE is also advertised so stations will limit
> themselves to (27-3)=24dBm/250mW.
> 
> Given the choice between unnecessarily halving transmit power on
> stations and potentially transmitting at twice the permissible power
> on APs without TPC I agree that the conservative approach should be
> taken for now. Ideally I think that the actual EIRP limits should be
> in the regdb and a 3dB constraint should be applied automatically on
> APs that cannot support TPC when the DFS flag is set.
> 
> >> + (5730 - 5850 @ 80), (36)
> >
> > In the document the ranges are 5650-5725 MHz and 5725-5850 MHz. I
> > suspect that the existing rules fudge that to line up with the wifi
> > channels, which technically is okay because the rules in the former
> > range are more restrictive. I wonder if we shouldn't be recording them
> > here as per the document and adding AUTO-BW. Johannes, any thoughts?
> 
> I've tested with AUTO-BW and it doesn't work in this case as channel
> 144 will be disabled if it doesn't exist entirely within one band.
> Fudging the more restrictive rules by a mere 5MHz to fit 802.11
> channels seems to be the status quo.

I wonder why AUTO-BW doesn't work. In that case it's certainly fine to
keep those ranges as they are.

Thanks,
Seth

Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote:
> Sourced from the current legislation at
> https://www.legislation.gov.au/Details/F2016C00432
> 
> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> 
> Frequency ranges and EIRP limits for all ranges have been updated to
> match items 59-63, 65 in the linked document. As the rules for AU have
> never previously mirrored local regulations, changes include a
> significant increase in the allowable 2.4GHz EIRP and smaller increases
> in most other bands.
> 
> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> bands) the lower, more restrictive band has been rounded up by 5MHz.
> 
> Signed-off-by: Ryan Mounce 
> ---
>  db.txt | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 05108e0..00e81b6 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
>   (57000 - 66000 @ 2160), (40)
>  
> +# Source:
> +# https://www.legislation.gov.au/Details/F2016C00432
> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>  country AU: DFS-ETSI
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (17), AUTO-BW
> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (24), DFS
> - (5735 - 5835 @ 80), (30)
> + (2400 - 2483.5 @ 40), (36)

The mention of ETSI EN 300 328 in item 55 (a) leads me to believe that
this is the limit we should be using, i.e. 500 mW. It is a bit confusing
though since it seems like such devices would also fall under "digital
modulation transmitters." 

> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW

This looks correct.

> + (5250 - 5350 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS

Since this range requires TPC we need to set the power limit at 100 mW.

> + (5470 - 5600 @ 80), (30), DFS
> + (5650 - 5730 @ 80), (30), DFS

These ranges also require TPC so we need to set the limit at 500 mW.

> + (5730 - 5850 @ 80), (36)

In the document the ranges are 5650-5725 MHz and 5725-5850 MHz. I
suspect that the existing rules fudge that to line up with the wifi
channels, which technically is okay because the rules in the former
range are more restrictive. I wonder if we shouldn't be recording them
here as per the document and adding AUTO-BW. Johannes, any thoughts?

> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR

This looks correct.

Thanks,
Seth

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Thu, Feb 23, 2017 at 06:58:45AM +0100, Johannes Berg wrote:
> 
> > The frequency ranges have been "rounded down" to conform with the
> > apparent convention of only including ranges used by standard 802.11
> > channels, rather than using the actual frequency ranges as has been
> > done for some countries (and most 60GHz rules). My preference is the
> > latter so that there is a clear correlation between the regdb and
> > relevant documentation, and so that the regdb may become useful
> > beyond 802.11. With your blessing as maintainer I will also make this
> > change to the patch.
> 
> I think that's just an artifact of the original database source and
> would also prefer the documented ranges to be used.

Yes, I prefer the documented ranges as well.

Thanks,
Seth

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Sat, Feb 18, 2017 at 05:05:15PM +1030, Ryan Mounce wrote:
> Sourced from the latest legislation at
> https://www.legislation.gov.au/Details/F2016C0043

This link isn't working for me.

> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (reserved for weather radar).

The changes also increases the limits for most other ranges, by quite a
bit in some cases. Seems that this should also be mentioned in the
changelog, and I'd like to be able to check those changes against the
documentation.

Thanks,
Seth

> 
> Signed-off-by: Ryan Mounce 
> ---
>  db.txt | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index 05108e0..b951e0c 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
>   (57000 - 66000 @ 2160), (40)
>  
> +# Source:
> +# https://www.legislation.gov.au/Details/F2016C00432
> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>  country AU: DFS-ETSI
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (17), AUTO-BW
> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (24), DFS
> - (5735 - 5835 @ 80), (30)
> + (2402 - 2482 @ 40), (36)
> + (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> + (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
> + (5490 - 5590 @ 80), (30), DFS
> + (5650 - 5730 @ 80), (30), DFS
> + (5735 - 5835 @ 80), (36)
> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>  
>  country AW: DFS-ETSI
>   (2402 - 2482 @ 40), (20)
> -- 
> 2.11.0
> 

Re: [PATCH] wireless-regdb: Remove DFS requirement for India (IN)

[Seth Forshee]

On Mon, Jan 30, 2017 at 02:08:32PM +0200, Jouni Malinen wrote:
> The "Indoor Use of low power wireless equipment in the frequency band 5
> GHz (Exemption from Licensing Requirement) Rules, 2005" notification by
> Ministry of Communications and Information Technology (Wireless Planning
> and Coordination Wing) (New Delhi, the 28th January 2005) does not
> mandate use of DFS, so remove the DFS flag from the 5250-5330 MHz band
> in India.
> 
> In addition, increase the TX power limit to 23 dBm to match the 200 mW
> maximum mentioned in the same notification. Also use the exact ranges
> from that notification and enable use of 160 MHz channels in the
> 5150-5350 MHz band.
> 
> Signed-off-by: Jouni Malinen 

Applied, thanks.

[ANN] wireless-regdb: master-2016-06-10

[Seth Forshee]

A new release of wireless-regdb (master-2016-06-10) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2016.06.10.tar.gz

The short log of changes since the 2015-05-02 release is below.

Thanks,
Seth

---

Maya Erez (1):
  wireless-regdb: Republic of Korea: Add 60GHz regulatory rules

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wireless-regdb: Republic of Korea: Add 60GHz regulatory rules

[Seth Forshee]

On Thu, Jun 02, 2016 at 10:33:05PM +0300, Maya Erez wrote:
> Add 60GHz regulatory rules for Korea (KR).
> Source is
> http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
> 
> Signed-off-by: Maya Erez 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Republic of Korea: Add 60GHz regulatory rules

[Seth Forshee]

On Wed, Jun 01, 2016 at 10:32:14PM +0300, me...@codeaurora.org wrote:
> On 2016-05-31 15:35, Seth Forshee wrote:
> >On Sat, May 21, 2016 at 12:25:08PM +0300, Maya Erez wrote:
> >>Add 60GHz regulatory rules for Korea (KR).
> >>Source is
> >>
> >http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%
> >A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
> >>
> >>Signed-off-by: Maya Erez <qca_me...@qca.qualcomm.com>
> >>---
> >> db.txt | 4 
> >> 1 file changed, 4 insertions(+)
> >>
> >>diff --git a/db.txt b/db.txt
> >>index da16f7c..143f915 100644
> >>--- a/db.txt
> >>+++ b/db.txt
> >>@@ -664,6 +664,10 @@ country KR: DFS-JP
> >>(5250 - 5330 @ 80), (20), DFS, AUTO-BW
> >>(5490 - 5710 @ 160), (30), DFS
> >>(5735 - 5835 @ 80), (30)
> >>+   # 60 GHz band channels 1-4,
> >>+   # ref:
> >http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%
> >A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
> >>+   (57000 - 66000 @ 2160), (57)
> >>+
> >
> >Thanks for the patch. I wanted to double check with you that the power
> >limit is correct though, since it seems extremely high (an order of
> >magnitude higher than what we have for any other country in fact). I
> >can't make out much of anything from the link, and I can't even run it
> >through google translate since it's composed of images rather than text.
> >
> >Thanks,
> >Seth
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> >in
> >the body of a message to majord...@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Thanks for your comment. I double checked it and the power limit should be
> 43dBm. I'll send an updated patch.
> This value is determined due to the following statement:
> "The antenna power is 500 mW or less, if you are using a non-directional
> antenna 100 mW or less, power density should be 13 dBm / MHz or less, the
> equivalent isotropic radiated power is less than 43 dBm."
> We fit the 500mW or less power, hence the EIRP is 43 dBm.

Great, thanks for double checking.

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Republic of Korea: Add 60GHz regulatory rules

[Seth Forshee]

On Sat, May 21, 2016 at 12:25:08PM +0300, Maya Erez wrote:
> Add 60GHz regulatory rules for Korea (KR).
> Source is
> http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
> 
> Signed-off-by: Maya Erez 
> ---
>  db.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/db.txt b/db.txt
> index da16f7c..143f915 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -664,6 +664,10 @@ country KR: DFS-JP
>   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
>   (5490 - 5710 @ 160), (30), DFS
>   (5735 - 5835 @ 80), (30)
> + # 60 GHz band channels 1-4,
> + # ref: 
> http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99
> + (57000 - 66000 @ 2160), (57)
> +

Thanks for the patch. I wanted to double check with you that the power
limit is correct though, since it seems extremely high (an order of
magnitude higher than what we have for any other country in fact). I
can't make out much of anything from the link, and I can't even run it
through google translate since it's composed of images rather than text.

Thanks,
Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] wireless-regdb: master-2016-05-02

[Seth Forshee]

A new release of wireless-regdb (master-2016-05-02) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2016.05.02.tar.gz

The short log of changes since the 2015-02-08 release is below.

Thanks,
Seth

---

Anne Marcel Roorda (1):
  Update regulatory rules for NL as per ETSI EN 300 440-1

Maximilian Engelhardt (2):
  wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz
  wireless-regdb: Update regulatory references for Germany (DE)

Petko Bordjukov (1):
  Update the regulatory rules for Bulgaria (BG)

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory references for Germany (DE)

[Seth Forshee]

On Mon, Apr 25, 2016 at 03:09:48PM +0200, Maximilian Engelhardt wrote:
> Hi,
> 
> The "Frequenznutzungsplan" is not really a good reference as it's a list
> of all frequency allocations and does only list basic information about
> the allocation. This patch changes the comments to reference directly
> the corresponding documents which provide all information about the
> allocation.
> 
> This patch does only change comments, all entries have been left
> unchanged. However the entries have been verified to match the mentioned
> documents.
> 
> This patch is based on my last path that adds the short range devices band 
> for 
> Germany.
> 
> Thanks,
> Maxi
> 
> 
> Signed-off-by: Maximilian Engelhardt 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Update regulatory rules for NL as per ETSI EN 300 440-1

[Seth Forshee]

On Fri, Apr 22, 2016 at 02:36:13PM +0200, Anne Marcel Roorda wrote:
> 
> Hi,
> 
>   Below the patch to include SRD as per ETSI EN 300 440-1
> for NL.
> 
> Thanks,
> 
> - marcel
> 
> Signed-off-by: Anne Marcel Roorda 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Thu, Apr 21, 2016 at 08:08:46PM +0200, Maximilian Engelhardt wrote:
> On Thursday 21 April 2016 08:19:38 Seth Forshee wrote:
> > On Tue, Apr 19, 2016 at 08:03:16PM +0200, Maximilian Engelhardt wrote:
> > > Hi,
> > > 
> > > In Europe ETSI standardized the used for short range devices (SRD) [1] in
> > > ETSI EN 300 440-1 [2].
> > > According to this standard generic use equipment is allowed to transmit in
> > > the frequency range form 5725 MHz to 5875 MHz with a maximum output power
> > > of 25 mW e.i.r.p. This generic allocation also allows transmission of
> > > 802.11 devices.
> > > 
> > > [3] has a list of countries and their status about the implementation of
> > > the SRD frequency bands. For the 5 GHz band this can be seen on page 38
> > > in the paragraph ANNEX 1 and the entry Annex j.
> > > 
> > > Attached is a patch that adds the 5 GHz SRD band to db.txt for Germany.
> > > 
> > > If it is acceptable I can provide a patch adding the 5 GHz SRD band for
> > > the
> > > other countries listed in [3].
> > 
> > The changes seem okay as far as I can tell. You do need to include your
> > signed-off-by tag on the patch however, see
> > https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tre
> > e/CONTRIBUTING.
> > 
> > Thanks,
> > Seth
> 
> Hi Seth,
> 
> Thanks for your reply. You can find my signed-off-by tag below together with 
> the unchanged patch.
> 
> I can affirm I did check this carefully with the official documents of the 
> German administration for radio equipment (Bundesnetzagentur für 
> Elektrizität, 
> Gas, Telekommunikation, Post und Eisenbahnen).
> 
> I noticed that the links to the other entries for Germany are broken, as the 
> website design was changed and thus all old link became non functional. I can 
> provide a patch fixing this if it is something that's considered useful.
> 
> 
> The comments to my initial mail indicated that the statement in the ERC 
> recommendation I linked are alone not enough to add this frequency ranges for 
> other countries. Unfortunately I don't have the possibility to do these 
> checks 
> for countries other than Germany.
> 
> If there is anything I can do to help adding the SRD entries for more 
> countries please let me know.
> 
> Thanks,
> Maxi
> 
> 
> Signed-off-by: Maximilian Engelhardt <engelha...@perisens.de>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Update regulatory rules for NL as per ETSI EN 300 440-1

[Seth Forshee]

On Fri, Apr 22, 2016 at 07:12:35PM +0200, Anne Marcel Roorda wrote:
> 
> In message <20160422135529.GA109717@ubuntu-hedt>, Seth Forshee writes:
> 
> 
> 
> > I'm looking at the document you reference as translated by Google, and
> > I'm not seeing anything there to support these changes. I can't find any
> > reference to ETSI 300 440-1. The section which would appear to apply
> > here (article 2 paragraph o) references Annex 11 for permitted frequency
> > bands, and this does not include the range that you're adding.
> > 
> > I didn't read the document in its entirety though, so I may have missed
> > something. If so, could you please point me to the specific section
> > which would permit operation in that range?
> 
>   Please see "Bijlage 11" (Non specific SRD) Nr. J.

I see it now. I know I looked at that section, so I must have overlooked
it. Thanks.

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Update regulatory rules for NL as per ETSI EN 300 440-1

[Seth Forshee]

On Fri, Apr 22, 2016 at 02:36:13PM +0200, Anne Marcel Roorda wrote:
> 
> Hi,
> 
>   Below the patch to include SRD as per ETSI EN 300 440-1
> for NL.
> 
> Thanks,
> 
> - marcel
> 
> Signed-off-by: Anne Marcel Roorda 
> 
> diff --git a/db.txt b/db.txt
> index e9ba21a..738e412 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -850,11 +850,18 @@ country NI: DFS-FCC
>   (5490 - 5730 @ 160), (24), DFS
>   (5735 - 5835 @ 80), (30)
>  
> +# Regulation on the use of frequency space without a license and 
> +# without notification 2015
> +#
> +# http://wetten.overheid.nl/BWBR0036378/2015-03-05
> +
>  country NL: DFS-ETSI
>   (2402 - 2482 @ 40), (20)
>   (5170 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
>   (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
>   (5490 - 5710 @ 160), (27), DFS
> + # short range devices (ETSI EN 300 440-1)
> + (5725 - 5875 @ 80), (25 mW)
>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
>   (57000 - 66000 @ 2160), (40)

I'm looking at the document you reference as translated by Google, and
I'm not seeing anything there to support these changes. I can't find any
reference to ETSI 300 440-1. The section which would appear to apply
here (article 2 paragraph o) references Annex 11 for permitted frequency
bands, and this does not include the range that you're adding.

I didn't read the document in its entirety though, so I may have missed
something. If so, could you please point me to the specific section
which would permit operation in that range?

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Thu, Apr 21, 2016 at 10:13:14PM +0200, Anne Marcel Roorda wrote:
> 
> On 21 Apr 2016, Seth Forshee wrote:
> > On Thu, Apr 21, 2016 at 08:08:46PM +0200, Maximilian Engelhardt wrote:
> >
> >> The comments to my initial mail indicated that the statement in the ERC 
> >> recommendation I linked are alone not enough to add this frequency ranges 
> >> for 
> >> other countries. Unfortunately I don't have the possibility to do these 
> >> checks 
> >> for countries other than Germany.
> >
> >Yep, I understand and am in agreement. I know how challenging it can be
> >to try to track down this information.
> 
>   I could do the same for NL.

That would be great, if anything about the current rules is incorrect or
out of date.

>   At the moment entries for NL are listed as center frequencies
> (almost, 5490 - 5710 @ 160 should be 5550 - 5645 @ 160), while for DE
> the whole band is listed (5470 - 5725 @ 160).

There's no reason per se to limit it to only the range for currently
defined wifi channels if the regulatory body allows unlicensed use of a
wider range. But the rule should include the entire channel bandwith and
not stop at the center frequencies.

>   Power budget is listed in db while the law specifies mW.
> 
>   What is the prefered format, and would a rewrite for NL listing the band
> and power in mW be acceptable ?

It's a direct conversion between the dBm and mW values (in fact mW
values in the text database are converted to dBm values for the binary
database), so the units in the text file don't matter all that much. But
I don't really like changing the units just for the sake of changing
them when the values are already correct; there's always the chance that
some mistake will slip in.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Thu, Apr 21, 2016 at 08:08:46PM +0200, Maximilian Engelhardt wrote:
> On Thursday 21 April 2016 08:19:38 Seth Forshee wrote:
> > On Tue, Apr 19, 2016 at 08:03:16PM +0200, Maximilian Engelhardt wrote:
> > > Hi,
> > > 
> > > In Europe ETSI standardized the used for short range devices (SRD) [1] in
> > > ETSI EN 300 440-1 [2].
> > > According to this standard generic use equipment is allowed to transmit in
> > > the frequency range form 5725 MHz to 5875 MHz with a maximum output power
> > > of 25 mW e.i.r.p. This generic allocation also allows transmission of
> > > 802.11 devices.
> > > 
> > > [3] has a list of countries and their status about the implementation of
> > > the SRD frequency bands. For the 5 GHz band this can be seen on page 38
> > > in the paragraph ANNEX 1 and the entry Annex j.
> > > 
> > > Attached is a patch that adds the 5 GHz SRD band to db.txt for Germany.
> > > 
> > > If it is acceptable I can provide a patch adding the 5 GHz SRD band for
> > > the
> > > other countries listed in [3].
> > 
> > The changes seem okay as far as I can tell. You do need to include your
> > signed-off-by tag on the patch however, see
> > https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tre
> > e/CONTRIBUTING.
> > 
> > Thanks,
> > Seth
> 
> Hi Seth,
> 
> Thanks for your reply. You can find my signed-off-by tag below together with 
> the unchanged patch.

Thanks, that will work. I'll leave it for a few days and see if anyone
else has comments.

> I can affirm I did check this carefully with the official documents of the 
> German administration for radio equipment (Bundesnetzagentur für 
> Elektrizität, 
> Gas, Telekommunikation, Post und Eisenbahnen).
> 
> I noticed that the links to the other entries for Germany are broken, as the 
> website design was changed and thus all old link became non functional. I can 
> provide a patch fixing this if it is something that's considered useful.

Yes, that would be useful, so please do.

> The comments to my initial mail indicated that the statement in the ERC 
> recommendation I linked are alone not enough to add this frequency ranges for 
> other countries. Unfortunately I don't have the possibility to do these 
> checks 
> for countries other than Germany.

Yep, I understand and am in agreement. I know how challenging it can be
to try to track down this information.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Tue, Apr 19, 2016 at 08:03:16PM +0200, Maximilian Engelhardt wrote:
> Hi,
> 
> In Europe ETSI standardized the used for short range devices (SRD) [1] in 
> ETSI 
> EN 300 440-1 [2].
> According to this standard generic use equipment is allowed to transmit in 
> the 
> frequency range form 5725 MHz to 5875 MHz with a maximum output power of 
> 25 mW e.i.r.p. This generic allocation also allows transmission of 802.11 
> devices.
> 
> [3] has a list of countries and their status about the implementation of the 
> SRD frequency bands. For the 5 GHz band this can be seen on page 38 in the 
> paragraph ANNEX 1 and the entry Annex j.
> 
> Attached is a patch that adds the 5 GHz SRD band to db.txt for Germany.
> 
> If it is acceptable I can provide a patch adding the 5 GHz SRD band for the 
> other countries listed in [3].

The changes seem okay as far as I can tell. You do need to include your
signed-off-by tag on the patch however, see
https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tree/CONTRIBUTING.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5735-5835 MHz band

[Seth Forshee]

On Fri, Mar 25, 2016 at 03:59:30PM +, thanh_ngu...@dell.com wrote:
> Seth,
> The sources I am using are also unofficial:
> 
> o   Broadcom’s document showing Russia allow 2.400-2.4835 (Ch 1-13), 
> 5.15-5.25GHz (Ch 36-48), 5.25-5.35GHz (Ch 52-64), 5.470-5.725GHz (Ch 100-140)
> 
> o   Wi-Fi Russian Certificates that Broadcom and Intel (and some other major 
> suppliers) provided to Dell don’t cover 5735-5835 MHz band
> I will try to obtain official documentation of Russia's regulations.

Thanks, that would be helpful. All I could turn up was a document
regarding fixed wireless installations, in which the 5375-5835 MHz range
was allowed.

> Regarding the Patch, I am new to Linux and I am not sure what that is. It 
> will be great if you can make one or guide me how to do it.

Let's hold off a bit. That will give you some time to look for some
official sources, and I'd also like to leave a little time to see if QCA
has any comments since the rules we currently have for Russia came from
them.

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Russia (RU) on 5735-5835 MHz band

[Seth Forshee]

On Thu, Mar 24, 2016 at 09:19:46PM +, thanh_ngu...@dell.com wrote:
> Dear Seth,
> Currently the db.txt has following setting for Russia:
> 
> country RU: DFS-ETSI
> (2402 - 2482 @ 40), (20)
> (5170 - 5250 @ 80), (20), AUTO-BW
> (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> (5650 - 5730 @ 80), (30), DFS
> (5735 - 5835 @ 80), (30)
> # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order 
> №129_22042015.pdf
> (57000 - 66000 @ 2160), (40)
> 
> Dell’s understanding is 5735-5835 MHz band is still not allowed in Russia. 
> Dell would like to submit a request for the wireless-regdb to investigate and 
> update the setting for Russia RU in the db.txt file.

I wasn't able to track down any official documentation of Russia's
regulations, but a few unofficial sources showed that range as being
allowed. What source(s) are you using to determine that it is not?

Feel free to send a patch if you think this should be changed, or I can
make one if you're not comfortable doing so. It would be helpful to have
a link to support the change though.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] wireless-regdb: master-2016-02-08

[Seth Forshee]

A new release of wireless-regdb (master-2016-02-08) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2016.02.08.tar.gz

The short log of changes since the 2015-12-14 release is below.

Thanks,
Seth

---

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

Xose Vazquez Perez (1):
  wireless-regdb: add 2.4GHz regulatory rules for Cuba (CU)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wireless-regdb: add 2.4GHz regulatory rules for Cuba (CU)

[Seth Forshee]

On Wed, Jan 27, 2016 at 10:56:33AM +0100, Xose Vazquez Perez wrote:
> Resolución 127, 2011 - Reglamento Banda 2,4 GHz.:
> http://www.mincom.gob.cu/sites/default/files/marcoregulatorio/R%20127-11%20Reglamento%20banda%202,4%20GHz.pdf
> 
> Cc: Seth Forshee <seth.fors...@canonical.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: wireless-re...@lists.infradead.org
> Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] wireless-regdb: master-2015-12-14

[Seth Forshee]

A new release of wireless-regdb (master-2015-12-14) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2015.12.14.tar.gz

The short log of changes since the 2015-10-22 release is below.

Thanks,
Seth

---

Anssi Hannula (1):
  wireless-regdb: Update regulatory rules for Finland (FI)

Johannes Berg (1):
  regulatory: fix world regdomain

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RegulatoryDB

[Seth Forshee]

On Mon, Nov 23, 2015 at 03:50:53PM -0500, Robert wrote:
> For Educational/Learning Purposes I am attempting to change some
> information in this database... Is it possible to change data within
> this binary file?

You can make changes to db.txt and then build a new binary database from
that. Have a look at
https://wireless.wiki.kernel.org/en/developers/regulatory/wireless-regdb
for more information, and let me know if you have questions which aren't
answered there.

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Update regulatory rules for Croatia (HR)

[Seth Forshee]

On Sun, Oct 18, 2015 at 09:44:19PM +0200, Andrej Vlašić wrote:
> On 15 October 2015 at 20:04, Seth Forshee <seth.fors...@canonical.com> wrote:
> > On Tue, Oct 13, 2015 at 08:31:24PM +0200, Andrej Vlasic wrote:
> >> Update frequency allocation rules to mach data from table [1].
> >>
> >> Also increase allowed power limit for range 5150-5250 Mhz to 200mW.
> >>
> >> [1] http://tablice.hakom.hr:8280/vis?lang=en
> >>
> >> Signed-off-by: Andrej Vlasic <andrej.vlas...@gmail.com>
> >> ---
> >>  db.txt | 14 ++
> >>  1 file changed, 10 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/db.txt b/db.txt
> >> index d57ea84..3b36616 100644
> >> --- a/db.txt
> >> +++ b/db.txt
> >> @@ -504,11 +504,17 @@ country HN: DFS-FCC
> >>   (5490 - 5730 @ 160), (24), DFS
> >>   (5735 - 5835 @ 80), (30)
> >>
> >> +# Data from table of frequency allocations: 
> >> http://tablice.hakom.hr:8280/vis?lang=en
> >> +# For 5ghz range see 
> >> http://www.hakom.hr/UserDocsImages/op%C4%87e%20dozvole%20prosinac%202009.g/Opca_dozvola_85.pdf
> >> +# and 
> >> http://www.hakom.hr/UserDocsImages/op%C4%87e%20dozvole%20prosinac%202009.g/Opca_dozvola_86.pdf
> >> +# and 
> >> http://www.hakom.hr/UserDocsImages/op%C4%87e%20dozvole%20prosinac%202009.g/Opca_dozvola_87.pdf
> >> +# TPC devices on range 5250-5350 can use 200mW, and 1W on range 5470-5725.
> >> +
> >>  country HR: DFS-ETSI
> >> - (2402 - 2482 @ 40), (20)
> >> - (5170 - 5250 @ 80), (20), AUTO-BW
> >> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> >> - (5490 - 5710 @ 160), (27), DFS
> >> + (2400 - 2483.5 @ 40), (100 mW)
> >> + (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
> >> + (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
> >> + (5470 - 5725 @ 160), (500 mW), DFS
> >>   # 60 gHz band channels 1-4, ref: Etsi En 302 567
> >>   (57000 - 66000 @ 2160), (40)
> >
> > In general the changes look okay to me and in line with the published
> > regulations (I couldn't read some of the documents you linked to, but
> > the limits do look to be in line with ERC/DEC/(01)07 and ECC/DEC/(04)08
> > which are referenced by the frequency allocation table).
> >
> > It seems pretty arbitrary to change from dBm to mW however, especially
> > for those rules whose power limit isn't actually changing. I'd prefer we
> > leave them in dBm for consistency, in which case I think we end up with:
> >
> > country HR: DFS-ETSI
> > (2400 - 2483.5 @ 40), (20)
> > (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> > (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
> > (5470 - 5725 @ 160), (27), DFS
> > # 60 gHz band channels 1-4, ref: Etsi En 302 567
> > (57000 - 66000 @ 2160), (40)
> >
> > If that looks fine to you then I can fix it up when I apply the patch.
> 
> It's fine with me too like that.

Applied with the discussed changes. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] wireless-regdb: master-2015-10-22

[Seth Forshee]

A new release of wireless-regdb (master-2015-10-22) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2015.10.22.tar.gz

The short log of changes since the 2015-10-13 release is below.

Thanks,
Seth

---

Andrej Vlasic (1):
  wireless-regdb: Update regulatory rules for Croatia (HR)

Johannes Berg (1):
  wireless-regdb: fix gHz to GHz

Jouni Malinen (1):
  wireless-regdb: Add 160 MHz channel bandwidth for Greenland (GL)

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Update regulatory rules for Croatia (HR)

[Seth Forshee]

On Tue, Oct 13, 2015 at 08:31:24PM +0200, Andrej Vlasic wrote:
> Update frequency allocation rules to mach data from table [1].
> 
> Also increase allowed power limit for range 5150-5250 Mhz to 200mW.
> 
> [1] http://tablice.hakom.hr:8280/vis?lang=en
> 
> Signed-off-by: Andrej Vlasic 
> ---
>  db.txt | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index d57ea84..3b36616 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -504,11 +504,17 @@ country HN: DFS-FCC
>   (5490 - 5730 @ 160), (24), DFS
>   (5735 - 5835 @ 80), (30)
>  
> +# Data from table of frequency allocations: 
> http://tablice.hakom.hr:8280/vis?lang=en
> +# For 5ghz range see 
> http://www.hakom.hr/UserDocsImages/op%C4%87e%20dozvole%20prosinac%202009.g/Opca_dozvola_85.pdf
> +# and 
> http://www.hakom.hr/UserDocsImages/op%C4%87e%20dozvole%20prosinac%202009.g/Opca_dozvola_86.pdf
> +# and 
> http://www.hakom.hr/UserDocsImages/op%C4%87e%20dozvole%20prosinac%202009.g/Opca_dozvola_87.pdf
> +# TPC devices on range 5250-5350 can use 200mW, and 1W on range 5470-5725.
> +
>  country HR: DFS-ETSI
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (20), AUTO-BW
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (27), DFS
> + (2400 - 2483.5 @ 40), (100 mW)
> + (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
> + (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
> + (5470 - 5725 @ 160), (500 mW), DFS
>   # 60 gHz band channels 1-4, ref: Etsi En 302 567
>   (57000 - 66000 @ 2160), (40)

In general the changes look okay to me and in line with the published
regulations (I couldn't read some of the documents you linked to, but
the limits do look to be in line with ERC/DEC/(01)07 and ECC/DEC/(04)08
which are referenced by the frequency allocation table).

It seems pretty arbitrary to change from dBm to mW however, especially
for those rules whose power limit isn't actually changing. I'd prefer we
leave them in dBm for consistency, in which case I think we end up with:

country HR: DFS-ETSI
(2400 - 2483.5 @ 40), (20)
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (27), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)

If that looks fine to you then I can fix it up when I apply the patch.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: fix gHz to GHz

[Seth Forshee]

On Thu, Oct 15, 2015 at 04:19:19PM +0200, Johannes Berg wrote:
> From: Johannes Berg 
> 
> There's no "g" prefix, only "G" (1e9) that was clearly intended here.
> 
> Signed-off-by: Johannes Berg 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Update ZA rules for 5490-5710 MHz

[Seth Forshee]

On Mon, Oct 05, 2015 at 09:02:02AM -0500, Seth Forshee wrote:
> The Radio Frequency Spectrum Regulations 2015 [1] drops the
> requirement for DFS and TPC in the 5490-5710 MHz range. Update
> the database to remove DFS for this range and remove the 3dB drop
> in the transmit power limit for TPC.
> 
> [1] 
> http://www.ellipsis.co.za/wp-content/uploads/2014/12/Radio-Frequency-Spectrum-Regulations-2015.pdf
> 
> Cc: Karl Möller <k...@excors.net>
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] wireless-regdb: Add 160 MHz channel bandwidth for Greenland (GL)

[Seth Forshee]

On Mon, Oct 05, 2015 at 10:11:57PM +0300, Jouni Malinen wrote:
> This extends regulatory rules for Greenland to allow 160 MHz VHT
> channels. This was missed in the earlier set of patches that added 160
> MHz for large number of countries.
> 
> Signed-off-by: Jouni Malinen 

Applied all 5 patches, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] wireless-regdb: Add 160 MHz channel bandwidth for Greenland (GL)

[Seth Forshee]

On Tue, Oct 13, 2015 at 01:37:58PM -0500, Seth Forshee wrote:
> On Mon, Oct 05, 2015 at 10:11:57PM +0300, Jouni Malinen wrote:
> > This extends regulatory rules for Greenland to allow 160 MHz VHT
> > channels. This was missed in the earlier set of patches that added 160
> > MHz for large number of countries.
> > 
> > Signed-off-by: Jouni Malinen <jo...@qca.qualcomm.com>
> 
> Applied all 5 patches, thanks.

Or maybe not. After I pushed out master-2015-10-13 I noticed that I
somehow missed the first patch. It's applied now, sorry about that.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/5] wireless-regdb: Update TW and US rules to latest regulations

[Seth Forshee]

On Fri, Oct 02, 2015 at 01:28:22PM +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 2, 2015 at 5:26 AM, Seth Forshee <seth.fors...@canonical.com> 
> wrote:
> > On Thu, Oct 01, 2015 at 02:57:42PM +0800, Chen-Yu Tsai wrote:
> >> Hi Seth,
> >>
> >> This is v3 of my TW/US 5GHz updates series. Sorry for the long delay.
> >>
> >> Changes since v2:
> >>
> >>   - Moved the US U-NII-1 (5150 ~ 5250 MHz) patch in front of the TW patch
> >>
> >>   - Drop U-NII-1 power limit from 24 dBm to 23 dBm, to be on the safe
> >> side of 250mW
> >>
> >>
> >> Patch 1 updates the 5470 ~ 5725 MHz rules for Taiwan, specifically
> >> the opening up of 5600 ~ 5650 MHz spectrum previously allocated to
> >> weather radars. The transmission power limit is also corrected to
> >> match the regulations.
> >>
> >> Patch 2 changes the boundary frequencies for each rule for Taiwan to
> >> match the frequency allocation table. The "regulation" database shouldn't
> >> care about artificial channel boundaries.
> >>
> >> Patch 3 updates the transmission power limits for 5150 ~ 5250 MHz for
> >> the US.
> >>
> >> Patch 4 adds the previously unusable 5150 ~ 5250 MHz band for Taiwan.
> >>
> >> Patch 5 updates the transmission power limits for Taiwan, per the NCC's
> >> official reply. This patch may be slightly controversial, as there is
> >> no official English document. Either someone will have to independently
> >> verify this, or translate the Chinese document.
> >
> > This description doesn't quite match the patches. Patch 4 both adds the
> > 5150-5250 MHz band and increases the power limits for 5250-5350 MHz,
> > whereas patch 5 changes the DFS master region to DFS-FCC. Previously the
> > increased power limit for 5250-5350 MHz was part of patch 5 - perhaps
> > you accidentally moved that part to patch 4 when you were updating the
> > patches?
> 
> Indeed. I squashed a fixup into the wrong patch, and tried to fix it.
> Obviously that didn't work out so well.
> 
> > So patches 1-3 look fine to me. I suspect you'll want to move the power
> > limit increase from patch 4 to 5. I'm also going to take a look at a
> > machine translation of the Chinese document, and if that looks to be in
> > agreement with your patches then I should be able to apply them next
> > week sometime.
> 
> Do you want me to send a new version now, or wait for you to go through
> the translation first?

I've taken a look at the translation, and as far as I can tell what
you've done looks okay. So go ahead and resend, and as long as no one
else finds a problem I'll apply all 5.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wireless-regdb: Update ZA rules for 5490-5710 MHz

[Seth Forshee]

The Radio Frequency Spectrum Regulations 2015 [1] drops the
requirement for DFS and TPC in the 5490-5710 MHz range. Update
the database to remove DFS for this range and remove the 3dB drop
in the transmit power limit for TPC.

[1] 
http://www.ellipsis.co.za/wp-content/uploads/2014/12/Radio-Frequency-Spectrum-Regulations-2015.pdf

Cc: Karl Möller <k...@excors.net>
Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index d57ea84..721b081 100644
--- a/db.txt
+++ b/db.txt
@@ -1242,7 +1242,7 @@ country ZA: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5490 - 5710 @ 160), (27), DFS
+   (5490 - 5710 @ 160), (30)
 
 country ZW: DFS-ETSI
(2402 - 2482 @ 40), (20)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for South Africa (ZA) on 5GHz

[Seth Forshee]

On Mon, Sep 28, 2015 at 09:44:20AM +0200, Johannes Berg wrote:
> 
> > The bands don’t quite match up and DFS/TPC is (apparently) not 
> > required for 5470 - 5725. More importantly, the max transmitted power
> > seems to be 1W/30dBm e.i.r.p and not 27dBm.
> 
> Without checking now, just a note: we sometimes have lower limits here
> due to spectral power density, indoor/outdoor or TPC requirements.

One of the documents says that the TPC requirement for that range was
lifted in March 2015, so if it was lowered for TPC then we may be able
to bump it up to 30 dBm.

Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] wireless-regdb: master-2015-09-25

[Seth Forshee]

A new release of wireless-regdb (master-2015-09-25) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2015.09.25.tar.gz

The short log of changes since the 2015-07-20 release is below.

Thanks,
Seth

---

Seth Forshee (2):
  wireless-regdb: Add ETSI as the DFS region for Hong Kong
  wireless-regdb: update regulatory.bin based on preceding changes

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: Add ETSI as the DFS region for Hong Kong

[Seth Forshee]

On Wed, Sep 16, 2015 at 09:22:00AM -0500, Seth Forshee wrote:
> Based on [1], Hong Kong follows ETSI requirements for DFS.
> 
> [1] http://www.ofca.gov.hk/filemanager/ofca/en/content_401/hkta1039.pdf
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wireless-regdb: Add ETSI as the DFS region for Hong Kong

[Seth Forshee]

Based on [1], Hong Kong follows ETSI requirements for DFS.

[1] http://www.ofca.gov.hk/filemanager/ofca/en/content_401/hkta1039.pdf

Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 982db34..d57ea84 100644
--- a/db.txt
+++ b/db.txt
@@ -490,7 +490,7 @@ country GY:
(2402 - 2482 @ 40), (30)
(5735 - 5835 @ 80), (30)
 
-country HK:
+country HK: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (17), AUTO-BW
(5250 - 5330 @ 80), (24), DFS, AUTO-BW
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: add 2.4GHz regulatory rules for Cuba (CU)

[Seth Forshee]

On Tue, Sep 08, 2015 at 03:59:38PM +0200, Xose Vazquez Perez wrote:
> On 08/13/2015 04:31 PM, Seth Forshee wrote:
> 
> > On Tue, Aug 11, 2015 at 03:29:55PM +0200, Xose Vazquez Perez wrote:
> >> Resolución 127, 2011 - Reglamento Banda 2,4 GHz.:
> >> http://www.mincom.gob.cu/sites/default/files/marcoregulatorio/R%20127-11%20Reglamento%20banda%202,4%20GHz.pdf
> >>
> >> Cc: Seth Forshee <seth.fors...@canonical.com>
> >> Cc: linux-wireless@vger.kernel.org
> >> Cc: wireless-re...@lists.infradead.org
> >> Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
> >> ---
> >>  db.txt | 7 +++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/db.txt b/db.txt
> >> index 982db34..2edbf90 100644
> >> --- a/db.txt
> >> +++ b/db.txt
> >> @@ -275,6 +275,13 @@ country CR: DFS-FCC
> >>(5490 - 5730 @ 20), (24), DFS
> >>(5735 - 5835 @ 20), (30)
> >>  
> >> +# http://www.mincom.gob.cu/?q=marcoregulatorio
> >> +# - Redes Informáticas
> >> +# Resolución 127, 2011 - Reglamento Banda 2,4 GHz.
> >> +country CU: DFS-FCC
> >> +  (2400 - 2456 @ 40), (200 mW)
> >> +  (2456 - 2483.5 @ 40), (200 mW)
> >> +
> > 
> > Based on the Google translation of the document you linked to, I don't
> > see anything which would prevent merging these rules into one rule. Am I
> > missing something?
> 
> from 
> http://www.mincom.gob.cu/sites/default/files/marcoregulatorio/R%20127-11%20Reglamento%20banda%202,4%20GHz.pdf
> page 7:
> 
> Artículo 4: Disposiciones de carácter técnico
> [..]
> 4.3.- No obstante lo anterior, los equipos que operen en las frecuencias 
> entre 2456 y
> 2483,5 MHz pueden emplear valores de p.i.r.e superiores, cuando ello se 
> justifique en
> beneficio de objetivos de interés nacional [...]
> 4.4.- Para estos casos es necesario obtener una autorización expresa de la 
> Agencia
> [...]
> 
> If you grant an authorization, for 2456-2483.5 pire can be increased.

Okay, but for the purposes of this database that provision isn't going
to apply, and it seems you agree since you've listed both as having the
exact same power limit. So I'd still prefer that we make it a single
rule.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wireless-regdb: add 2.4GHz regulatory rules for Cuba (CU)

[Seth Forshee]

On Tue, Aug 11, 2015 at 03:29:55PM +0200, Xose Vazquez Perez wrote:
 Resolución 127, 2011 - Reglamento Banda 2,4 GHz.:
 http://www.mincom.gob.cu/sites/default/files/marcoregulatorio/R%20127-11%20Reglamento%20banda%202,4%20GHz.pdf
 
 Cc: Seth Forshee seth.fors...@canonical.com
 Cc: linux-wireless@vger.kernel.org
 Cc: wireless-re...@lists.infradead.org
 Signed-off-by: Xose Vazquez Perez xose.vazq...@gmail.com
 ---
  db.txt | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/db.txt b/db.txt
 index 982db34..2edbf90 100644
 --- a/db.txt
 +++ b/db.txt
 @@ -275,6 +275,13 @@ country CR: DFS-FCC
   (5490 - 5730 @ 20), (24), DFS
   (5735 - 5835 @ 20), (30)
  
 +# http://www.mincom.gob.cu/?q=marcoregulatorio
 +# - Redes Informáticas
 +# Resolución 127, 2011 - Reglamento Banda 2,4 GHz.
 +country CU: DFS-FCC
 + (2400 - 2456 @ 40), (200 mW)
 + (2456 - 2483.5 @ 40), (200 mW)
 +

Based on the Google translation of the document you linked to, I don't
see anything which would prevent merging these rules into one rule. Am I
missing something?

Thanks,
Seth
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/5] wireless-regdb: Update U-NII-2c (5470 ~ 5725 MHz) rules for Taiwan (TW)

[Seth Forshee]

On Tue, Aug 04, 2015 at 09:55:06AM +0800, Chen-Yu Tsai wrote:
 On Tue, Aug 4, 2015 at 9:26 AM, Chen-Yu Tsai w...@csie.org wrote:
  On Tue, Aug 4, 2015 at 2:27 AM, Seth Forshee seth.fors...@canonical.com 
  wrote:
  On Thu, Jul 23, 2015 at 11:32:56AM +0800, Chen-Yu Tsai wrote:
  Taiwan's Ministry of Transportation and Communications revised its
  frequency allocation rules [1] on 2014/11/17, allowing usage of 5600 ~
  5650 MHz, previously allocated to weather radars, to U-NII applications
  with DFS support.
 
  Also, the technical regulations [2] show that for 5470 ~ 5725 MHz U-NII
  applications, the peak transmit power shall not exceed the lesser of
  250 mW (slightly less than 24 dBm) or 11 dBm + 10log B, where B is the
  26dB emission bandwidth in MHz. This is slightly more than 23 dBm for
  20 MHz channels.
 
  This patch updates both. Also add links to the two documents into the
  database.
 
  [1] 
  http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.docfiledisplay=Table+of+radio+frequency+allocation.doc
  [2] 
  http://www.ncc.gov.tw/english/show_file.aspx?table_name=newsfile_sn=681
 
  Signed-off-by: Chen-Yu Tsai w...@csie.org
 
  Sorry for the slow response to these patches.
 
  ---
   db.txt | 10 --
   1 file changed, 8 insertions(+), 2 deletions(-)
 
  diff --git a/db.txt b/db.txt
  index 982db34..5114557 100644
  --- a/db.txt
  +++ b/db.txt
  @@ -1118,11 +1118,17 @@ country TT: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
 
  +# Source:
  +# Table of Frequency Allocations of Republic of China (Taiwan) / Nov 
  2014:
  +#   http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc; 
  \
  +#  filedisplay=Table+of+radio+frequency+allocation.doc
  +# LP0002 Low-power Radio-frequency Devices Technical Regulations / 28 
  Jun 2011:
  +#   
  http://www.ncc.gov.tw/english/show_file.aspx?table_name=newsfile_sn=681
  +#   (section 3.10.1, 4.7)
   country TW: DFS-JP
(2402 - 2472 @ 40), (30)
(5270 - 5330 @ 40), (17), DFS
  - (5490 - 5590 @ 80), (30), DFS
  - (5650 - 5710 @ 40), (30), DFS
  + (5470 - 5725 @ 160), (23), DFS
 
  Based on [2], it looks like this range requires TPC, in which case the
  power limit should be dropped by 3 dB on account of our not supporting
  TPC.
 
  Will fix.
 
  Is there any plan to support multiple rules per band? Such as different
  power limits with vs without TPC, or something like DFS vs indoor only?

Not that I know of. Currently the binary database format is a constraint
on doing anything like that.

 BTW, this band has the exact same restrictions as the US, as specified
 by the FCC. The relevant rules were added in
 
 f894543 wireless-regdb: Add back regulatory rules for US
 
 and expanded to cover the whole band in
 
 3c61549 wireless-regdb: Update 5GHz rules for US
 
 These show the power limit at 23 dBm as well. Any comments on this?

Good question. Afaict this probably originates with commit 31dc1c5e
which defines the limit for 5250-5330 MHz in the US, then using the same
limit for the 5490-5730 MHz rule seemed logical. The 5250-5330 MHz rule
came from QCA then. Adding Jouni to the Cc to see if he can help clarify
how they arrived at 23 dBm.

Hmm, I see now that 15.407(h)(1) says that TPC is not required for
systems with an EIRP of less than 500 mW. In that case I guess maybe we
don't need to drop the power limit by 3 dB, so in light of that 23 dBm
does make sense. The documents you linked to say the same, seemingly
word-for-word, so in all likelihood 23 dBm is actually okay.

Thanks,
Seth
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html