Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
Jouni Malinen wrote: On Fri, May 05, 2006 at 03:14:35PM -0500, Larry Finger wrote: The driver may not know the country code, so there should be mechanism for user space to override this. Do you think an environment variable would suffice, or do you propose another scheme? * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit anyone with moderate skills from hacking the channel/power settings, but such hacking will require some effort. I did not see this included in the example file. Did you have more detailed plans on how this would be done? I was anticipating storing the output of an md5sum command in a separate file and comparing the contents of that file with one computed for the database when the daemon initializes. Is there a better scheme? * Each channel in the resulting kernel data structure will have appropriate flags set indicating if it is to be used indoors, outdoors, or both. In addition, if the channel should be used only for passive scanning, a suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it should be used for 802.11b, otherwise both b and g mode will be assumed. In the 5.0 GHz bands, a flag will be set if the channel is to conform with 802.11h or 802.11a standards. 802.11h, radar detection, and DFS may need to be more complex than just a one-bit value of it being enabled. Countries may have different requirements for different areas related to 802.11h.. I'm afraid that I'm not quite ready for the complexity of 802.11h. Obviously, I need to do more reading. The database consists of two sections. The first relates the Country Codes to a wireless group. The second section describes the channel parameters for the groups. Shown below is a fragment showing the Country Code - Group info for a few countries and the definitions for a few of the groups. One way to compress this and possible make maintaining quite a bit easier would be to use two different set of groups: one for 2.4 GHz band and another one for 5 GHz band. Many countries share the same requirements for 2.4 GHz, but have different 5 GHz requirements.. This is not really a requirement, but could end up making this easier to use. I don't think it makes too much difference, but I will consider your suggestion as the database starts to be more complete. Number of Countries: 100 Number of Groups: 15 These are not really needed and unless a tool is used to update this file, they will most likely end up being out of sync at some point ;-). The parser can just read through the file twice if it need to know these numbers before parsing (though, that should not really be needed with dynamic data structures).. Your point is well taken. I will remove that data. # group Country CodeDescription # 1 AT Austria (Standard EU) 1 DE Germany (Standard EU) 2 FRI France Indoor (Not Guyana or La Reunion) 3 FRO France Outdoor (Not Guyana or La Reunion) 4 FR1 French Departments of Guyana and La Reunion Indoor 5 FR2 French Departments of Guyana and La Reunion Outdoor Country code has to be two characters to fit into country IE.. This problem can be resolved for most of France as long as the driver supplies the country code and the indoor/outdoor flag. The table would then be: Group 2 - France (Not Guyana or La Reunion) # bg1 - 8 1100B bg9 - 13 1100I bg9 - 13 1 10O h36 - 48 4200I h52 - 64 4200IP h 100 - 140 4 1000IP h 100 - 140 4 1000OP The details for the two unique French departments may have to come from the still undetermined 802.11h information. AT and DE are a good example of possible use for different 2.4 GHz and 5 GHz groups.. If I remember correctly, they have the same rules for 2.4 GHz, but different for 5 GHz.. (unless--of course--they already changed them since I looked last time.. ;-) Yes they have. Following the decision contained in http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:32005D0513:EN:NOT, all EU members and candidates are to adopt the same standards. Most already have. The differences are outlined in Appendix 3 of the the document downloaded through http://www.ero.dk/documentation/docs/docfiles.asp?docid=1622&wd=N. Things are changing so fast that the information for Greece has already changed. The bottom line is that for most EU countries, the requirements are identical. # Ch. Range - Minimum and Maximum Channels for this range # Ch. Spacing - Number of channels between adjacent entries Other option would be to use start channel and number of channels. Channel spacing is also fixed in practice (1 for 2.4 GHz, 4 for 5 GHz), so i
Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
Michael Buesch wrote: On Friday 05 May 2006 22:14, you wrote: # Groups follow countries # Group 0 - Unspecified Country # # Band Ch. Range Ch. Spacing Power Flags ^ Aren't there countries around, where there are gaps in the allowed channel numbers? (Especially for 802.11a) So it would not be an allowed "range", but an allowed list of channels. Yes, but the gaps are only in 802.11a that I know about. If there is a gap, then I use a second line as was shown in the example for the standard EU specs. In most cases, other factors change as well. I initially was going to specify the allowed channels, but the tables got very long. This way is more compact. 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] Proposed structure for Regulatory/Geographical Wireless database
On Friday 05 May 2006 22:14, you wrote: > # Groups follow countries > # > Group 0 - Unspecified Country > # > # Band Ch. Range Ch. Spacing Power Flags ^ Aren't there countries around, where there are gaps in the allowed channel numbers? (Especially for 802.11a) So it would not be an allowed "range", but an allowed list of channels. -- Greetings Michael. - 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] Proposed structure for Regulatory/Geographical Wireless database
Larry Finger wrote: > Uli Kunitz wrote: > > Larry Finger wrote: > > > > > * A new routine (ieee80211_init_geo ?) will be written to be called by the > > > driver to load the geo structure into the kernel. Information passed to > > > the > > > daemon will be the country code in ASCII and whether the interface is to > > > be > > > used indoors or outdoors. > > > > Would it be possible to support the regulatory domain codes as > > used in the outdated table 105 in Corrigendum 1 for 802.11b? The > > ZD1211 EEPROM contains only this code. An easy translation > > function would be sufficient. Maybe the group codes could be > > misused for it. > > That certainly shouldn't be any difficulty. It could be done in the ZD1211 > driver before it calls the ieee80211_init_geo routine, or it could be done in > the regulatory daemon. I assume that the EEPROM contains X'10' for FCC > regulations, X'31' for Spain, etc. > > Larry Yes, it could be done in the driver. But if there are other drivers having the same issue, the helper function should be integrated in the geo code. Uli -- Uli 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] Proposed structure for Regulatory/Geographical Wireless database
On Fri, May 05, 2006 at 03:14:35PM -0500, Larry Finger wrote: > * A new routine (ieee80211_init_geo ?) will be written to be called by the > driver to load the geo structure into the kernel. Information passed to the > daemon will be the country code in ASCII and whether the interface is to be > used indoors or outdoors. The driver may not know the country code, so there should be mechanism for user space to override this. > * Checksum routines will be used to validate the data base. Such a simple > scheme will not inhibit anyone with moderate skills from hacking the > channel/power settings, but such hacking will require some effort. I did not see this included in the example file. Did you have more detailed plans on how this would be done? > * Each channel in the resulting kernel data structure will have appropriate > flags set indicating if it is to be used indoors, outdoors, or both. In > addition, if the channel should be used only for passive scanning, a > suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it > should be used for 802.11b, otherwise both b and g mode will be assumed. In > the 5.0 GHz bands, a flag will be set if the channel is to conform with > 802.11h or 802.11a standards. 802.11h, radar detection, and DFS may need to be more complex than just a one-bit value of it being enabled. Countries may have different requirements for different areas related to 802.11h.. > The database consists of two sections. The first relates the Country Codes > to a wireless group. The second section describes the channel parameters > for the groups. Shown below is a fragment showing the Country Code - Group > info for a few countries and the definitions for a few of the groups. One way to compress this and possible make maintaining quite a bit easier would be to use two different set of groups: one for 2.4 GHz band and another one for 5 GHz band. Many countries share the same requirements for 2.4 GHz, but have different 5 GHz requirements.. This is not really a requirement, but could end up making this easier to use. > Number of Countries: 100 > Number of Groups: 15 These are not really needed and unless a tool is used to update this file, they will most likely end up being out of sync at some point ;-). The parser can just read through the file twice if it need to know these numbers before parsing (though, that should not really be needed with dynamic data structures).. > # group Country CodeDescription > # > 1 AT Austria (Standard EU) > 1 DE Germany (Standard EU) > 2 FRI France Indoor (Not Guyana or La Reunion) > 3 FRO France Outdoor (Not Guyana or La Reunion) > 4 FR1 French Departments of Guyana and La Reunion Indoor > 5 FR2 French Departments of Guyana and La Reunion Outdoor Country code has to be two characters to fit into country IE.. AT and DE are a good example of possible use for different 2.4 GHz and 5 GHz groups.. If I remember correctly, they have the same rules for 2.4 GHz, but different for 5 GHz.. (unless--of course--they already changed them since I looked last time.. ;-) > # Ch. Range - Minimum and Maximum Channels for this range > # Ch. Spacing - Number of channels between adjacent entries Other option would be to use start channel and number of channels. Channel spacing is also fixed in practice (1 for 2.4 GHz, 4 for 5 GHz), so it may not be needed here. > # Power in mW EIRP I would prefer to see the maximum TX power in dBm, not mW. > # Flag Codes > # B - Both Indoor and Outdoor > # I - Indoor Only > # O - Outdoor Only > # P - Passive Scan Only Some more flags may need to be added in the future. It looks like the format used here makes this trivial to extend. -- 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] Proposed structure for Regulatory/Geographical Wireless database
Dan Williams wrote: On Fri, 2006-05-05 at 15:14 -0500, Larry Finger wrote: Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis, Jouni Malinen, and Harald Welte. The important points of my proposal are as follows: * The database will be maintained as a text file to be processed by a userland daemon that will transform this database into the data structure needed by the ieee80211 code. In addition to the regulatory data, this file will also contain the information needed for the daemon to set the size of its data arrays dynamically. Can you explain a bit more about the dynamic array aspect here? What's that about? Shouldn't the geo-daemon be able to figure this stuff out automatically and tell the ieee80211 stack how many countries and groups there are? It has to parse the file anyway, so it should surely know how many groups and countries there are after parsing it. (or do I just not understand the issues...?) The kernel only has a single geo object for each wireless interface initialized. The kernel routine would state which country it wanted to the daemon, which would supply that one from the entities created one when if parsed the database file. The dynamic aspect is to code the daemon in such a way that changing the number of countries and/or groups will not necessitate changing the code in the daemon. * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo structure into the kernel. Information passed to the daemon will be the country code in ASCII and whether the interface is to be used indoors or outdoors. * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit anyone with moderate skills from hacking the channel/power settings, but such hacking will require some effort. What I'm concerned about is error reporting. And as a distro packager, I don't want any user to have to touch the geo file. That's fine if they do, but nobody should _have_ to. I agree. For error reporting, if the geo file does not exist, or contains invalid information, or if the checksum doesn't match for some reason, what's the failure case? It's not sufficient to just log that to dmesg and fail the attempt, because then a program like wpa_supplicant or NetworkManager will have no clue what the problem is if the driver just returns ENOENT or EFILESUCKS or whatever. This is the same problem we currently have with missing firmware. The failure case is not clearly recognizable by the client. I plan to put the "unknown country" data into the init_geo routine. In case the geo database is not available, has been corrupted, or the daemon is not running, the parameters will be the minimal set of only bg channels 1-11 at minimum power and indoor usage. There would be a valid set of geo parameters in the ieee80211 structure - likely not the ones that were wanted, but a valid set. In addition, a failure code would be sent back to the driver, and the exact reason for the failure logged to dmesg. If the geo data fails to be read, or fails to be validated by the driver, user apps that are trying to make connection attempts need to know exactly why the attempt failed, so they can inform users of the failure in a smart way. That information needs to come through the driver, because user apps that make network connection attempts shouldn't have to talk to the regulatory daemon _at all_. Agreed. Conceptually, the regulatory/geo daemon is part of the kernel and the driver, and just happens to live in userspace because policy +kernel==ohmygodbad. But that means that it's the kernel's responsibility to marshal the error information back to clients of the wireless driver, not the clients problem to ask the regulatory/geo daemon, if it's actually running, what the heck the problem is and why the driver returned the error code it did. U NetworkManager geo-daemon |---|--- K | | driver/iee80211 Think of it as a V, not a triangle. That's where we need to be WRT error reporting. I'm not sure what additional error reporting mechanisms could/should be implemented. Any suggestions? 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] Proposed structure for Regulatory/Geographical Wireless database
Uli Kunitz wrote: Larry Finger wrote: * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo structure into the kernel. Information passed to the daemon will be the country code in ASCII and whether the interface is to be used indoors or outdoors. Would it be possible to support the regulatory domain codes as used in the outdated table 105 in Corrigendum 1 for 802.11b? The ZD1211 EEPROM contains only this code. An easy translation function would be sufficient. Maybe the group codes could be misused for it. That certainly shouldn't be any difficulty. It could be done in the ZD1211 driver before it calls the ieee80211_init_geo routine, or it could be done in the regulatory daemon. I assume that the EEPROM contains X'10' for FCC regulations, X'31' for Spain, etc. 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] Proposed structure for Regulatory/Geographical Wireless database
On Fri, 2006-05-05 at 15:14 -0500, Larry Finger wrote: > Thanks to all that responded to my earlier RFC. A number of changes in my > thinking are based on > those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, > Faidon Liambotis, > Jouni Malinen, and Harald Welte. The important points of my proposal are as > follows: > > * The database will be maintained as a text file to be processed by a > userland daemon that will > transform this database into the data structure needed by the ieee80211 code. > In addition to the > regulatory data, this file will also contain the information needed for the > daemon to set the size > of its data arrays dynamically. Can you explain a bit more about the dynamic array aspect here? What's that about? Shouldn't the geo-daemon be able to figure this stuff out automatically and tell the ieee80211 stack how many countries and groups there are? It has to parse the file anyway, so it should surely know how many groups and countries there are after parsing it. (or do I just not understand the issues...?) > * A new routine (ieee80211_init_geo ?) will be written to be called by the > driver to load the geo > structure into the kernel. Information passed to the daemon will be the > country code in ASCII and > whether the interface is to be used indoors or outdoors. > > * Checksum routines will be used to validate the data base. Such a simple > scheme will not inhibit > anyone with moderate skills from hacking the channel/power settings, but such > hacking will require > some effort. What I'm concerned about is error reporting. And as a distro packager, I don't want any user to have to touch the geo file. That's fine if they do, but nobody should _have_ to. For error reporting, if the geo file does not exist, or contains invalid information, or if the checksum doesn't match for some reason, what's the failure case? It's not sufficient to just log that to dmesg and fail the attempt, because then a program like wpa_supplicant or NetworkManager will have no clue what the problem is if the driver just returns ENOENT or EFILESUCKS or whatever. This is the same problem we currently have with missing firmware. The failure case is not clearly recognizable by the client. If the geo data fails to be read, or fails to be validated by the driver, user apps that are trying to make connection attempts need to know exactly why the attempt failed, so they can inform users of the failure in a smart way. That information needs to come through the driver, because user apps that make network connection attempts shouldn't have to talk to the regulatory daemon _at all_. Conceptually, the regulatory/geo daemon is part of the kernel and the driver, and just happens to live in userspace because policy +kernel==ohmygodbad. But that means that it's the kernel's responsibility to marshal the error information back to clients of the wireless driver, not the clients problem to ask the regulatory/geo daemon, if it's actually running, what the heck the problem is and why the driver returned the error code it did. U NetworkManager geo-daemon |---|--- K | | driver/iee80211 Think of it as a V, not a triangle. That's where we need to be WRT error reporting. Dan - 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] Proposed structure for Regulatory/Geographical Wireless database
Larry Finger wrote: > * A new routine (ieee80211_init_geo ?) will be written to be called by the > driver to load the geo structure into the kernel. Information passed to the > daemon will be the country code in ASCII and whether the interface is to be > used indoors or outdoors. Would it be possible to support the regulatory domain codes as used in the outdated table 105 in Corrigendum 1 for 802.11b? The ZD1211 EEPROM contains only this code. An easy translation function would be sufficient. Maybe the group codes could be misused for it. Uli -- Uli 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
[RFC] Proposed structure for Regulatory/Geographical Wireless database
Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis, Jouni Malinen, and Harald Welte. The important points of my proposal are as follows: * The database will be maintained as a text file to be processed by a userland daemon that will transform this database into the data structure needed by the ieee80211 code. In addition to the regulatory data, this file will also contain the information needed for the daemon to set the size of its data arrays dynamically. * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo structure into the kernel. Information passed to the daemon will be the country code in ASCII and whether the interface is to be used indoors or outdoors. * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit anyone with moderate skills from hacking the channel/power settings, but such hacking will require some effort. * Each channel in the resulting kernel data structure will have appropriate flags set indicating if it is to be used indoors, outdoors, or both. In addition, if the channel should be used only for passive scanning, a suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it should be used for 802.11b, otherwise both b and g mode will be assumed. In the 5.0 GHz bands, a flag will be set if the channel is to conform with 802.11h or 802.11a standards. The database consists of two sections. The first relates the Country Codes to a wireless group. The second section describes the channel parameters for the groups. Shown below is a fragment showing the Country Code - Group info for a few countries and the definitions for a few of the groups. Please send me any comments, etc. Larry === # text file for IEEE80211 Regulatory/Geographical information # # Version of 04 May 2006 # # Information for dynamic array sizing # Number of Countries: 100 Number of Groups: 15 # # Countries listed first # # group Country CodeDescription # 1 AT Austria (Standard EU) 1 DE Germany (Standard EU) 2 FRI France Indoor (Not Guyana or La Reunion) 3 FRO France Outdoor (Not Guyana or La Reunion) 4 FR1 French Departments of Guyana and La Reunion Indoor 5 FR2 French Departments of Guyana and La Reunion Outdoor . . . 9 US United States (FCC) # # # Groups follow countries # Group 0 - Unspecified Country # # Band Ch. Range Ch. Spacing Power Flags # # Band - b, bg, a, or h # Ch. Range - Minimum and Maximum Channels for this range # Ch. Spacing - Number of channels between adjacent entries # Power in mW EIRP # Flag Codes # B - Both Indoor and Outdoor # I - Indoor Only # O - Outdoor Only # P - Passive Scan Only # bg1 - 111100B # Group 1 - General European Union (EU) # bg1 - 13 1100B h36 - 40 4200I h52 - 64 4200IP h 100 - 140 4 1000BP # Group 2 - France Indoor (Not Guyana or La Reunion) # bg1 - 13 1100I h36 - 48 4200I h52 - 64 4200IP h 100 - 140 4 1000IP # Group 3 - France Outdoor (Not Guyana or La Reunion) # bg1 - 8 1100O bg9 - 13 1 10O h 100 - 140 4 1000OP . . . . # Group 9 - US (FCC) # bg1 - 11 1100B a36 - 40 4200I a52 - 64 4200B a 149 - 161 4 1000B # - 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
