regdomain

regdomain

[James]

I am in Canada so is 0x10 right?
Is there a tool I can use to read the EEPROM?

ath: EEPROM regdomain: 0x10
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: CO
ath: Regpair used: 0x10

Re: regdomain

[Luis R. Rodriguez]

On Mon, Mar 28, 2011 at 10:09 PM, James <bjlockie@lockie.ca> wrote:
> I am in Canada so is 0x10 right?

Nope, CA has these two mappings:

        {CTRY_CANADA, FCC3_FCCA, "CA"},
        {CTRY_CANADA2, FCC6_FCCA, "CA"},


> Is there a tool I can use to read the EEPROM?

The ath driver spits it out for you:

> ath: EEPROM regdomain: 0x10

That's it.

> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: CO
> ath: Regpair used: 0x10

Sorry for the confusion, 0x10 is a value that is used for a few
countries, specifically, 0x10 maps to a name "FCC1_FCCA" and all these
countries map to 0x10:

mcgrof@tux ~/wireless-testing (git::master)$ grep FCC1_FCCA
drivers/net/wireless/ath/regd_common.h
	FCC1_FCCA = 0x10,
	{FCC1_FCCA, CTL_FCC, CTL_FCC},
	{CTRY_DEFAULT, FCC1_FCCA, "CO"},
	{CTRY_COLOMBIA, FCC1_FCCA, "CO"},
	{CTRY_DOMINICAN_REPUBLIC, FCC1_FCCA, "DO"},
	{CTRY_GUAM, FCC1_FCCA, "GU"},
	{CTRY_GUATEMALA, FCC1_FCCA, "GT"},
	{CTRY_MEXICO, FCC1_FCCA, "MX"},
	{CTRY_PANAMA, FCC1_FCCA, "PA"},
	{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},

In reality that print, " ath: Country alpha2 being used: CO" should
say something like this:

 ath: Country alpha2 which can be used: CO, DO, GU, GT, MX, PA, PR

But the Canada regulatory domain is indeed not being used. The differences:

country CA:
        (2402 - 2472 @ 40), (3, 27)
        (5170 - 5250 @ 40), (3, 17)
        (5250 - 5330 @ 40), (3, 20), DFS
        (5490 - 5710 @ 40), (3, 20), DFS
        (5735 - 5835 @ 40), (3, 30)

country US:
        (2402 - 2472 @ 40), (3, 27)
        (5170 - 5250 @ 40), (3, 17)
        (5250 - 5330 @ 40), (3, 20), DFS
        (5490 - 5600 @ 40), (3, 20), DFS
        (5650 - 5710 @ 40), (3, 20), DFS
        (5735 - 5835 @ 40), (3, 30)

In the US 5600-5650 was removed due to this commit:

Author: Luis R. Rodriguez <lrodriguez@atheros.com>
Date:   Thu Nov 5 12:46:25 2009 -0500

    wireless-regdb: update US rules for 5600 MHz - 5650 MHz

    The FCC is trying to assist airports that use Terminal Doppler
    Weather Radar (TDWR) systems in avoiding interference with
    some outdoor wireless systems operating in the 5.4 GHz
    (5470 MHz - 5725 MHz) band. One of the things they have decided
    on is to disallow operation on the 5600 MHz - 5650 MHz frequency
    range inclusive. What this means in practice is 5 GHz 802.11
    devices programmed to operate in the US will have these
    channels now disabled:

     * 5600 MHz [120] (disabled)
     * 5620 MHz [124] (disabled)
     * 5640 MHz [128] (disabled)

    Channel on 5660 MHz (132) will be left enabled as the channel
    bandwidth is 20 MHz for legacy 802.11 networks but note that
    HT40- will be disallowed for that channel. The HT40+ and HT40-
    allowed channel map obviously changes. This is computed
    dynamically on cfg80211 based on your allowed channel list.
    For a US based device this is what you will get now
    (excerpt from on /sys/kernel/debug/ieee80211/phy0):

     .. etc ..
    5540 HT40 -+
    5560 HT40 -+
    5580 HT40 -
    5600 Disabled
    5620 Disabled
    5640 Disabled
    5660 HT40  +
    5680 HT40 -+
     .. etc ..

    The details on which this patch is based on is documented on
    the FCC Knowledge based Publication Number: 443999 [1]

    [1] https://fjallfoss.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?switch=P&id=41732

    Cc: Michael Green <Michael.Green@atheros.com>
    Cc: Senthil Balasubramanian <senthilkumar@atheros.com>
    Cc: David Quan <David.Quan@atheros.com>
    Cc: Vivek Natarajan <Vivek.Natarajan@atheros.com>
    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

So that's all you are missing out on, and I would not be surprised if
CA passed similar rules for their own reguatory domain, but the
important thing is your card remains compliant with CA. Hope this
clarifies things.

  Luis

Re: regdomain

[James]

On 03/29/11 14:06, Luis R. Rodriguez wrote:
> On Mon, Mar 28, 2011 at 10:09 PM, James <bjlockie@lockie.ca> wrote:
>> I am in Canada so is 0x10 right?
> Nope
Well, I bought the card used, I just assume he bought it retail.
> But the Canada regulatory domain is indeed not being used. The differences:
>
> country CA:
>         (2402 - 2472 @ 40), (3, 27)
>         (5170 - 5250 @ 40), (3, 17)
>         (5250 - 5330 @ 40), (3, 20), DFS
>         (5490 - 5710 @ 40), (3, 20), DFS
>         (5735 - 5835 @ 40), (3, 30)
>
> country US:
>         (2402 - 2472 @ 40), (3, 27)
>         (5170 - 5250 @ 40), (3, 17)
>         (5250 - 5330 @ 40), (3, 20), DFS
>         (5490 - 5600 @ 40), (3, 20), DFS
>         (5650 - 5710 @ 40), (3, 20), DFS
>         (5735 - 5835 @ 40), (3, 30)

It is using CO, not US.

I am trying to debug this card since it works on kernel-2.6.36.2 but not
any later one.

Re: regdomain

[Luis R. Rodriguez]

On Tue, Mar 29, 2011 at 1:23 PM, James <bjlockie@lockie.ca> wrote:
> On 03/29/11 14:06, Luis R. Rodriguez wrote:
>> country CA:
>>         (2402 - 2472 @ 40), (3, 27)
>>         (5170 - 5250 @ 40), (3, 17)
>>         (5250 - 5330 @ 40), (3, 20), DFS
>>         (5490 - 5710 @ 40), (3, 20), DFS
>>         (5735 - 5835 @ 40), (3, 30)

> It is using CO, not US.

Ah yes, sorry so you use this then:

country CO:
        (2402 - 2472 @ 40), (3, 27)
        (5170 - 5250 @ 20), (3, 17)
        (5250 - 5330 @ 20), (3, 23), DFS
        (5735 - 5835 @ 20), (3, 30)

So you loose out on 5490 - 5710 range given that the card has been
programmed for that regulatory domain. You cannot override this, this
built into the EEPROM and due to regulatory restrictions this cannot
be changed or left to the user to say where they are. On Linux we
however do enable the user to restrict the device further, but never
enable more than what the card was calibrated / designed for.

> I am trying to debug this card since it works on kernel-2.6.36.2 but not
> any later one.

Define "works" and "not works". You can bisect if you know two kernel
releases that you can use a bisection points, a good one and a bad
one. Please review how to do that.

  Luis

Re: regdomain

[James]

On 03/29/11 16:48, Luis R. Rodriguez wrote:

>> I am trying to debug this card since it works on kernel-2.6.36.2 but not
>> any later one.
> Define "works" and "not works". You can bisect if you know two kernel
> releases that you can use a bisection points, a good one and a bad
> one. Please review how to do that.
>
>   Luis
It misses a lot of SSIDs during a scan (different ones each time) and it
won't associate with an open AP.
I suspected a hardware problem but it works fine on kernel-2.6.36.2.
I'lll google how to bisect.