Re: [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
Larry, I've not read your patches your detail, so I comment only on your description. 1. A new routine, ieee80211_init_geo has been written that is called by a driver wishing to use this functionality. The arguments are an ieee80211_device, a two-character ISO3661 country code, and a flag that is true if the device is to be used outdoors. This new routine does the following: The problem is the driver doesn't have good ideas, whether the device is outdoor and in which country it operates. Devices have some information available, but I have definitely a device marketed in Canada, which had an EEPROM value for ETSI as regulatory domain. I would expect the daemon to know, in which country it is and whether the device is used outdoors. Keep also in mind, that this information will be available from the AP at a later time. So there should be an explicit method to request the minimum set or the configuration of daemon. Later the set can be changed again by the AP information provided. b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for communication with the daemon. The first, which is read by the daemon, contains the country and outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data corresponding to the country and indoor/outdoor information passed from the kernel. Michael Buesch already commented on /proc/net. I don't think, that this will be popular with a lot of folks. sysfs should be supported and the mechanism should be comparable to firmware loading. Maybe this could be some kind of udev extension. And make it device specific, the whole approach should not break, if you are accessing two devices connecting to two different access points at the same time, where one of them is configured by the central networking folks, who don't bother to adapt there configs to specific countries and the other is a perfectly conformant local AP, which is used for testing purposes. 2. The user-space daemon, which need not be run as root, does the following: It needs only to run temporarily run as root. I would definitely recommend that all file parsing activities should not run as root. e) It then spins waiting for the existence of file '/proc/net/ieee80211_geo/country', which is the indication that the kernel is requesting data. Again the whole interface should be device specific. I welcome your comments. Part 2 will show a debug dump of the converted database, Part 3 will present the patch needed to add the new routine to the ieee80211 routines, and Part 4 will show the patches needed to modify the bcm43xx driver to use the new routine.. Cheers, Uli -- Uli Kunitz - 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 ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
Uli, Ulrich Kunitz wrote: Larry, I've not read your patches your detail, so I comment only on your description. The problem is the driver doesn't have good ideas, whether the device is outdoor and in which country it operates. Devices have some information available, but I have definitely a device marketed in Canada, which had an EEPROM value for ETSI as regulatory domain. I would expect the daemon to know, in which country it is and whether the device is used outdoors. Keep also in mind, that this information will be available from the AP at a later time. I agree that once the AP is broadcasting the country code, this all gets easier. I have a problem similar to yours in that my interface's EEPROM supplies a code that indicates the world, which leads to the bcm43xx driver code setting 2.4 GHz channels 1 - 14 and then running active scans on all of them. Of course in the US 12, 13 and 14 are illegal and could lead to legal action if the FCC were monitoring outside my house. I don't see any means for the daemon to know its country other than the driver or the user telling it. If such a means exists, I would like to learn of it. My current working model is to supply the country code from a module option when the driver is loaded. So there should be an explicit method to request the minimum set or the configuration of daemon. Later the set can be changed again by the AP information provided. If the daemon is not running, if the country code is , or if it doesn't match any country in the database, the minimum set is supplied, but the driver could call the routine again if it learned more about its environment. b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for communication with the daemon. The first, which is read by the daemon, contains the country and outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data corresponding to the country and indoor/outdoor information passed from the kernel. Michael Buesch already commented on /proc/net. I don't think, that this will be popular with a lot of folks. sysfs should be supported and the mechanism should be comparable to firmware loading. Maybe this could be some kind of udev extension. And make it device specific, the whole approach should not break, if you are accessing two devices connecting to two different access points at the same time, where one of them is configured by the central networking folks, who don't bother to adapt there configs to specific countries and the other is a perfectly conformant local AP, which is used for testing purposes. Based on Michael's comments, I have changed the kernel - user space communication to use sysfs rather than procfs. It also uses only a single mode 0666 file in /sys for communication. The deamon spins waiting for that file to exist, then reads it to get the country and in/out flags. It then writes the geo binary data to the file, closes it, delays a while and then repeats. After the geo data are read, the kernel routine deletes the kobjects that create the sysfs file, loads the geo data into the location supplied by the driver, and exits. Because the /sys file exists for only a short time, I don't think that having it world writable will cause any problems. In addition, the data supplied are thoroughly checked to make sure that it has the proper data for geo information. If the 0666 mode is a problem, the daemon may have to become root to write the data. Because, the geo data is loaded into a data area that is specific to each device, I don't expect any problem with the situation you describe even if the same driver is operating both devices. If I have missed some nuance, please enlighten me. 2. The user-space daemon, which need not be run as root, does the following: It needs only to run temporarily run as root. I would definitely recommend that all file parsing activities should not run as root. At present, it does everything as an unprivileged user. e) It then spins waiting for the existence of file '/proc/net/ieee80211_geo/country', which is the indication that the kernel is requesting data. Again the whole interface should be device specific. This part I don't understand. Everything in the geo data is generic to ieee802.11 devices. As I stated earlier, it will end up in the private data for the device, but I don't see any reason for the daemon to know which device is going to use the data. Thanks for your comments, 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 ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
As announced earlier in this list, I am working on providing kernel support for providing regulatory information to be used to set usable channels, max power, and other information needed by IEEE802.11 drivers. The database will be maintained as a text file processed by a user-space daemon. I now have the complete system running on my machine. The full database and the user space daemon are available through a subversion repository at svn://lwfinger.dynalias.org/ide1/ieee80211_geo. The details of the implementation are as follows: 1. A new routine, ieee80211_init_geo has been written that is called by a driver wishing to use this functionality. The arguments are an ieee80211_device, a two-character ISO3661 country code, and a flag that is true if the device is to be used outdoors. This new routine does the following: a) It establishes a default set of wireless parameters that will be supplied to the driver if the user space daemon is not running, if the daemon does not respond in a timely fashion, or if the daemon supplies data that do not pass rudimentary validity checks. The default data includes b/g channels 1 - 11 for indoor usage at a maximum power of 20 dBm (100 mW). At present, no 5 GHz channels are defined in the default set. This set of parameters should be legal everywhere. b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for communication with the daemon. The first, which is read by the daemon, contains the country and outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data corresponding to the country and indoor/outdoor information passed from the kernel. c) It next spin loops for up to 1 second waiting for the user space daemon to respond. As noted earlier, if this loop times out, the default set is supplied. d) It then calls ieee80211_set_geo to load the channel data into the appropriate place in the ieee80211_device block, and returns the status to the driver. 2. The user-space daemon, which need not be run as root, does the following: a) It verifies that the text file containing the regulatory information is intact by assuming that the last line of the file contains the md5 sum for all of the file except for this last line. The scheme is certainly not tamper proof, but it ensures that whomever has modified the file has some technical skills. If the checksum is not correct, the program generates an appropriate error message and exits. b) It then process the country information consisting of a number pointing to an entry describing the 2.4 GHz band information, a second number pointing to the description of the 5 GHz bands, and a two-character country code. c) It then reads the groups that describe the allowed channels for the 2.4 GHz band and similar information for the 5 GHz bands and builds the tables in the form needed by the ieee80211_geo structure. Each input line consists of (a)the band identification characters b, bg, a, or h, (b) a channel range consisting of the starting and ending channels, (c) the number of channels between each stop (normally 1 for b/g and 4 for a), (d) the maximum eirp power for this channel in dBm, and (e) a set of flags for these channels. Flags currently implemented are for 802.11b only, for passive scanning, or for 802.11h rules. These data are checked to confirm that every group mentioned in the country section is indeed present, that the channels listed are appropriate for that band, and that there are no duplicate channels in any group. If there are any difficulties with the data the daemon aborts. d) It then daemonizes, unless the -F command-line switch was supplied. e) It then spins waiting for the existence of file '/proc/net/ieee80211_geo/country', which is the indication that the kernel is requesting data. f) It then reads the country and outdoor flag, finds the appropriate entries in its internal tables and writes the data back through the pseudo-file.in /proc. If the country code is unknown, a default dataset is supplied. The program then loops back to step e) and waits for the next driver load. A segment of the country section of the data file is as follows (data are 2.4 GHz group, 5 GHz group ISO country name and English country name): 0 0 AO Angola, Republic of 0 0 AI Anguilla 0 0 AG Antigua and Barbuda 9 12 AR Argentina, Argentine Republic 0 0 AM Armenia 0 0 AW Aruba 2 2 AU Australia, Commonwealth of 1 1 AT Austria, Republic of 0 0 AZ Azerbaijan, Republic of A couple of representative groups from the 2.4 GHz band are: # Band Ch_Range Ch_Spacing Power Flags # bgGroup: 0 - Unspecified Country # - Saudi Arabia (http://www.citc.sa) # bg1 - 11 1 20 I # bgGroup: 1 - General European Union (EU) # - India
Re: [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
On Sunday 04 June 2006 00:45, Larry Finger wrote: b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for communication with the daemon. The first, which is read by the daemon, contains the country and outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data corresponding to the country and indoor/outdoor information passed from the kernel. Use sysfs, please. -- 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
