[RFC] Geographical/regulatory information for ieee80211

[RFC] Geographical/regulatory information for ieee80211

[Larry Finger]

I am planning on writing a new routine to be added to net/ieee80211/ieee80211_geo.c that will 
populate an ieee80211_geo object given a country code. The new routine will eliminate the need for 
each driver to do their own.

Finding the allowable channels, etc. for various countries has not been easy; however, Cisco 
(http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter09186a008059c96f.html) 
has what seems to be the most complete listing of country information. Neglecting any discussion of 
maximum power, I have been able to arrange the countries into the following groups:

Group         Countries                      b/g channels          a channels
============================================================================

1        Austria                             1-11                   36, 40, 48, 52

2        Australia, Brazil, Canada           1-11                   36, 40, 44, 48
          Cyprus, Czech Republic, Estonia                            52, 56, 60, 64
          Hong Kong, Ireland, Lithuania, Latvia                     149,153,157,161
          New Zealand, Philippines, Poland
          Slovenia, Slovak Republic
          United States

3        Belgium, Israel                      1-11                  36, 40, 44, 48
                                                                     52, 56, 60, 64

4        Israel Outdoors                      5-13                  36, 40, 44, 48
                                                                     52, 56, 60, 64

5        Switzerland and Liechtenstein        1-11                  36, 40, 44, 48
          France, Hungary, United States Low

6        China, Republic of Korea (1)         1-13                 149,153,157,161

7        Republic of Korea (2)                1-13                  36, 40, 44, 48
                                                                     52, 56, 60, 64
                                                                    100,104,108,112
                                                                    116,120,124
                                                                    149,153,157,161

8        Germany, Denmark, Spain, Finland     1-11                  36, 40, 44, 48
          Great Britain, Iceland, Italy                              52, 56, 60, 64
          Luxembourg, Netherlands, Norway                           104,108,112,116
          Portugal, Sweden                                          120,124,128,132
                                                                    140

9        Greece, India                        1-11

10       Indonesia, Malaysia, Thailand        1-13
          South Africa

11       Japan                                1-14 (14 is b only)   36, 40, 44, 48

12       Japan High                           1-14 (14 is b only)   36, 40, 44, 48
                                                                     52, 56, 60, 64

13       Singapore                            1-13                  36, 40, 44, 48
                                                                     52, 56, 60, 64
                                                                    149,153,157,161

14       Taiwan                               1-13                  56, 60, 64
                                                                    100,104
                                                                    149,153,157,161

Any countries not listed above will be placed in group 9 with b/g channels of 1-11 and no valid "a" 
channels.

Please tell me if I have (a) missed any countries, or (b) gotten them wrong. Once I have a 
"netdev-list approved" set, I will do some coding. I have noticed that not all the ipw2200 codes 
that are listed in Documentation/README.ipw2200 correspond to these groups. All of the differences 
are in the valid "a" channels.

Thanks to Jeff Liebermann (jeffl@comix.santa-cruz.ca.us) for helping me find some of the 
geographical/regulatory info on the Web.

Larry

Re: [RFC] Geographical/regulatory information for ieee80211

[Ulrich Kunitz]

Larry,

the CISCO list is not correct. For Europe the detailed information
can be found in the recommendation ERC/REC 70-03 of the European
Radiocommunications Office. It is downloadable from this page:

http://www.ero.dk/documentation/docs/doccategory.asp?catid=2&catname=ECC/ERC/ECTRA%20Recommendations

The WLAN frequencies are specified in Annex 3 and the national
restrictions can be found in Appendix 3.

So for 802.11b/g channels 1-13 can be used across Europe. France
has some differing power requirements. Italy require license for
outdoor usage. Luxembourg authorisation for public usage. Romania
requires an individual license.

For the 802.11a frequencies, there are three bands: 

Annex 3 Band B 5150-5250 MHz for indoor use (36-48)
Annex 3 Band C 5250-5350 MHz for indoor use (52-64)
Annex 3 Band D 5470-5725 MHz for outdoor use (100-140)

However these bands are not available in all European states,
details can be found in the recommendation. Spain, Portugal,
Greece and Belgium for instance don't allow Annex 3 Band D.

Uli

On Thu, 13 Apr 2006, Larry Finger wrote:

> I am planning on writing a new routine to be added to
> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object given
> a country code. The new routine will eliminate the need for each driver to do
> their own.
> 
> Finding the allowable channels, etc. for various countries has not been easy;
> however, Cisco
> (http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter
> 09186a008059c96f.html) has what seems to be the most complete listing of
> country information. Neglecting any discussion of maximum power, I have been
> able to arrange the countries into the following groups:

-- 
Ulrich Kunitz - kune@deine-taler.de

Re: [RFC] Geographical/regulatory information for ieee80211

[Faidon Liambotis]

Ulrich Kunitz wrote:
> For the 802.11a frequencies, there are three bands: 
> 
> Annex 3 Band B 5150-5250 MHz for indoor use (36-48)
> Annex 3 Band C 5250-5350 MHz for indoor use (52-64)
> Annex 3 Band D 5470-5725 MHz for outdoor use (100-140)
> 
> However these bands are not available in all European states,
> details can be found in the recommendation. Spain, Portugal,
> Greece and Belgium for instance don't allow Annex 3 Band D.
Actually, Greece allows 5150-5250 and 5250-5350MHz for indoor use and
5470-5725 for indoor and outdoor use.
This is quite new though (3rd April) :-)

As I've mailed Larry in private, EU countries will eventually conform to
this:
http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:32005D0513:EN:NOT

Regards,
Faidon

Re: [RFC] Geographical/regulatory information for ieee80211

[Jouni Malinen]

On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:

> I am planning on writing a new routine to be added to 
> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object 
> given a country code. The new routine will eliminate the need for each 
> driver to do their own.

> Neglecting any discussion of maximum power, I have been able to arrange the 
> countries into the following groups:

The maximum power would be quite useful--I would say required--part of
regulatory domain information.. In other words, I would like to see the
groups created in a way that would take differences in power limits into
account. Without this, the groups will need to be re-created at some
point in the future when IEEE 802.11d and IEEE 802.11h would like to use
the same table.. In addition, flag of specifying indoor/outdoor/both
would be a nice addition.

It would be useful to have a text file with all the information in an
easily parseable format. I would like to be able to add a user space
tool that uses this file to take care of channel/TX power policies. The
needed parameters would then be configured for the kernel side 802.11
whenever needed.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [RFC] Geographical/regulatory information for ieee80211

[Larry Finger]

Jouni Malinen wrote:
> The maximum power would be quite useful--I would say required--part of
> regulatory domain information.. In other words, I would like to see the
> groups created in a way that would take differences in power limits into
> account. Without this, the groups will need to be re-created at some
> point in the future when IEEE 802.11d and IEEE 802.11h would like to use
> the same table.. In addition, flag of specifying indoor/outdoor/both
> would be a nice addition.
> 
> It would be useful to have a text file with all the information in an
> easily parseable format. I would like to be able to add a user space
> tool that uses this file to take care of channel/TX power policies. The
> needed parameters would then be configured for the kernel side 802.11
> whenever needed.

Good idea to include power and indoor etc. flags. I will also include flags to indicate that 
scanning should be passive on a given channel.

Have you any thoughts on the structure of the text file for parsing?

Larry

Re: [RFC] Geographical/regulatory information for ieee80211

[Faidon Liambotis]

Jouni Malinen wrote:
> The maximum power would be quite useful--I would say required--part of
> regulatory domain information.. In other words, I would like to see the
> groups created in a way that would take differences in power limits into
> account. Without this, the groups will need to be re-created at some
> point in the future when IEEE 802.11d and IEEE 802.11h would like to use
> the same table.. In addition, flag of specifying indoor/outdoor/both
> would be a nice addition.
Speaking of 802.11h, for the table to be complete, it should specify
which protocol is allowed on a given channel.
EU members allow 802.11h (DFS/TPC) but not 802.11a. This is an important
distinction that, IMHO, should be included in a regulatory information
table.

Regards,
Faidon

Re: [RFC] Geographical/regulatory information for ieee80211

[Christoph Hellwig]

On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
> I am planning on writing a new routine to be added to 
> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object 
> given a country code. The new routine will eliminate the need for each 
> driver to do their own.

This sounds like a generally good idea, but the question is:  do we want
this inside a kernel module or in userspace, either like the regulartory
daemon intel has (unfortunately in binary only form) or as a simple init
script.  I really don't want to recompile my kernel just because regulations
changed, and they seems to do that quite often.

Re: [RFC] Geographical/regulatory information for ieee80211

[Rick Jones]

Christoph Hellwig wrote:
> On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
> 
>>I am planning on writing a new routine to be added to 
>>net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object 
>>given a country code. The new routine will eliminate the need for each 
>>driver to do their own.
> 
> 
> This sounds like a generally good idea, but the question is:  do we want
> this inside a kernel module or in userspace, either like the regulartory
> daemon intel has (unfortunately in binary only form) or as a simple init
> script.  I really don't want to recompile my kernel just because regulations
> changed, and they seems to do that quite often.

Yet I would expect the regulatory bodies to look less favorably on 
something more easily maleable by the end-user.

rick jones

Re: [RFC] Geographical/regulatory information for ieee80211

[Larry Finger]

Rick Jones wrote:
> Christoph Hellwig wrote:
>> On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
>>
>>> I am planning on writing a new routine to be added to 
>>> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo 
>>> object given a country code. The new routine will eliminate the need 
>>> for each driver to do their own.
>>
>>
>> This sounds like a generally good idea, but the question is:  do we want
>> this inside a kernel module or in userspace, either like the regulartory
>> daemon intel has (unfortunately in binary only form) or as a simple init
>> script.  I really don't want to recompile my kernel just because 
>> regulations
>> changed, and they seems to do that quite often.
> 
> Yet I would expect the regulatory bodies to look less favorably on 
> something more easily maleable by the end-user.

I don't think it would make that much difference as the user could easily lie about their locality 
and get any set of parameters that they wanted. Intel avoids this problem by hiding the locality in 
an EEPROM (ipw2200) or by combining the EEPROM information with the binary-only daemon (3945).

I am leaning toward putting the geographical information into a userland daemon. That way we won't 
have to patch the kernel every time a country modifies its regulations. In addition, the kernel will 
be smaller. The downside is that the daemon will have to be updated and supplied in some convenient 
form, perhaps as part of a wireless tools package.

Larry

Re: [RFC] Geographical/regulatory information for ieee80211

[Harald Welte]

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

On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I am leaning toward putting the geographical information into a
> userland daemon. 

I like that idea very much.  This is all control metadate that doesn't
really need to be in the kernel.

> That way we won't have to patch the kernel every time a country
> modifies its regulations. 

that's another advantage.

> In addition, the kernel will be smaller. The downside is that the
> daemon will have to be updated and supplied in some convenient form,
> perhaps as part of a wireless tools package.

Ideally the daemon would get the table of country restrictions from a
policy file (some human-readable ascii?).  That file can then be
downloaded by a cronjob to keep it updated, if desired.  A bit like the
PCI/USB device id databases...

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] Geographical/regulatory information for ieee80211

[Jouni Malinen]

On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:

> I don't think it would make that much difference as the user could easily 
> lie about their locality and get any set of parameters that they wanted. 

Well, not any set.. One of the configured countries, yes, but that is
not same as setting arbitrary TX power limit and allowed channel sets..
Anyway, users should be allowed to move from one country to another and
still being able to use their wlan card (within the limits of the
current location).

> I am leaning toward putting the geographical information into a userland 
> daemon. That way we won't have to patch the kernel every time a country 
> modifies its regulations. In addition, the kernel will be smaller. The 
> downside is that the daemon will have to be updated and supplied in some 
> convenient form, perhaps as part of a wireless tools package.

I'm strongly in favor of doing this in user space, too. In order to
provide some control on what end users do with this, I would consider
including a signature on a data file and have the user space tool verify
that signature before accepting the data. This signature need not be
anything extra secure, i.e., it could just be a keyed checksum of the
file using a well-known key. The main point here is that it shows some
attempt on limiting end users from setting random values to regulatory
limits. Of course, if someone really wants to change these values, they
could do so since the source code for the tool would be available and so
would the key used for signing the file in the first place.

I don't know how secure a system would be needed to pass requirements
that FCC and similar organizations place on wireless devices. I would
like to handle this with fully open source tools and having some kind of
simple signature on the data file would be good starting point. It is up
to vendors then to decide whether they are fine with such a mechanism or
whether some additional tool (like the Intel plan on using a closed
source user space tool) would be needed on top of this.

-- 
Jouni Malinen                                            PGP id EFC895FA