Re: [RFC] Geographical/regulatory information for ieee80211
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 [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpYfGS2xTcML.pgp Description: PGP signature
Re: [RFC] Geographical/regulatory information for ieee80211
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 MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
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=2catname=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 - [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Geographical/regulatory information for ieee80211
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Geographical/regulatory information for ieee80211
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 1Austria 1-11 36, 40, 48, 52 2Australia, Brazil, Canada 1-11 36, 40, 44, 48 Cyprus, Czech Republic, Estonia52, 56, 60, 64 Hong Kong, Ireland, Lithuania, Latvia 149,153,157,161 New Zealand, Philippines, Poland Slovenia, Slovak Republic United States 3Belgium, Israel 1-11 36, 40, 44, 48 52, 56, 60, 64 4Israel Outdoors 5-13 36, 40, 44, 48 52, 56, 60, 64 5Switzerland and Liechtenstein1-11 36, 40, 44, 48 France, Hungary, United States Low 6China, Republic of Korea (1) 1-13 149,153,157,161 7Republic of Korea (2)1-13 36, 40, 44, 48 52, 56, 60, 64 100,104,108,112 116,120,124 149,153,157,161 8Germany, 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 9Greece, India1-11 10 Indonesia, Malaysia, Thailand1-13 South Africa 11 Japan1-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 Singapore1-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 ([EMAIL PROTECTED]) for helping me find some of the geographical/regulatory info on the Web. Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
