On Mon, Feb 23, 2009 at 6:51 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > On Sat, Feb 21, 2009 at 7:31 AM, Gábor Stefanik <netrolller.3d@xxxxxxxxx> wrote: >> On Sat, Feb 21, 2009 at 12:40 AM, Luis R. Rodriguez >> <mcgrof@xxxxxxxxxxxxxxxxxxxxxx> wrote: >>> On Fri, Feb 20, 2009 at 10:07:05PM +0100, Gábor Stefanik wrote: >>>> On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: >>>> > On Fri, Feb 20, 2009 at 11:45 AM, Gábor Stefanik >>>> > <netrolller.3d@xxxxxxxxx> wrote: >>>> >> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez >>>> >> <mcgrof@xxxxxxxxxxxxxxxxxxxxxx> wrote: >>>> >>> On Wed, Feb 18, 2009 at 04:38:10PM -0600, Larry Finger wrote: >>>> >>>> Luis R. Rodriguez wrote: >>>> >>>> > On Wed, Feb 18, 2009 at 01:31:52PM -0800, Johannes Berg wrote: >>>> >>>> >> On Wed, 2009-02-18 at 15:29 -0600, Larry Finger wrote: >>>> >>>> >>> On at least one forum, I have seen the recommendation that a user set their >>>> >>>> >>> regulatory domain by creating the file /etc/modprobe.d/cfg80211 with the >>>> >>>> >>> contents "ieee80211_regdom=US". >>>> >>>> >>> >>>> >>>> >>> That works as long as CONFIG_WIRELESS_OLD_REGULATORY is set in their .config, >>>> >>>> >>> but will fail if it is not. >>>> >>>> >>> >>>> >>>> >>> Should the module_param statement be moved outside the ifdef >>>> >>>> >>> CONFIG_WIRELESS_OLD...? Setting the module parameter that way might not make any >>>> >>>> >>> sense, but it surely shouldn't kill wireless. >>>> >>>> >> I actually see no reason to not just /honour/ it by calling crda with >>>> >>>> >> its parameter if CONFIG_WIRELESS_OLD_REGULATORY isn't set. >>>> >>>> > >>>> >>>> > The idea was that things we want to get rid of will go in OLD_REG. Static regdoms >>>> >>>> > for US, JP and EU fall into that and so does the module parameter. I believe >>>> >>>> > it is silly to keep the module parameter around as we already have userspace >>>> >>>> > APIs to let users set this. >>>> >>>> >>>> >>>> I guess we leave it the way it is. At least the only people that will get caught >>>> >>>> are those that upgrade their distro. >>>> >>> >>>> >>> Yeah, if they disable OLD_REG -- but I am curious which distributions are using this >>>> >>> themselves as well. Would you happen to know ? Or are you mostly seeing just users >>>> >>> doing that themselves? >>>> >> >>>> >> Yes, I was talking about users doing this, users who upgrade their >>>> >> kernel without upgrading their distro. Keeping a modparam provides an >>>> >> easy way for users to upgrade kernels without a full distro upgrade - >>>> >> modparams have a much simpler syntax than init scripts. If we keep the >>>> >> modparam as a way to control CRDA, this is what an user has to do to >>>> >> upgrade: >>>> >> 1. Compile and install the new kernel. (Mostly straightforward, as >>>> >> long as the user has a config and knows how to use make.) >>>> >> 2. Compile and install CRDA. (Straightforward.) >>>> >> 3. echo options cfg80211 ieee80211_regdom="HU" >> >>>> >> /etc/modprobe.d/options (Straightforward.) >>>> >> >>>> >> Removing the modparam changes step 3 to: >>>> >> 3. Find the init scripts, and edit them to include "iw reg set HU", >>>> >> making sure it happens early enough, caring about the syntax, taking >>>> >> into account differences between distros, etc. Possibly includes >>>> >> modifying the initramfs/initrd by hand in some odd distros. (Not >>>> >> straightforward at all, requires knowledge of the distro's inner >>>> >> workings, such as the init version used, e.g. sysvinit, bsdinit, >>>> >> upstart, etc.) >>>> > >>>> > It seems reasonable to keep the module parameter in case iw is not >>>> > installed but if users went through the trouble of installing crda are >>>> > we to not expect users to have iw also by 2.6.30? >>>> > >>>> > Luis >>>> > >>>> >>>> I am not talking about the case when iw is not installed - even if iw >>>> is installed, it is much easier to edit the module options file than >>>> the init scripts. >>> >>> We should strive away from using module parameters and provided we have >>> a good userspace API it should be up to userspace to figure that stuff out. >>> >>> Although an ieee80211_regdom module parameter may be convenient its not >>> productive towards what we want as well -- we shouldn't strive to let your >>> module parameter be the only place to put your location information from >>> userspace. Say you suspend to ram, fly to another country -- you'd want >>> more of an intelligent usersapce figuring out your location for you and you >>> don't want it to muck with your module parameters. >>> >>> Luis >>> >> >> In my proposal, the userspace can still override the regdom set in the >> modparam - it is only for setting the initial regdomain. So, you >> suspend to ram, fly to another country, resume and if you have the >> right utilities installed, userspace will reconfigure your regdomain >> to match the current place. However, it is up to distributors to >> include such utilities, it is quite hard for users to install them >> from sources >> Distributors can also easily include the necessary CRDA command in >> their init scripts, but I am not talking about new distributions, but >> rather users who upgrade their kernel. Removing the modparam would >> amount to requiring users to either upgrade their distro or be >> absolutely confident editing all types of init scripts (be it >> sysvinit, bsdinit, upstart or some other apocryphal init program) to >> get a proper initial regdomain. (In fact, due to the lack of such >> modparam support, right now I am always doing "iw reg set HU" by hand >> on every boot, as I can't figure out how to properly edit the init >> scripts without YaST corrupting them upon the next system update!) >> New distros can do fancy userspace tricks like setting the regdomain >> based on GPS position, but for users of old distros who upgraded their >> kernel/installed compat-wireless, the choice is to either use only the >> world regdomain channels (bad) or set regdomain by hand on every boot >> (inconvenient). >> >> So, here is a more "visual" approach to the proposal (in all of these >> examples, iw and crda are installed): >> >> Case 1: Compat-wireless installed on e.g. Ubuntu Intrepid, in Israel >> 1. System boots up. Cfg80211 from newly installed compat-wireless (and >> NOT the one shipped by the distro) loads with regdom=IL. >> --- The regdomain is now Israel. Channels 12 and 13 are available. --- >> 2. During the init process, network startup is reached. The system >> auto-connects to ESSID "MyNET123", which is on channel 13. IP address >> assigned via DHCP. >> 3. When X starts up, the system is ready for the user to browse the web. >> >> Case 2: Same system if modparam support is removed >> 1. System boots up. Cfg80211 of compat-wireless loads. Initial >> regdomain is hardcoded to World. >> --- The regdomain is World. Only b/g channels 1-11 are available. --- >> 2. Network startup is reached. Auto-connect impossible, as channel 13 >> is disabled. >> 3. X starts up, but no networking - the user must "iw reg set IL" and >> connect by hand, requiring root access. >> >> Case 3: Fedora 11 (with support for setting regdomain based on GPS - I >> hope it will!), in Germany (the user iften roams throughout Europe) >> 1. System boots up. Cfg80211 of the distro loads with regdom=EU. >> --- The regdomain is now EU. --- >> 2. The GPS device is initialized. >> 3. Upon network startup, location is identified as Darmstadt >> University, Germany, so "iw reg set DE" is called. >> --- The regdomain is now DE, which is correct. --- >> 4. Network startup continues, auto-connect to ESSID "Universität" successful. >> 5. Upon X startup, wireless is up with regdom=DE. >> 6. User files to Denmark. Regdomain changes to DK. >> >> Case 4: Same system without modparam support: >> 1. System boots up. Cfg80211 of the distro loads with hardcoded "World". >> --- The regdomain is now World. --- >> 2. The GPS device is initialized. >> 3. Upon network startup, location is identified as Darmstadt >> University, Germany, so "iw reg set DE" is called. >> --- The regdomain is now DE, which is correct. --- >> 4. Network startup continues, auto-connect to ESSID "Universität" successful. >> 5. Upon X startup, wireless is up with regdom=DE. >> 6. User files to Denmark. Regdomain changes to DK. >> >> So, cases 3 and 4 (new, regdomain-aware distro) are equivalent from >> the user's standpoint - but case 1 (old, regdomain-unaware distro with >> compat-wireless adding "aftermarket" CRDA support) is much better than >> case 2. > > If we enable passive scan on channels 12-14 on the world regdomain > (which it seems we should) that would cure this issue as well. > Thoughts? > > Luis > What if the user wants to host an AP? What if "MyNET123" is ad-hoc or mesh? What if the user needs packet injection? Forcing the initial regdomain to world is not a good idea. Channel 13 was also just an example, it could be an 5GHz channel as well. Gábor -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
