Changing the way we handle region codes on Linux (public thread)

Changing the way we handle region codes on Linux (public thread)

[Luis R. Rodriguez]

Note: this e-mail is on a public mailing list.

So Jeffrey pointed out a regression introduced by a recent patch to
update our regulatory domain information on the Atheros driver common
module, ath.ko. Of relevance the patch added Aruba "AW" and made "AW"
the first alpha2 to which the ETSI1_WORLD region code maps to. This
region code used to first map to "AT". The wireless-regdb did not
however yet get an update for "AW" so the next logical step is to add
it to wireless-regdb based on the "AT" for example (or any other
country on the region, as all of those countries are expected to be on
the same region and hence the same regulatory domain). That missing
patch would address the issues reported by Jeffrey, which is that he
was unable to use AP mode of operation as no channels when world
roaming are allowed to start IBSS/AP mode unless you are world roaming
(not the case when a region code is used) and find a nearby AP.

Users tend to get confused by the current region code mapping though
so alternatives we can consider are:

1) If a user selects a regulatory domain manually (either before or
after the wireless driver is loaded) check to see if the alpha2 the
user selected fits in the region of the currently programmed region
code. This would be to search the allCountries[] array, and see if the
programmed region code has a match for the alpha2 the user selected at
all in the array. If this is true then allow the usage of that
regulatory domain for the driver.

2) Treat region codes as world roaming regulatory domains and define
them statically in the ath.ko module as we do with the other 12 world
regulatory domains. The advantage to this solution is these regions
would then *world roam* and this means being able to use the world
roaming features of finding a channel on a passive-scan/no-beaconing
channel and lifting those restrictions. The down side to this is we'd
increase ath.ko in size with however many region codes we support.

I think that sums it up. I'd like to hear input on these on
linux-wireless. I'll address this internally at Atheros also to to see
what we think too and get back to this thread with a path. In th
meantime I'll send a patch for wireless-regdb for AW just to get a
quick resolution to this.

  Luis

Re: Changing the way we handle region codes on Linux (public thread)

[Bob Copeland]

On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:

> I think that sums it up.

I personally still like the idea of pushing the vendor-specific
codes out to user space and having psuedo-country codes for
those (e.g. "ATH_37").  Then the driver doesn't need all of the
static rules loaded all the time and it would drop a lot of
policy code from the driver.  CRDA could be enhanced to load
multiple databases, one for pure iso-3166 codes, one with
Atheros codes, one with Intel, etc.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Changing the way we handle region codes on Linux (public thread)

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>
>> I think that sums it up.
>
> I personally still like the idea of pushing the vendor-specific
> codes out to user space and having psuedo-country codes for
> those (e.g. "ATH_37").  Then the driver doesn't need all of the
> static rules loaded all the time and it would drop a lot of
> policy code from the driver.  CRDA could be enhanced to load
> multiple databases, one for pure iso-3166 codes, one with
> Atheros codes, one with Intel, etc.

There is obviously an added complexity added to userspace for this,
but it seems that having that complexity in userspace is better than
in kernel space. Only reason for not doing this I think would be
perhaps if we can really avoid such custom region codes.

Ultimately what makes more sense to me is to see more trust on the
user's location based on alternative inputs like geoclue but since
this year the Google Summer of Code project failed miserly even by the
midterm who knows when we'll be able to get proper feeds we can use in
the kernel.

But with that said -- I think the region-code scheme is overly complex
and am not sure if aiding it is something we should focus energy and
resources on. It would seem better to me to focus on more cleaner
solutions and leave that old stuff as legacy solutions.

  Luis

Re: Changing the way we handle region codes on Linux (public thread)

[John W. Linville]

On Fri, Nov 06, 2009 at 09:45:29AM -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
> > On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> >
> >> I think that sums it up.
> >
> > I personally still like the idea of pushing the vendor-specific
> > codes out to user space and having psuedo-country codes for
> > those (e.g. "ATH_37").  Then the driver doesn't need all of the
> > static rules loaded all the time and it would drop a lot of
> > policy code from the driver.  CRDA could be enhanced to load
> > multiple databases, one for pure iso-3166 codes, one with
> > Atheros codes, one with Intel, etc.

<snip>

> But with that said -- I think the region-code scheme is overly complex
> and am not sure if aiding it is something we should focus energy and
> resources on. It would seem better to me to focus on more cleaner
> solutions and leave that old stuff as legacy solutions.

That's the thing about "legacy" stuff -- it doesn't go away just from
ignoring it!

FWIW, I think Bob's suggestion makes a lot of sense.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Changing the way we handle region codes on Linux (public thread)

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Fri, Nov 06, 2009 at 09:45:29AM -0800, Luis R. Rodriguez wrote:
>> On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
>> > On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> >
>> >> I think that sums it up.
>> >
>> > I personally still like the idea of pushing the vendor-specific
>> > codes out to user space and having psuedo-country codes for
>> > those (e.g. "ATH_37").  Then the driver doesn't need all of the
>> > static rules loaded all the time and it would drop a lot of
>> > policy code from the driver.  CRDA could be enhanced to load
>> > multiple databases, one for pure iso-3166 codes, one with
>> > Atheros codes, one with Intel, etc.
>
> <snip>
>
>> But with that said -- I think the region-code scheme is overly complex
>> and am not sure if aiding it is something we should focus energy and
>> resources on. It would seem better to me to focus on more cleaner
>> solutions and leave that old stuff as legacy solutions.
>
> That's the thing about "legacy" stuff -- it doesn't go away just from
> ignoring it!

True.

> FWIW, I think Bob's suggestion makes a lot of sense.

Patches welcomed then :)

  Luis

Re: Changing the way we handle region codes on Linux (public thread)

[John W. Linville]

On Fri, Nov 06, 2009 at 11:20:34AM -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Fri, Nov 06, 2009 at 09:45:29AM -0800, Luis R. Rodriguez wrote:
> >> On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
> >> > On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> >> >
> >> >> I think that sums it up.
> >> >
> >> > I personally still like the idea of pushing the vendor-specific
> >> > codes out to user space and having psuedo-country codes for
> >> > those (e.g. "ATH_37").  Then the driver doesn't need all of the
> >> > static rules loaded all the time and it would drop a lot of
> >> > policy code from the driver.  CRDA could be enhanced to load
> >> > multiple databases, one for pure iso-3166 codes, one with
> >> > Atheros codes, one with Intel, etc.
> >
> > <snip>
> >
> >> But with that said -- I think the region-code scheme is overly complex
> >> and am not sure if aiding it is something we should focus energy and
> >> resources on. It would seem better to me to focus on more cleaner
> >> solutions and leave that old stuff as legacy solutions.
> >
> > That's the thing about "legacy" stuff -- it doesn't go away just from
> > ignoring it!
> 
> True.
> 
> > FWIW, I think Bob's suggestion makes a lot of sense.
> 
> Patches welcomed then :)

Haha...OK, I'll put it on my list...  Lurkers are welcome to beat me to it!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Changing the way we handle region codes on Linux (public thread)

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 11:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
>>
>> FWIW, I think Bob's suggestion makes a lot of sense.
>
> Patches welcomed then :)

So this could consist probably of adding one more environment variable
to the passed COUNTRY one that the kernel passes before calling crda,
a group I guess, andif the group is passed the crda can read
/path/grop-regulatory.bin where group could be ATHR for example.

BTW -- the region codes are already present on db.txt -- so the only
thing that group thing could do is allow us to move the 12 regulatory
domains to userspace and I'm not sure if this is someone's time,
specially since I managed to squeeze the 12 world regulatory domains
to 5 structures, the slight modifications between a few are handled
internally on ath.ko through the reg notifier, see:

static void ath_reg_apply_world_flags(struct wiphy *wiphy,
                                      enum nl80211_reg_initiator initiator,
                                      struct ath_regulatory *reg)
{
        switch (reg->regpair->regDmnEnum) {
        case 0x60:
        case 0x63:
        case 0x66:
        case 0x67:
                ath_reg_apply_beaconing_flags(wiphy, initiator);
                break;
        case 0x68:
                ath_reg_apply_beaconing_flags(wiphy, initiator);
                ath_reg_apply_active_scan_flags(wiphy, initiator);
                break;
        }
        return;
}


  Luis

Re: Changing the way we handle region codes on Linux (public thread)

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 11:26 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 11:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>>>
>>> FWIW, I think Bob's suggestion makes a lot of sense.
>>
>> Patches welcomed then :)
>
> So this could consist probably of adding one more environment variable
> to the passed COUNTRY one that the kernel passes before calling crda,
> a group I guess, andif the group is passed the crda can read
> /path/grop-regulatory.bin where group could be ATHR for example.
>
> BTW -- the region codes are already present on db.txt

What I mean by that is a region code is mapped to an alpha2 and then
the first alpha2 for the region code is used to query CRDA and CRDA
already has these alpha2s.

Just for the record I have reviewed possible changes internally and it
seems that we're happy to allow the alpha2 that a user sets through
userspace and trust it for a device if the region code also maps to
the alpha2 the user set. But we're also happy to move more things to
userspace if that is desired.

I'm more inclined to spend a couple of hours on the checking the
alpah2 set by the user than the other solution so if I get some time
I'll eventually hack that up.

 Luis