Getting random regulatory domains on boot-up with ath9k

Getting random regulatory domains on boot-up with ath9k

[Jeffrey Baker]

I am trying to work with a card made with Atheros 9280, but I find
that I am getting essentially random regulatory domains.  The very
first time I booted the system, under Linux 2.6.30, I got the country
code AT.  Subsequently I got US.  Then I upgraded to
compat-wireless-2009-11-06 and now I get AW (Aruba).

dmesg says:

ath: EEPROM regdomain: 0x37
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: AW
ath: Regpair used: 0x37
cfg80211: Calling CRDA for country: AW

Now, my understanding is that 0x37 is world roaming.  The key sentence
from the docs seems to be this:

"Regulatory pair regulatory domains are mapped to the first
ISO-3166-alpha2 country."

Does that mean that AW is the first country code in the 0x37
regulatory pair group?

The result is this list of channels

5180 MHz [36] (30.0 dBm) (passive scanning, no IBSS)
5200 MHz [40] (30.0 dBm) (passive scanning, no IBSS)
5220 MHz [44] (30.0 dBm) (passive scanning, no IBSS)
5240 MHz [48] (30.0 dBm) (passive scanning, no IBSS)
5260 MHz [52] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5280 MHz [56] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5300 MHz [60] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5320 MHz [64] (30.0 dBm) (passive scanning, no IBSS, radar detection)
5500 MHz [100] (disabled)
5520 MHz [104] (disabled)
5540 MHz [108] (disabled)
5560 MHz [112] (disabled)
5580 MHz [116] (disabled)
5600 MHz [120] (disabled)
5620 MHz [124] (disabled)
5640 MHz [128] (disabled)
5660 MHz [132] (disabled)
5680 MHz [136] (disabled)
5700 MHz [140] (disabled)
5745 MHz [149] (30.0 dBm) (passive scanning, no IBSS)
5765 MHz [153] (30.0 dBm) (passive scanning, no IBSS)
5785 MHz [157] (30.0 dBm) (passive scanning, no IBSS)
5805 MHz [161] (30.0 dBm) (passive scanning, no IBSS)
5825 MHz [165] (30.0 dBm) (passive scanning, no IBSS)

... which in summary prevents me from operating an access point in the
5GHz band at all.  The perplexing thing is that I was able to use
channel 36 under kernel.org 2.6.30, so from my perspective that
software was working better than the current software does, and of
course leads me to believe that I can use software to change this card
to FCC regs instead of these frustrating "world" regs which prevent me
from running an AP.

Needless to say, I am perplexed by this behavior. The exact phy is
"Atheros AR9280 Rev:2"

-jwb

Re: Getting random regulatory domains on boot-up with ath9k

[Holger Schurig]

> ath: EEPROM regdomain: 0x37
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: AW
> ath: Regpair used: 0x37
> cfg80211: Calling CRDA for country: AW

I can confirm this bug on wireless-testing, v2.6.32-rc6-41576-g4408b3b
with an ath5k card:

[    9.193118] ath: doing EEPROM country->regdmn map search
[    9.193121] ath: country maps to regdmn code: 0x37
[    9.193124] ath: Country alpha2 being used: DK
[    9.193126] ath: Regpair used: 0x37
[    9.207182] phy0: Selected rate control algorithm 'minstrel'
[    9.207874] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
[    9.208801] cfg80211: Calling CRDA for country: DK
[    9.221773] cfg80211: Regulatory domain changed to country: DK

Re: Getting random regulatory domains on boot-up with ath9k

[Davide Pesavento]

On Fri, Nov 6, 2009 at 10:50, Holger Schurig
<holgerschurig@googlemail.com> wrote:
>> ath: EEPROM regdomain: 0x37
>> ath: EEPROM indicates we should expect a direct regpair map
>> ath: Country alpha2 being used: AW
>> ath: Regpair used: 0x37
>> cfg80211: Calling CRDA for country: AW
>
> I can confirm this bug on wireless-testing, v2.6.32-rc6-41576-g4408b3b
> with an ath5k card:
>

Confirmed on wireless-testing v2.6.32-rc6-wl-41575-g5e68bfb with an
AR5418 card using ath9k. Also 'iw reg set <country code>' stopped
working. Last known working kernel is v2.6.32-rc5-wl-40584-g9b469da.

[   12.573257] ath: EEPROM regdomain: 0x37
[   12.573259] ath: EEPROM indicates we should expect a direct regpair map
[   12.573262] ath: Country alpha2 being used: AW
[   12.573264] ath: Regpair used: 0x37
[   12.579608] cfg80211: Calling CRDA for country: AW

Regards,
Davide

Re: Getting random regulatory domains on boot-up with ath9k

[Sebastian Kemper]

Davide Pesavento wrote:
> Confirmed on wireless-testing v2.6.32-rc6-wl-41575-g5e68bfb with an
> AR5418 card using ath9k. Also 'iw reg set <country code>' stopped
> working. Last known working kernel is v2.6.32-rc5-wl-40584-g9b469da.

I noticed this as well with ath9k on 2.6.32-rc6. Has this been fixed
already? If not I could spend some time trying to find the patch that
caused the regression.

Regards
Sebastian

Re: Getting random regulatory domains on boot-up with ath9k

[Luis R. Rodriguez]

On Tue, Nov 10, 2009 at 2:03 AM, Sebastian Kemper <sebastian_ml@gmx.net> wrote:
> Davide Pesavento wrote:
>> Confirmed on wireless-testing v2.6.32-rc6-wl-41575-g5e68bfb with an
>> AR5418 card using ath9k. Also 'iw reg set <country code>' stopped
>> working. Last known working kernel is v2.6.32-rc5-wl-40584-g9b469da.
>
> I noticed this as well with ath9k on 2.6.32-rc6. Has this been fixed
> already? If not I could spend some time trying to find the patch that
> caused the regression.

This was caused by a regression of mapping a region code to an alpha2
which does not have an entry on wireless-regdb, I sent a patch to
address this on wireless-regdb.

  Luis

Re: Getting random regulatory domains on boot-up with ath9k

[Holger Schurig]

Hmm, maybe it's not a bug after all.

The card's eeprom just have a region, 0x37 is ETSI World. Now the
kernel looks for the first country with this region and uses this for
crda.

There have been changes to drivers/net/wireless/ath/regd_common.h
recently, so maybe on one kernel-version "DK" is the first ETSI World,
on the next "AW" is the first and on some other again some different
country.

So it's just misleading, e.g.

    using first country with regdm 0x37: DK

would probably a better dmesg output.



If you however can reproduce that with the same kernel you always get
different output after each reboot, then we have a bug here.

Re: Getting random regulatory domains on boot-up with ath9k

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 4:05 AM, Holger Schurig
<holgerschurig@googlemail.com> wrote:
> Hmm, maybe it's not a bug after all.

Right.

> The card's eeprom just have a region, 0x37 is ETSI World. Now the
> kernel looks for the first country with this region and uses this for
> crda.

The atheros driver does this, that is right. This is just one way in
which the EEPROM can be programmed on Atheros cards, a way which I
hope will disappear as this obviously can confuse users.

> There have been changes to drivers/net/wireless/ath/regd_common.h
> recently, so maybe on one kernel-version "DK" is the first ETSI World,
> on the next "AW" is the first and on some other again some different
> country.

Right, this is exactly what happens.

So the search is for any alpha2 for 0x37 (ETSI1_WORLD) on the Atheros
regulatory table allCountries[]. There are a few and recently the
first alpha2 was made 'AW' as noted. Reason for searching for the
first one is all of the alpha2s that match ETSI1_WORLD all have the
same regulatory domain so the way to think about these is more of a
region code and that region code maps to a certain number of alpha2s
which all happen to have the same exact regulatory domain definitions.
This obviously can change over time but for Windows driver this
behavior is static as the driver remains static unless a change is
requested by an ODM. For Linux this is different -- we get all the
updates, and IMHO this is good but this also means this one way of
programming the EEPROM should be avoided and eventually dropped. That
will take time but I had already started poking internally for a
change.

In the meantime I've tried to document the regulatory details on the
wiki so interested users / developers can understand what is going on.

So for ETSI1_WORLD we have these mappings, in this order now on
wireless-testing (bleeding edge):

mcgrof@tux ~/wireless-testing (git::my-stuff)$ grep ETSI1_WORLD
drivers/net/wireless/ath/regd_common.h
        ETSI1_WORLD = 0x37,
        {ETSI1_WORLD, CTL_ETSI, CTL_ETSI},
        {CTRY_ARUBA, ETSI1_WORLD, "AW"},
        {CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
        {CTRY_BELARUS, ETSI1_WORLD, "BY"},
        {CTRY_BELGIUM, ETSI1_WORLD, "BE"},
        {CTRY_BOSNIA_HERZ, ETSI1_WORLD, "BA"},
        {CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
        {CTRY_CROATIA, ETSI1_WORLD, "HR"},
        {CTRY_CYPRUS, ETSI1_WORLD, "CY"},
        {CTRY_DENMARK, ETSI1_WORLD, "DK"},
        {CTRY_ESTONIA, ETSI1_WORLD, "EE"},
        {CTRY_FINLAND, ETSI1_WORLD, "FI"},
        {CTRY_FRANCE, ETSI1_WORLD, "FR"},
        {CTRY_GERMANY, ETSI1_WORLD, "DE"},
        {CTRY_GREECE, ETSI1_WORLD, "GR"},
        {CTRY_GREENLAND, ETSI1_WORLD, "GL"},
        {CTRY_HAITI, ETSI1_WORLD, "HT"},
        {CTRY_HUNGARY, ETSI1_WORLD, "HU"},
        {CTRY_ICELAND, ETSI1_WORLD, "IS"},
        {CTRY_IRELAND, ETSI1_WORLD, "IE"},
        {CTRY_ITALY, ETSI1_WORLD, "IT"},
        {CTRY_LATVIA, ETSI1_WORLD, "LV"},
        {CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
        {CTRY_LITHUANIA, ETSI1_WORLD, "LT"},
        {CTRY_LUXEMBOURG, ETSI1_WORLD, "LU"},
        {CTRY_MALTA, ETSI1_WORLD, "MT"},
        {CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
        {CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
        {CTRY_NORWAY, ETSI1_WORLD, "NO"},
        {CTRY_POLAND, ETSI1_WORLD, "PL"},
        {CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
        {CTRY_SERBIA_MONTENEGRO, ETSI1_WORLD, "CS"},
        {CTRY_SLOVAKIA, ETSI1_WORLD, "SK"},
        {CTRY_SLOVENIA, ETSI1_WORLD, "SI"},
        {CTRY_SPAIN, ETSI1_WORLD, "ES"},
        {CTRY_SWEDEN, ETSI1_WORLD, "SE"},
        {CTRY_SWITZERLAND, ETSI1_WORLD, "CH"},
        {CTRY_UNITED_KINGDOM, ETSI1_WORLD, "GB"},

The assumption of whether or not all of these alpha2s have the same
regulatory definition on db.txt from wireless-regdb may be wrong
already, not sure, but they all should be pretty close. The design of
programming an Atheros card with 0x37 would end up being to use the
same exact regulatory domain for any of these alpha2s as all of these
alpha2s would be mapped internally in the driver to static regulatory
domain definition. In that case the regulatory domain would never
change, the user would not be informed of the alpha2 at all and its
just used. For Linux the alpha2 regulatory database has been moved to
userspace and although countries (alpah2s) can have the same exact
regulatory domain they do not -- they are just split up.

> So it's just misleading, e.g.
>
>    using first country with regdm 0x37: DK
>
> would probably a better dmesg output.

Agreed, maybe better:

ath: region code found 0x37, fist country in region: DK

That or print all the alpha2s in the region. But as I also had
suggested before we could also check the currently set alpha2 on
cfg80211 by the user and if it happens to match an alpha2 in the
region ask CRDA for that alpha2's regulatory domain.

  Luis

Re: Getting random regulatory domains on boot-up with ath9k

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 12:04 AM, Jeffrey Baker <jwbaker@gmail.com> wrote:
> I am trying to work with a card made with Atheros 9280, but I find
> that I am getting essentially random regulatory domains.  The very
> first time I booted the system, under Linux 2.6.30, I got the country
> code AT.

That just happened to be the first alpha2 in the countries array on
the Atheros driver's country table which mapped 0x37 to an alpha2.
Either way it could have been any of the other alpha2s that map to
0x37 as well.

> Subsequently I got US.

I would need more full logs to analyze this, but it definitely would
not be expected to have come from the ath9k code. The US happened to
be default if you have CONFIG_WIRELESS_OLD_REGULATORY and hence why
this is called OLD, it was the old regulatory implementation. You can
also get US regulatory domain request through an AP country
information element. For atheros wireless cards that are already
programmed to follow a country regulatory domain though (ie: not a
world roaming regulatory domain) the country IE would just enhance
regulatory restrictions further -- it won't enable new channels.

> Then I upgraded to
> compat-wireless-2009-11-06 and now I get AW (Aruba).

Right, AW is now the first country that maps to 0x37, this was changed
on a recent patch.

> dmesg says:
>
> ath: EEPROM regdomain: 0x37
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: AW
> ath: Regpair used: 0x37
> cfg80211: Calling CRDA for country: AW
>
> Now, my understanding is that 0x37 is world roaming.

Actually no, that is not the case. 0x37 maps to ETSI1_WORLD which also
does have the postfix WORLD it does not mean its a world roaming
regulatory domain. The _WORLD postfix just annotates to the developer
that the 2 GHz regulatory SKU is one which world roams, but this is
more of an implementation detail and has nothing to do with real world
roaming regulatory domains. Real Atheros world regulatory domains have
0x60 in them, so this would be 0x61, 0x62, etc. These *are world
roaming* regulatory domain in the sense that static world regulatory
domains have been defined statically in the ath.ko module *and*
typically this also means passive scan is preferred on certain
channels which would otherwise remain disabled in certain countries,
just as beaconing is also disabled (this is called NO-IBSS flag). Now,
cfg80211 then has world roaming enhancements which *lift* the passive
scan and no-ibss (beaconing) flag if a channel has been found though
so you happened to have a world roaming card on 5 GHz you essentially
would be able to enable IBSS or AP mode of operation if a nearby AP
was found through an initial scan.

> The key sentence
> from the docs seems to be this:
>
> "Regulatory pair regulatory domains are mapped to the first
> ISO-3166-alpha2 country."
>
> Does that mean that AW is the first country code in the 0x37
> regulatory pair group?

Now it is, before it was AT.

> The result is this list of channels
>
> 5180 MHz [36] (30.0 dBm) (passive scanning, no IBSS)
> 5200 MHz [40] (30.0 dBm) (passive scanning, no IBSS)
> 5220 MHz [44] (30.0 dBm) (passive scanning, no IBSS)
> 5240 MHz [48] (30.0 dBm) (passive scanning, no IBSS)
> 5260 MHz [52] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5280 MHz [56] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5300 MHz [60] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5320 MHz [64] (30.0 dBm) (passive scanning, no IBSS, radar detection)
> 5500 MHz [100] (disabled)
> 5520 MHz [104] (disabled)
> 5540 MHz [108] (disabled)
> 5560 MHz [112] (disabled)
> 5580 MHz [116] (disabled)
> 5600 MHz [120] (disabled)
> 5620 MHz [124] (disabled)
> 5640 MHz [128] (disabled)
> 5660 MHz [132] (disabled)
> 5680 MHz [136] (disabled)
> 5700 MHz [140] (disabled)
> 5745 MHz [149] (30.0 dBm) (passive scanning, no IBSS)
> 5765 MHz [153] (30.0 dBm) (passive scanning, no IBSS)
> 5785 MHz [157] (30.0 dBm) (passive scanning, no IBSS)
> 5805 MHz [161] (30.0 dBm) (passive scanning, no IBSS)
> 5825 MHz [165] (30.0 dBm) (passive scanning, no IBSS)
>
> ... which in summary prevents me from operating an access point in the
> 5GHz band at all.

Yes, unfortunately when Atheros cards are programmed with a country
code the world roaming enhancement I described above does not apply
which would otherwise have at least enabled AP / IBSS mode of
operation if at least any of your local neighbors did have an AP on
any of the passive-scan/no-ibss channels.

But -- as it so happens "AW" has no entry on db.txt therefore making
0x37 cards stuck with non-world roaming capabilities but since CRDA
does not find any regulatory domain the card essentially *is* stuck
world roaming.

> The perplexing thing is that I was able to use
> channel 36 under kernel.org 2.6.30, so from my perspective that
> software was working better than the current software does,

You can interpret that as however you want, the real fact is just that
AT did have an entry on db.txt which does consist of at least a set of
5 GHz channels which do enable AP mode of operation:

country AT:
        (2402 - 2482 @ 40), (N/A, 20)
        (5170 - 5250 @ 40), (N/A, 20)
        (5250 - 5330 @ 40), (N/A, 20), DFS
        (5490 - 5710 @ 40), (N/A, 27), DFS

> and of
> course leads me to believe that I can use software to change this card
> to FCC regs instead of these frustrating "world" regs which prevent me
> from running an AP.

You have a few twisted statements here but let me order them up and
fix the for you:

  * If you happen to have an Atheros card with a region code and that
region code maps to an alpha2 for which CRDA does not have an entry
for yet your card will remain world roaming if you did not enable
CONFIG_WIRELESS_OLD_REGULATORY as the default under the new regulatory
framework is to world roam. If you did enable
CONFIG_WIRELESS_OLD_REGULATORY though your default would be the static
US rules followed by a request to CRDA for the US regulatory domain.

  * What you have found is a regression introduced by the patch titled
"ath: Updates for regulatory and country codes" and its caused by your
region code not having a mapped regulatory domain on db.txt, as AW has
no entry yet on wireless-regdb.

  * The fix for the regression would be to either use an alpha2 which
does have an entry and put that first in the array *or* (my
preference) to check first the alpha2 set on cfg80211 and see if that
maps to a country allowed by your region code and if so get cfg80211
to request that regulatory domain to CRDA.

  * On modern 802.11 cards you typically can somehow change the
regulatory domain one way or another:

  - Reverse engineering of driver
  - Reprogramming of an EEPROM
  - Modifying open drivers or open regulatory databases and signing
off on these changes

Most Linux distributions today do ship a crda with RSA key support
which protect usage against a non-authored-and-trusted regulatory.bin.
You can obviosly modify and build your own crda and wireless-regdb but
this would be an act an end user does.

So one way or another user intervention is required to alter current
regulatory solutions. For Linux though the best solution *as an end
user* to enable AP mode is not to alter wireless-regdb but instead to
report your issue. In your case you have a non-trivial regression
which does indeed need to be addressed.

> Needless to say, I am perplexed by this behavior. The exact phy is
> "Atheros AR9280 Rev:2"

Thanks for the report, we'll cook up a fix and have you test it.

  Luis

Re: Getting random regulatory domains on boot-up with ath9k

[Luis R. Rodriguez]

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

>  * The fix for the regression would be to either use an alpha2 which
> does have an entry and put that first in the array *or* (my
> preference) to check first the alpha2 set on cfg80211 and see if that
> maps to a country allowed by your region code and if so get cfg80211
> to request that regulatory domain to CRDA.

I just thought of another possible solution for region code stuff --
just make them static world roaming regulatory domains. But to do this
it means we'd enable the world roaming features on cfg80211 and
channels which would typically be disabled would then just become
passive-scan/no-ibss. I'd have to get buy-in through our internal
regulatory guys first. This also seems like a clean solution but it
would mean more static tables define for each major region code we
have and I am not sure how many of those we have.

  Luis

Re: Getting random regulatory domains on boot-up with ath9k

[Luis R. Rodriguez]

On Fri, Nov 6, 2009 at 8:30 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 8:21 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>
>>  * The fix for the regression would be to either use an alpha2 which
>> does have an entry and put that first in the array *or* (my
>> preference) to check first the alpha2 set on cfg80211 and see if that
>> maps to a country allowed by your region code and if so get cfg80211
>> to request that regulatory domain to CRDA.
>
> I just thought of another possible solution for region code stuff --
> just make them static world roaming regulatory domains. But to do this
> it means we'd enable the world roaming features on cfg80211 and
> channels which would typically be disabled would then just become
> passive-scan/no-ibss. I'd have to get buy-in through our internal
> regulatory guys first. This also seems like a clean solution but it
> would mean more static tables define for each major region code we
> have and I am not sure how many of those we have.

Oh and the other solution is to just add AW to db.txt with the same
mappings as any other country in the region code group.

I'll out line this in an e-mail followup, still reviewing what option to take.

  Luis

Re: Getting random regulatory domains on boot-up with ath9k

[Jeffrey Baker]

On Fri, Nov 6, 2009 at 8:21 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 12:04 AM, Jeffrey Baker <jwbaker@gmail.com> wrote:
> So one way or another user intervention is required to alter current
> regulatory solutions. For Linux though the best solution *as an end
> user* to enable AP mode is not to alter wireless-regdb but instead to
> report your issue. In your case you have a non-trivial regression
> which does indeed need to be addressed.

Thanks, your email(s) explained a great number of issues.  I don't
have the expertise to contribute here, so I leave it in your capable
hands.  I would say, however, that from the _user's_ perspective, the
best thing is if a wifi card bought in the USA from a USA retailer
automagically conformed to USA regulations, even if that's an issue to
be taken up with the card manufacturer and not with the driver
authors.

-jwb

Re: Getting random regulatory domains on boot-up with ath9k

[Luis R. Rodriguez]

On Sat, Nov 7, 2009 at 11:02 AM, Jeffrey Baker <jwbaker@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 8:21 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Fri, Nov 6, 2009 at 12:04 AM, Jeffrey Baker <jwbaker@gmail.com> wrote:
>> So one way or another user intervention is required to alter current
>> regulatory solutions. For Linux though the best solution *as an end
>> user* to enable AP mode is not to alter wireless-regdb but instead to
>> report your issue. In your case you have a non-trivial regression
>> which does indeed need to be addressed.
>
> Thanks, your email(s) explained a great number of issues.  I don't
> have the expertise to contribute here, so I leave it in your capable
> hands.  I would say, however, that from the _user's_ perspective, the
> best thing is if a wifi card bought in the USA from a USA retailer
> automagically conformed to USA regulations, even if that's an issue to
> be taken up with the card manufacturer and not with the driver
> authors.

Agreed, however how devices get programmed is a little complex than
just a country code. So one option is to use a direct country code and
that's it, another option is to use a world regulatory domain when you
want to target a few countries and want to have passive scanning
enabled -- typically business laptop SKUs. Then you have the region
codes as your card has which is targetted for a few set of countries
on a region, for example a european region code.

What we have learned from implementing a solution on Linux is this
wasn't easy to manage but that we can make it simpler. At Atheros at
least we might stop using the region codes and just stick to the world
roaming options and direct country codes. The Linux implementation we
have done has helped to re-evaluate current implementations and has
helped us adapt to better more reasonable solutions.

These things just take time to change.

  Luis