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.
Larry
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. A clean install should redo the /etc/...
tree and do away with such modifications.
Larry
On Sat, Feb 21, 2009 at 12:40 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Fri, Feb 20, 2009 at 10:07:05PM +0100, G=E1bor Stefanik wrote:
>> On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <[email protected]=
> wrote:
>> > On Fri, Feb 20, 2009 at 11:45 AM, G=E1bor Stefanik
>> > <[email protected]> wrote:
>> >> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
>> >> <[email protected]> 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/cfg8=
0211 with the
>> >>>> >>> contents "ieee80211_regdom=3DUS".
>> >>>> >>>
>> >>>> >>> 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 ifde=
f
>> >>>> >>> CONFIG_WIRELESS_OLD...? Setting the module parameter that w=
ay 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 param=
eter. 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 tha=
t will get caught
>> >>>> are those that upgrade their distro.
>> >>>
>> >>> Yeah, if they disable OLD_REG -- but I am curious which distribu=
tions 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 thei=
r
>> >> kernel without upgrading their distro. Keeping a modparam provide=
s an
>> >> easy way for users to upgrade kernels without a full distro upgra=
de -
>> >> modparams have a much simpler syntax than init scripts. If we kee=
p 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, a=
s
>> >> 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=3D"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, tak=
ing
>> >> 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?
>> >
>> > =A0Luis
>> >
>>
>> I am not talking about the case when iw is not installed - even if i=
w
>> 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 ha=
ve
> a good userspace API it should be up to userspace to figure that stuf=
f out.
>
> Although an ieee80211_regdom module parameter may be convenient its n=
ot
> 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 f=
rom
> userspace. Say you suspend to ram, fly to another country -- you'd wa=
nt
> more of an intelligent usersapce figuring out your location for you a=
nd you
> don't want it to muck with your module parameters.
>
> =A0Luis
>
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=3DIL.
--- 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=
=2E
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=3DEU.
--- 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=E4t" suc=
cessful.
5. Upon X startup, wireless is up with regdom=3DDE.
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"=
=2E
--- 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=E4t" suc=
cessful.
5. Upon X startup, wireless is up with regdom=3DDE.
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.
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
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.
johannes
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?
> A clean install should redo the /etc/...
> tree and do away with such modifications.
Sure, I'd like to see us avoid upgrade issues but I'd also like to phase out
module parameters for which we have created equivalent userspace APIs. I suspect
this is a reasonable case.
Luis
On Mon, Feb 23, 2009 at 12:33 PM, G=C3=A1bor Stefanik
<[email protected]> wrote:
> On Mon, Feb 23, 2009 at 6:51 PM, Luis R. Rodriguez <[email protected]>=
wrote:
>> 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?
Then if you see an AP around you you can determine you can beacon as
well (did you see the new beacon hint patches I sent?) otherwise you
need crda and you need to set your regdomain. Mind you AP support
didn't got in for mac80211 drivers until 2.6.29 where OLD_REG is still
default. The patch in question is for 2.6.30 and it not about
_removing_ OLD_REG, its about not making it default, the patch
suggests removal for 2.6.31.
Also remember that hostapd supports setting the country from the
configuration file as well.
> Forcing the initial
> regdomain to world is not a good idea.
OLD_REG implies just that -- its old, meaning we're moving on to new
things. The new strategy we decided on was to not rely on static
regulatory domains in the kernel so so the only reasonable option in
the absence of location information is to default to world.
> Channel 13 was also just an
> example, it could be an 5GHz channel as well.
Sure, and I posted a new set of patches which enable 5 GHz passive scan=
as well.
Luis
On Fri, Feb 20, 2009 at 11:45 AM, G=C3=A1bor Stefanik
<[email protected]> wrote:
> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
> <[email protected]> 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 us=
er set their
>>> >>> regulatory domain by creating the file /etc/modprobe.d/cfg80211=
with the
>>> >>> contents "ieee80211_regdom=3DUS".
>>> >>>
>>> >>> 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 m=
ight 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=
=2E Static regdoms
>>> > for US, JP and EU fall into that and so does the module parameter=
=2E I believe
>>> > it is silly to keep the module parameter around as we already hav=
e userspace
>>> > APIs to let users set this.
>>>
>>> I guess we leave it the way it is. At least the only people that wi=
ll get caught
>>> are those that upgrade their distro.
>>
>> Yeah, if they disable OLD_REG -- but I am curious which distribution=
s are using this
>> themselves as well. Would you happen to know ? Or are you mostly see=
ing 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 th=
e
> 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=3D"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
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.
Luis
On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <[email protected]> w=
rote:
> On Fri, Feb 20, 2009 at 11:45 AM, G=E1bor Stefanik
> <[email protected]> wrote:
>> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
>> <[email protected]> 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 u=
ser set their
>>>> >>> regulatory domain by creating the file /etc/modprobe.d/cfg8021=
1 with the
>>>> >>> contents "ieee80211_regdom=3DUS".
>>>> >>>
>>>> >>> 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 crd=
a 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_RE=
G. Static regdoms
>>>> > for US, JP and EU fall into that and so does the module paramete=
r. I believe
>>>> > it is silly to keep the module parameter around as we already ha=
ve userspace
>>>> > APIs to let users set this.
>>>>
>>>> I guess we leave it the way it is. At least the only people that w=
ill get caught
>>>> are those that upgrade their distro.
>>>
>>> Yeah, if they disable OLD_REG -- but I am curious which distributio=
ns are using this
>>> themselves as well. Would you happen to know ? Or are you mostly se=
eing 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 a=
n
>> easy way for users to upgrade kernels without a full distro upgrade =
-
>> modparams have a much simpler syntax than init scripts. If we keep t=
he
>> 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=3D"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 ar=
e
> we to not expect users to have iw also by 2.6.30?
>
> =A0Luis
>
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.
G=E1bor
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Sat, Feb 21, 2009 at 7:31 AM, G=C3=A1bor Stefanik <netrolller.3d@gma=
il.com> wrote:
> On Sat, Feb 21, 2009 at 12:40 AM, Luis R. Rodriguez
> <[email protected]> wrote:
>> On Fri, Feb 20, 2009 at 10:07:05PM +0100, G=C3=A1bor Stefanik wrote:
>>> On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <[email protected]=
m> wrote:
>>> > On Fri, Feb 20, 2009 at 11:45 AM, G=C3=A1bor Stefanik
>>> > <[email protected]> wrote:
>>> >> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
>>> >> <[email protected]> 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 wrot=
e:
>>> >>>> >> 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/cfg=
80211 with the
>>> >>>> >>> contents "ieee80211_regdom=3DUS".
>>> >>>> >>>
>>> >>>> >>> That works as long as CONFIG_WIRELESS_OLD_REGULATORY is se=
t in their .config,
>>> >>>> >>> but will fail if it is not.
>>> >>>> >>>
>>> >>>> >>> Should the module_param statement be moved outside the ifd=
ef
>>> >>>> >>> 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 OL=
D_REG. Static regdoms
>>> >>>> > for US, JP and EU fall into that and so does the module para=
meter. I believe
>>> >>>> > it is silly to keep the module parameter around as we alread=
y have userspace
>>> >>>> > APIs to let users set this.
>>> >>>>
>>> >>>> I guess we leave it the way it is. At least the only people th=
at will get caught
>>> >>>> are those that upgrade their distro.
>>> >>>
>>> >>> Yeah, if they disable OLD_REG -- but I am curious which distrib=
utions are using this
>>> >>> themselves as well. Would you happen to know ? Or are you mostl=
y seeing just users
>>> >>> doing that themselves?
>>> >>
>>> >> Yes, I was talking about users doing this, users who upgrade the=
ir
>>> >> kernel without upgrading their distro. Keeping a modparam provid=
es an
>>> >> easy way for users to upgrade kernels without a full distro upgr=
ade -
>>> >> modparams have a much simpler syntax than init scripts. If we ke=
ep the
>>> >> modparam as a way to control CRDA, this is what an user has to d=
o 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=3D"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 H=
U",
>>> >> making sure it happens early enough, caring about the syntax, ta=
king
>>> >> 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 no=
t
>>> > installed but if users went through the trouble of installing crd=
a 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 tha=
n
>>> the init scripts.
>>
>> We should strive away from using module parameters and provided we h=
ave
>> a good userspace API it should be up to userspace to figure that stu=
ff out.
>>
>> Although an ieee80211_regdom module parameter may be convenient its =
not
>> productive towards what we want as well -- we shouldn't strive to le=
t 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 w=
ant
>> 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 th=
e
> 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 thei=
r
> kernel/installed compat-wireless, the choice is to either use only th=
e
> 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 (an=
d
> NOT the one shipped by the distro) loads with regdom=3DIL.
> --- 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 w=
eb.
>
> 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=3DEU.
> --- 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=C3=A4t=
" successful.
> 5. Upon X startup, wireless is up with regdom=3DDE.
> 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 "Worl=
d".
> --- 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=C3=A4t=
" successful.
> 5. Upon X startup, wireless is up with regdom=3DDE.
> 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 wit=
h
> compat-wireless adding "aftermarket" CRDA support) is much better tha=
n
> 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
On Mon, Feb 23, 2009 at 1:36 PM, G=C3=A1bor Stefanik <netrolller.3d@gma=
il.com> wrote:
> On Mon, Feb 23, 2009 at 10:18 PM, Luis R. Rodriguez <[email protected]=
> wrote:
>> On Mon, Feb 23, 2009 at 12:33 PM, G=C3=A1bor Stefanik
>> <[email protected]> wrote:
>>> On Mon, Feb 23, 2009 at 6:51 PM, Luis R. Rodriguez <[email protected]=
m> wrote:
>>
>>>> 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?
>>
>> Then if you see an AP around you you can determine you can beacon as
>> well (did you see the new beacon hint patches I sent?) otherwise you
>> need crda and you need to set your regdomain. Mind you AP support
>> didn't got in for mac80211 drivers until 2.6.29 where OLD_REG is sti=
ll
>> default. The patch in question is for 2.6.30 and it not about
>> _removing_ OLD_REG, its about not making it default, the patch
>> suggests removal for 2.6.31.
>>
>> Also remember that hostapd supports setting the country from the
>> configuration file as well.
>>
>>> Forcing the initial
>>> regdomain to world is not a good idea.
>>
>> OLD_REG implies just that -- its old, meaning we're moving on to new
>> things. The new strategy we decided on was to not rely on static
>> regulatory domains in the kernel so so the only reasonable option in
>> the absence of location information is to default to world.
>
> I mean forcing the initial regdomain to world even when CRDA is
> available - the only way to set the regdomain on boot without the
> modparam on an existing distro is editing init scripts, which changes
> depending on the distro.
Its not about "init scripts", its about userspace.
> (I've seen distros which didn't allow direct
> editing of init scripts, instead they were auto-generated on each
> software change!) A distro upgrade is not always an option.
This isn't about init scripts or not, this is about userspace/kernel
space. Init scripts should only be used if your current software
doesn't support allowing you to set regdomains. wpa_supplicant and
hostapd already support this, network manager doesn't though and that
I think is a good argument to keep around the module parameter for a
bit longer.
So what if we set OLD_REG to default to n, and allow the module
parameter to exist with OLD_REG and without it for a while (until I
guess Network Manager picks up setting regdomains).
Keep in mind if your card is already providing a regulatory hint such
as ath9k, zd1211rw you don't even need to set your regdomain -- unless
you want to help compliance further.
>>> Channel 13 was also just an
>>> example, it could be an 5GHz channel as well.
>>
>> Sure, and I posted a new set of patches which enable 5 GHz passive s=
can as well.
>
> On all channels that may be available somewhere, or is it just an int=
ersection?
On the non-DFS frequency range of standard IEEE-802.11a channels
Luis
On Fri, Feb 20, 2009 at 10:07:05PM +0100, G=E1bor Stefanik wrote:
> On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <[email protected]>=
wrote:
> > On Fri, Feb 20, 2009 at 11:45 AM, G=E1bor Stefanik
> > <[email protected]> wrote:
> >> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
> >> <[email protected]> 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/cfg80=
211 with the
> >>>> >>> contents "ieee80211_regdom=3DUS".
> >>>> >>>
> >>>> >>> 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 wa=
y might not make any
> >>>> >>> sense, but it surely shouldn't kill wireless.
> >>>> >> I actually see no reason to not just /honour/ it by calling c=
rda 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 parame=
ter. 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 distribut=
ions 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 upgrad=
e -
> >> 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=3D"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, taki=
ng
> >> 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?
> >
> > =A0Luis
> >
>=20
> 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 y=
our
module parameter be the only place to put your location information fro=
m
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
On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
<[email protected]> 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 use=
r set their
>> >>> regulatory domain by creating the file /etc/modprobe.d/cfg80211 =
with the
>> >>> contents "ieee80211_regdom=3DUS".
>> >>>
>> >>> That works as long as CONFIG_WIRELESS_OLD_REGULATORY is set in t=
heir .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 mi=
ght 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 wil=
l 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 seei=
ng 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=3D"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.)
>
>> A clean install should redo the /etc/...
>> tree and do away with such modifications.
>
> Sure, I'd like to see us avoid upgrade issues but I'd also like to ph=
ase out
> module parameters for which we have created equivalent userspace APIs=
=2E I suspect
> this is a reasonable case.
>
> =A0Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
> the body of a message to [email protected]
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Mon, Feb 23, 2009 at 10:18 PM, Luis R. Rodriguez <[email protected]> =
wrote:
> On Mon, Feb 23, 2009 at 12:33 PM, G=E1bor Stefanik
> <[email protected]> wrote:
>> On Mon, Feb 23, 2009 at 6:51 PM, Luis R. Rodriguez <[email protected]=
> wrote:
>
>>> 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?
>>>
>>> =A0Luis
>>>
>>
>> What if the user wants to host an AP? What if "MyNET123" is ad-hoc o=
r
>> mesh? What if the user needs packet injection?
>
> Then if you see an AP around you you can determine you can beacon as
> well (did you see the new beacon hint patches I sent?) otherwise you
> need crda and you need to set your regdomain. Mind you AP support
> didn't got in for mac80211 drivers until 2.6.29 where OLD_REG is stil=
l
> default. The patch in question is for 2.6.30 and it not about
> _removing_ OLD_REG, its about not making it default, the patch
> suggests removal for 2.6.31.
>
> Also remember that hostapd supports setting the country from the
> configuration file as well.
>
>> Forcing the initial
>> regdomain to world is not a good idea.
>
> OLD_REG implies just that -- its old, meaning we're moving on to new
> things. The new strategy we decided on was to not rely on static
> regulatory domains in the kernel so so the only reasonable option in
> the absence of location information is to default to world.
I mean forcing the initial regdomain to world even when CRDA is
available - the only way to set the regdomain on boot without the
modparam on an existing distro is editing init scripts, which changes
depending on the distro. (I've seen distros which didn't allow direct
editing of init scripts, instead they were auto-generated on each
software change!) A distro upgrade is not always an option.
>
>> Channel 13 was also just an
>> example, it could be an 5GHz channel as well.
>
> Sure, and I posted a new set of patches which enable 5 GHz passive sc=
an as well.
On all channels that may be available somewhere, or is it just an inter=
section?
>
> =A0Luis
>
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Wed, Feb 18, 2009 at 11:34:58PM +0100, G=E1bor Stefanik wrote:
> On Wed, Feb 18, 2009 at 11:05 PM, Luis R. Rodriguez
> <[email protected]> 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 use=
r set their
> >> > regulatory domain by creating the file /etc/modprobe.d/cfg80211 =
with the
> >> > contents "ieee80211_regdom=3DUS".
> >> >
> >> > That works as long as CONFIG_WIRELESS_OLD_REGULATORY is set in t=
heir .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 mi=
ght not make any
> >> > sense, but it surely shouldn't kill wireless.
> >>
> >> I actually see no reason to not just /honour/ it by calling crda w=
ith
> >> 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.
>=20
> Keeping the module parameter as a way to set the initial regdomain is
> helpful for users who upgrade the kernel of an older distro.
This makes sense, but what distributions are using this module paramete=
r?
As far as I can tell its only users using it.
And if there are distributions using it -- can we not expect them to st=
op
using it by they disable OLD_REG?
> Adding a
> line to /etc/modprobe.d/options would be a much easier way of setting
> the right regdomain right during bootup than having to edit the init
> scripts
Using init scripts is just one way of doing this, its not the only way.
Userspace can use user-configuration settings through wpa_supplicant,
hostapd, GPS devices can also provide hints, say through the usage of
GeoClue. That's really a lot neater than a module parameter or an init
script.
> and it is also something that CRDA's "make install" could do
> automagically (like "make install regdom=3DHU").
I'd rather not make that a practice provided we want to phase out OLD_R=
EG
and we want userspace to use nl80211 for this.
Luis
On Wed, Feb 18, 2009 at 11:05 PM, Luis R. Rodriguez
<[email protected]> 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.
Keeping the module parameter as a way to set the initial regdomain is
helpful for users who upgrade the kernel of an older distro. Adding a
line to /etc/modprobe.d/options would be a much easier way of setting
the right regdomain right during bootup than having to edit the init
scripts, and it is also something that CRDA's "make install" could do
automagically (like "make install regdom=HU").
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Mon, Feb 23, 2009 at 6:51 PM, Luis R. Rodriguez <[email protected]> w=
rote:
> On Sat, Feb 21, 2009 at 7:31 AM, G=E1bor Stefanik <netrolller.3d@gmai=
l.com> wrote:
>> On Sat, Feb 21, 2009 at 12:40 AM, Luis R. Rodriguez
>> <[email protected]> wrote:
>>> On Fri, Feb 20, 2009 at 10:07:05PM +0100, G=E1bor Stefanik wrote:
>>>> On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <[email protected]=
om> wrote:
>>>> > On Fri, Feb 20, 2009 at 11:45 AM, G=E1bor Stefanik
>>>> > <[email protected]> wrote:
>>>> >> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez
>>>> >> <[email protected]> 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 wro=
te:
>>>> >>>> >> On Wed, 2009-02-18 at 15:29 -0600, Larry Finger wrote:
>>>> >>>> >>> On at least one forum, I have seen the recommendation tha=
t a user set their
>>>> >>>> >>> regulatory domain by creating the file /etc/modprobe.d/cf=
g80211 with the
>>>> >>>> >>> contents "ieee80211_regdom=3DUS".
>>>> >>>> >>>
>>>> >>>> >>> That works as long as CONFIG_WIRELESS_OLD_REGULATORY is s=
et in their .config,
>>>> >>>> >>> but will fail if it is not.
>>>> >>>> >>>
>>>> >>>> >>> Should the module_param statement be moved outside the if=
def
>>>> >>>> >>> 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 callin=
g 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 O=
LD_REG. Static regdoms
>>>> >>>> > for US, JP and EU fall into that and so does the module par=
ameter. I believe
>>>> >>>> > it is silly to keep the module parameter around as we alrea=
dy have userspace
>>>> >>>> > APIs to let users set this.
>>>> >>>>
>>>> >>>> I guess we leave it the way it is. At least the only people t=
hat will get caught
>>>> >>>> are those that upgrade their distro.
>>>> >>>
>>>> >>> Yeah, if they disable OLD_REG -- but I am curious which distri=
butions are using this
>>>> >>> themselves as well. Would you happen to know ? Or are you most=
ly seeing just users
>>>> >>> doing that themselves?
>>>> >>
>>>> >> Yes, I was talking about users doing this, users who upgrade th=
eir
>>>> >> kernel without upgrading their distro. Keeping a modparam provi=
des an
>>>> >> easy way for users to upgrade kernels without a full distro upg=
rade -
>>>> >> modparams have a much simpler syntax than init scripts. If we k=
eep 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=3D"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, t=
aking
>>>> >> into account differences between distros, etc. Possibly include=
s
>>>> >> modifying the initramfs/initrd by hand in some odd distros. (No=
t
>>>> >> straightforward at all, requires knowledge of the distro's inne=
r
>>>> >> 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 n=
ot
>>>> > installed but if users went through the trouble of installing cr=
da are
>>>> > we to not expect users to have iw also by 2.6.30?
>>>> >
>>>> > =A0Luis
>>>> >
>>>>
>>>> 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 th=
an
>>>> 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 st=
uff out.
>>>
>>> Although an ieee80211_regdom module parameter may be convenient its=
not
>>> productive towards what we want as well -- we shouldn't strive to l=
et 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.
>>>
>>> =A0Luis
>>>
>>
>> In my proposal, the userspace can still override the regdom set in t=
he
>> 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, bu=
t
>> 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 han=
d
>> 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 the=
ir
>> kernel/installed compat-wireless, the choice is to either use only t=
he
>> world regdomain channels (bad) or set regdomain by hand on every boo=
t
>> (inconvenient).
>>
>> So, here is a more "visual" approach to the proposal (in all of thes=
e
>> 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 (a=
nd
>> NOT the one shipped by the distro) loads with regdom=3DIL.
>> --- 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 addres=
s
>> 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 1=
3
>> is disabled.
>> 3. X starts up, but no networking - the user must "iw reg set IL" an=
d
>> 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=3DEU.
>> --- 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=E4t" =
successful.
>> 5. Upon X startup, wireless is up with regdom=3DDE.
>> 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 "Wor=
ld".
>> --- 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=E4t" =
successful.
>> 5. Upon X startup, wireless is up with regdom=3DDE.
>> 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 wi=
th
>> compat-wireless adding "aftermarket" CRDA support) is much better th=
an
>> 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?
>
> =A0Luis
>
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=E1bor
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)