regulatory domain settings overwritten

regulatory domain settings overwritten

[Erich Titl]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

Hello

I am trying to set up wireless support on an embedded X86 based device
(PCengines WRAP) using an atheros based CM-9 card manufactured by
Wistron Neweb.

I am using cfg80211 with the internal regulatory domain database. I am
observing the following with dmesg

[  133.324451] cfg80211: Calling CRDA to update world regulatory domain
[  133.344421] cfg80211: World regulatory domain updated:
[  133.346021]     (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[  133.347622]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[  133.348902]     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi,
2000 mBm)
[  133.349842]     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
2000 mBm)
[  133.350455]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[  133.351736]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[  133.353431] cfg80211: Calling CRDA for country: CH
[  133.443881] cfg80211: Regulatory domain changed to country: CH
[  133.444568]     (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[  133.445486]     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[  133.446397]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[  133.447630]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[  133.448863]     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[  141.971982] ath5k 0000:00:0d.0: registered as 'phy0'
[  142.453824] ath: EEPROM regdomain: 0x0
[  142.453881] ath: EEPROM indicates default country code should be used
[  142.453940] ath: doing EEPROM country->regdmn map search
[  142.454009] ath: country maps to regdmn code: 0x3a
[  142.454062] ath: Country alpha2 being used: US
[  142.454109] ath: Regpair used: 0x3a
[  146.738786] phy0: Selected rate control algorithm 'minstrel'
[  146.838666] ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
[  146.839284] ath5k phy0: RF5112B multiband radio found (0x36)
[  146.842202] cfg80211: Calling CRDA for country: US
[  146.936338] cfg80211: Current regulatory domain intersected:
[  146.937470]     (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[  146.938415]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[  146.939290]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 1700 mBm)
[  146.940525]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[  146.941758]     (5490000 KHz - 5600000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[  146.942702]     (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2000 mBm)

Although I specify a country code CH at module loading, it appears that
the athk5 driver is calling cfg80211 with a default country code. Why is
US the default country code and why is it called at all.

Thanks

Erich Titl


[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]

Re: regulatory domain settings overwritten

[Julian Calaby]

Hi Erich,

On Tue, Nov 27, 2012 at 6:50 PM, Erich Titl <erich.titl@think.ch> wrote:
> Hello
>
> I am trying to set up wireless support on an embedded X86 based device
> (PCengines WRAP) using an atheros based CM-9 card manufactured by
> Wistron Neweb.
>
> I am using cfg80211 with the internal regulatory domain database. I am
> observing the following with dmesg
>
> [  133.324451] cfg80211: Calling CRDA to update world regulatory domain
> [  133.344421] cfg80211: World regulatory domain updated:
> [  133.346021]     (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [  133.347622]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
> 2000 mBm)
> [  133.348902]     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi,
> 2000 mBm)
> [  133.349842]     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
> 2000 mBm)
> [  133.350455]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
> 2000 mBm)
> [  133.351736]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
> 2000 mBm)
> [  133.353431] cfg80211: Calling CRDA for country: CH
> [  133.443881] cfg80211: Regulatory domain changed to country: CH
> [  133.444568]     (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [  133.445486]     (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  133.446397]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  133.447630]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  133.448863]     (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
> [  141.971982] ath5k 0000:00:0d.0: registered as 'phy0'
> [  142.453824] ath: EEPROM regdomain: 0x0
> [  142.453881] ath: EEPROM indicates default country code should be used
> [  142.453940] ath: doing EEPROM country->regdmn map search
> [  142.454009] ath: country maps to regdmn code: 0x3a
> [  142.454062] ath: Country alpha2 being used: US
> [  142.454109] ath: Regpair used: 0x3a
> [  146.738786] phy0: Selected rate control algorithm 'minstrel'
> [  146.838666] ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
> [  146.839284] ath5k phy0: RF5112B multiband radio found (0x36)
> [  146.842202] cfg80211: Calling CRDA for country: US
> [  146.936338] cfg80211: Current regulatory domain intersected:
> [  146.937470]     (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [  146.938415]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  146.939290]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 1700 mBm)
> [  146.940525]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  146.941758]     (5490000 KHz - 5600000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  146.942702]     (5650000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>
> Although I specify a country code CH at module loading, it appears that
> the athk5 driver is calling cfg80211 with a default country code. Why is
> US the default country code and why is it called at all.

It's not being completely overridden and it is working as designed.

Firstly, the default country code for all Atheros chips is the USA.
This is most likely because that's where the company is based.

Secondly, your choice, China, is not being overridden. As the card is
saying that it's configured for the USA, and you're saying that it's
in China, the regulatory framework is using the intersection of the US
and Chinese rules to govern it's output, thereby ensuring that the
operation of the card complies with all the information it has about
it's location.

This has been explained in more detail in this thread:

http://www.spinics.net/lists/linux-wireless/msg92420.html

If you want to have the complete set of frequencies as specified by
the Chinese rules, you will need to obtain a card which has been
configured for Chinese operation.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: regulatory domain settings overwritten

[Christian Lamparter]

On Tue, Nov 27, 2012 at 10:55 AM, Julian Calaby <julian.calaby@gmail.com> wrote:
> Hi Erich,
>
> On Tue, Nov 27, 2012 at 6:50 PM, Erich Titl <erich.titl@think.ch> wrote:
> It's not being completely overridden and it is working as designed.
>
> Firstly, the default country code for all Atheros chips is the USA.
> This is most likely because that's where the company is based.
>
> Secondly, your choice, China, is not being overridden. As the card is
> saying that it's configured for the USA, and you're saying that it's
> in China, the regulatory framework is using the intersection of the US
> and Chinese rules to govern it's output, thereby ensuring that the
> operation of the card complies with all the information it has about
> it's location.
>

Just to avoid further confusion. The country code CH maps to Switzerland,
whereas CN is China.So the second part should be about Switzerland.

Regards,
    Chr

Re: regulatory domain settings overwritten

[Julian Calaby]

Hi Christian,

On Tue, Nov 27, 2012 at 9:27 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Tue, Nov 27, 2012 at 10:55 AM, Julian Calaby <julian.calaby@gmail.com> wrote:
>> Hi Erich,
>>
>> On Tue, Nov 27, 2012 at 6:50 PM, Erich Titl <erich.titl@think.ch> wrote:
>> It's not being completely overridden and it is working as designed.
>>
>> Firstly, the default country code for all Atheros chips is the USA.
>> This is most likely because that's where the company is based.
>>
>> Secondly, your choice, China, is not being overridden. As the card is
>> saying that it's configured for the USA, and you're saying that it's
>> in China, the regulatory framework is using the intersection of the US
>> and Chinese rules to govern it's output, thereby ensuring that the
>> operation of the card complies with all the information it has about
>> it's location.
>>
>
> Just to avoid further confusion. The country code CH maps to Switzerland,
> whereas CN is China.So the second part should be about Switzerland.

I should have known that, I have a Chinese card here in Australia.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: regulatory domain settings overwritten

[Erich Titl]

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]

Hi Julian

Thank you for the quick reply and the link

on 27.11.2012 10:55, Julian Calaby wrote:
> Hi Erich,
> 
...


> 
> It's not being completely overridden and it is working as designed.
> 
> Firstly, the default country code for all Atheros chips is the USA.
> This is most likely because that's where the company is based.
> 
> Secondly, your choice, China, is not being overridden. As the card is
> saying that it's configured for the USA, and you're saying that it's
> in China, the regulatory framework is using the intersection of the US
> and Chinese rules to govern it's output, thereby ensuring that the
> operation of the card complies with all the information it has about
> it's location.
> 
> This has been explained in more detail in this thread:
> 
> http://www.spinics.net/lists/linux-wireless/msg92420.html
> 
> If you want to have the complete set of frequencies as specified by
> the Chinese rules, you will need to obtain a card which has been
> configured for Chinese operation.

Actually the country code CH should stand for Switzerland and I am
surprised a default for the US should be hard coded into the driver

        regdmn = ath_regd_get_eepromRD(reg);
        reg->country_code = ath_regd_get_default_country(regdmn);

        if (reg->country_code == CTRY_DEFAULT &&
            regdmn == CTRY_DEFAULT) {
                printk(KERN_DEBUG "ath: EEPROM indicates default "
                       "country code should be used\n");
                reg->country_code = CTRY_UNITED_STATES;
        }

        if (reg->country_code == CTRY_DEFAULT) {
                country = NULL;
        } else {
                printk(KERN_DEBUG "ath: doing EEPROM country->regdmn "
                       "map search\n");
                country = ath_regd_find_country(reg->country_code);
                if (country == NULL) {
                        printk(KERN_DEBUG
                                "ath: no valid country maps found for "
                                "country code: 0x%0x\n",
                                reg->country_code);
                        return -EINVAL;
                } else {
                        regdmn = country->regDmnEnum;
                        printk(KERN_DEBUG "ath: country maps to "
                               "regdmn code: 0x%0x\n",
                               regdmn);
                }
        }

Anyway, I am located in Switzerland and I saw similar threads from a few
people on the net. Today's mobile society demands that equipment can be
reconfigured freely to accommodate the local regulatory limits. This can
be achieved at will with an open card, which just gets crippled by the
hard coded limits set here.

So under the worst thinkable circumstances this code won't work for my
environment as, for example, the intersection of the world regdomain and
the US regdomain would AFAIK cut away channels 12 and 13, which are
perfectly legal at my domicile and are used by some AP's.

I could (and will probably have to) recompile the driver using another
regdomain file, but this is not really satisfactory either. IMHO the
regdomain should be chosen as seen fit and not imposed by hard coded
limits in the driver.

Thanks

Erich


[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]

Re: regulatory domain settings overwritten

[Julian Calaby]

Hi Erich,

On Tue, Nov 27, 2012 at 11:53 PM, Erich Titl <erich.titl@think.ch> wrote:
> Hi Julian
>
> Thank you for the quick reply and the link
>
> on 27.11.2012 10:55, Julian Calaby wrote:
>> Hi Erich,
>>
> ...
>
>
>>
>> It's not being completely overridden and it is working as designed.
>>
>> Firstly, the default country code for all Atheros chips is the USA.
>> This is most likely because that's where the company is based.
>>
>> Secondly, your choice, China, is not being overridden. As the card is
>> saying that it's configured for the USA, and you're saying that it's
>> in China, the regulatory framework is using the intersection of the US
>> and Chinese rules to govern it's output, thereby ensuring that the
>> operation of the card complies with all the information it has about
>> it's location.
>>
>> This has been explained in more detail in this thread:
>>
>> http://www.spinics.net/lists/linux-wireless/msg92420.html
>>
>> If you want to have the complete set of frequencies as specified by
>> the Chinese rules, you will need to obtain a card which has been
>> configured for Chinese operation.
>
> Actually the country code CH should stand for Switzerland and I am
> surprised a default for the US should be hard coded into the driver

Sorry about that, the last time I explained this, it was for a Chinese
resident, and I got the codes mixed up.

This "default" is part of the specification of how the hardware
operates. If it hasn't been configured otherwise, it defaults to US
operation. I'm sure that the Windows driver behaves in exactly the
same way - this isn't some feature of the Linux driver, it's how the
card is supposed to work.

> Anyway, I am located in Switzerland and I saw similar threads from a few
> people on the net. Today's mobile society demands that equipment can be
> reconfigured freely to accommodate the local regulatory limits. This can
> be achieved at will with an open card, which just gets crippled by the
> hard coded limits set here.

Laws say otherwise. Each country has a different set of regulations
for how they expect a WiFi card to operate. To make a card that is
fully compliant with all these sets of regulations would require it to
be tested against in a way which can prove that it complies with all
those regulations. In general, as I understand it, cards are usually
built for a particular market, and tested that they comply with that
market's regulations, usually then ignoring any other country's
regulations. Cheaper manufacturers may just use a reference design,
which is probably built to comply with US regulations, and then just
use the defaults.

The card is not "open", it's using the default configuration. The
default configuration is that it's configured for US operation.

> So under the worst thinkable circumstances this code won't work for my
> environment as, for example, the intersection of the world regdomain and
> the US regdomain would AFAIK cut away channels 12 and 13, which are
> perfectly legal at my domicile and are used by some AP's.

If you're using access points on channels 12 and 13, then yeah, using
a card that is configured for US operation won't work for you.

> I could (and will probably have to) recompile the driver using another
> regdomain file, but this is not really satisfactory either. IMHO the
> regdomain should be chosen as seen fit and not imposed by hard coded
> limits in the driver.

You could recompile the driver to use the Swiss country code as the
default, however then you'd be using the card in a way which is
outside of it's specification.

It is possible that your particular card cannot work predictably
enough on channels 12 and 13 to comply with the Swiss regulations
which is why it's been left at the default configuration. It's also
possible that it can comply with the regulations perfectly, but has
never been tested and had the EEPROM set to indicate that it can
comply with them.

The simple fact of the matter is that the card is set to use the
default configuration. The default configuration is for US operation,
simple as that. This isn't short sighted Linux developers assuming
that everyone is in the US, this is a design decision by the company
that produced the card to give it a sensible default it can comply
with.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: regulatory domain settings overwritten

[Erich Titl]

[-- Attachment #1: Type: text/plain, Size: 4816 bytes --]

Hi Julian

on 27.11.2012 23:55, Julian Calaby wrote:
> Hi Erich,
> 
> On Tue, Nov 27, 2012 at 11:53 PM, Erich Titl <erich.titl@think.ch> wrote:
>> Hi Julian
>>
...

> 
> Sorry about that, the last time I explained this, it was for a Chinese
> resident, and I got the codes mixed up.
> 
> This "default" is part of the specification of how the hardware
> operates. If it hasn't been configured otherwise, it defaults to US
> operation. I'm sure that the Windows driver behaves in exactly the
> same way - this isn't some feature of the Linux driver, it's how the
> card is supposed to work.

I understand that well, but how is the driver supposed to know what the
default is?
In my case I got a card imported by a local OEM which gets them from
Taiwan directly.

..

> 
> Laws say otherwise. Each country has a different set of regulations
> for how they expect a WiFi card to operate. To make a card that is
> fully compliant with all these sets of regulations would require it to
> be tested against in a way which can prove that it complies with all
> those regulations. In general, as I understand it, cards are usually
> built for a particular market, and tested that they comply with that
> market's regulations, usually then ignoring any other country's
> regulations. Cheaper manufacturers may just use a reference design,
> which is probably built to comply with US regulations, and then just
> use the defaults.

Yes, but in my case the card says 'OK, use the default' and then the
default happens to be hard coded as US in he driver. In my book this is
different from a card saying, 'OH, I believe I am a US card, so please
behave US conformant'.

> 
> The card is not "open", it's using the default configuration. The
> default configuration is that it's configured for US operation.

No, it is not, the card pretends nothing, the driver does.

> 
>> So under the worst thinkable circumstances this code won't work for my
>> environment as, for example, the intersection of the world regdomain and
>> the US regdomain would AFAIK cut away channels 12 and 13, which are
>> perfectly legal at my domicile and are used by some AP's.
> 
> If you're using access points on channels 12 and 13, then yeah, using
> a card that is configured for US operation won't work for you.

Indeed and that is what I am ranting about.

> 
>> I could (and will probably have to) recompile the driver using another
>> regdomain file, but this is not really satisfactory either. IMHO the
>> regdomain should be chosen as seen fit and not imposed by hard coded
>> limits in the driver.
> 
> You could recompile the driver to use the Swiss country code as the
> default, however then you'd be using the card in a way which is
> outside of it's specification.
> 
> It is possible that your particular card cannot work predictably
> enough on channels 12 and 13 to comply with the Swiss regulations
> which is why it's been left at the default configuration. 

The driver itself cannot be made responsible for the malfunction of the
card. If the card was restricted in any way, the manufacturer can and
IMHO _must_ use the EEPROM value to restrict it's use. This was _not_
done here, as the manufacturer cannot know what the driver author thinks
is the default.

It's also
> possible that it can comply with the regulations perfectly, but has
> never been tested and had the EEPROM set to indicate that it can
> comply with them.

Yes of course, it could be that way, but my past experience in IT leads
me to believe that manufacturers shy away from market specific hardware
design. This is why the CM9 does not specify a country code, but a
'default' setting.

> 
> The simple fact of the matter is that the card is set to use the
> default configuration. The default configuration is for US operation,
> simple as that. This isn't short sighted Linux developers assuming
> that everyone is in the US, this is a design decision by the company
> that produced the card to give it a sensible default it can comply
> with.

Oh, I don't pretend the developers are short sighted, just that the
person writing the code sat possibly somewhere in the US midwest and his
perception of the world might be restricted to the county border, been
there, seen it. The driver IMHO should be written in a way that it can
meet the local regulatory law, and the default should not be US imposed
by the driver.

Nevertheless, I have patched the driver to do exactly that, if there is
no regdom specified in the EEPROM then use the one specified in the
cfg80211 options. The behaviour of the driver can be controlled right
now by a compile time flag, I might even turn that into a flag passed as
an option at load time.

cheers

Erich


[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]

Re: regulatory domain settings overwritten

[Julian Calaby]

Hi Erich,

On Wed, Nov 28, 2012 at 6:11 PM, Erich Titl <erich.titl@think.ch> wrote:
> Hi Julian
>
> on 27.11.2012 23:55, Julian Calaby wrote:
>> Hi Erich,
>>
>> On Tue, Nov 27, 2012 at 11:53 PM, Erich Titl <erich.titl@think.ch> wrote:
>>> Hi Julian
>>>
> ...
>
>>
>> Sorry about that, the last time I explained this, it was for a Chinese
>> resident, and I got the codes mixed up.
>>
>> This "default" is part of the specification of how the hardware
>> operates. If it hasn't been configured otherwise, it defaults to US
>> operation. I'm sure that the Windows driver behaves in exactly the
>> same way - this isn't some feature of the Linux driver, it's how the
>> card is supposed to work.
>
> I understand that well, but how is the driver supposed to know what the
> default is?

Because the specification of the EEPROM format says that it's US.

> In my case I got a card imported by a local OEM which gets them from
> Taiwan directly.

So it's unlikely to have been tested to comply with Swiss regulations,
therefore the EEPROM is set to use the defaults.

>> Laws say otherwise. Each country has a different set of regulations
>> for how they expect a WiFi card to operate. To make a card that is
>> fully compliant with all these sets of regulations would require it to
>> be tested against in a way which can prove that it complies with all
>> those regulations. In general, as I understand it, cards are usually
>> built for a particular market, and tested that they comply with that
>> market's regulations, usually then ignoring any other country's
>> regulations. Cheaper manufacturers may just use a reference design,
>> which is probably built to comply with US regulations, and then just
>> use the defaults.
>
> Yes, but in my case the card says 'OK, use the default' and then the
> default happens to be hard coded as US in he driver. In my book this is
> different from a card saying, 'OH, I believe I am a US card, so please
> behave US conformant'.

It's no different. In this case, the card saying "I don't know what I
am" is specified to be equivalent to it saying "I'm a US card".

>> The card is not "open", it's using the default configuration. The
>> default configuration is that it's configured for US operation.
>
> No, it is not, the card pretends nothing, the driver does.

The card says to use the default, the default is US.

>>> I could (and will probably have to) recompile the driver using another
>>> regdomain file, but this is not really satisfactory either. IMHO the
>>> regdomain should be chosen as seen fit and not imposed by hard coded
>>> limits in the driver.
>>
>> You could recompile the driver to use the Swiss country code as the
>> default, however then you'd be using the card in a way which is
>> outside of it's specification.
>>
>> It is possible that your particular card cannot work predictably
>> enough on channels 12 and 13 to comply with the Swiss regulations
>> which is why it's been left at the default configuration.
>
> The driver itself cannot be made responsible for the malfunction of the
> card. If the card was restricted in any way, the manufacturer can and
> IMHO _must_ use the EEPROM value to restrict it's use. This was _not_
> done here, as the manufacturer cannot know what the driver author thinks
> is the default.

We are required by law to do our best to ensure that the card complies
with whatever regulations are in force, wherever we are in the world.
The simplest way to do this is to ensure that we comply with every
piece of information we have. If the card says that we're in the US
and the user says we're in Switzerland, then we restrict it to the
minimum of both sets of regulatory rules so that we can be sure that
the card is, to the best of our knowledge, complying with the rules.

On the other hand, some cheaper manufacturers use reference designs
and keep things default to cut costs. Therefore the manufacturer of
the chip specifies a default which is hard coded in the driver.

> It's also
>> possible that it can comply with the regulations perfectly, but has
>> never been tested and had the EEPROM set to indicate that it can
>> comply with them.
>
> Yes of course, it could be that way, but my past experience in IT leads
> me to believe that manufacturers shy away from market specific hardware
> design. This is why the CM9 does not specify a country code, but a
> 'default' setting.

CM9 is getting rather old now and there are now facilities in the
kernel to detect which region we're in from the information the phone
would get from a cell phone tower, I don't know for sure, but I'd
expect that this will be used in the future to ensure that we comply
where possible.

Also, CM9 is a custom ROM and may simply not have bothered where
manufacturer ROMs might have.

>> The simple fact of the matter is that the card is set to use the
>> default configuration. The default configuration is for US operation,
>> simple as that. This isn't short sighted Linux developers assuming
>> that everyone is in the US, this is a design decision by the company
>> that produced the card to give it a sensible default it can comply
>> with.
>
> Oh, I don't pretend the developers are short sighted, just that the
> person writing the code sat possibly somewhere in the US midwest and his
> perception of the world might be restricted to the county border, been
> there, seen it. The driver IMHO should be written in a way that it can
> meet the local regulatory law, and the default should not be US imposed
> by the driver.

The default is not imposed by some midwest driver author, the default
is imposed by the manufacturer of the chip as a default when the
regulatory information is incorrect or unavailable.

> Nevertheless, I have patched the driver to do exactly that, if there is
> no regdom specified in the EEPROM then use the one specified in the
> cfg80211 options. The behaviour of the driver can be controlled right
> now by a compile time flag, I might even turn that into a flag passed as
> an option at load time.

And this will be trying to use the card against it's specifications
and will probably be rejected because of that.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: regulatory domain settings overwritten

[Erich Titl]

[-- Attachment #1: Type: text/plain, Size: 4384 bytes --]

Hi Julian

on 28.11.2012 09:18, Julian Calaby wrote:
> Hi Erich,
> 
> On Wed, Nov 28, 2012 at 6:11 PM, Erich Titl <erich.titl@think.ch> wrote:
>> Hi Julian
>>
...

> 
> So it's unlikely to have been tested to comply with Swiss regulations,
> therefore the EEPROM is set to use the defaults.

It is pretty unlikely to have been tested against US regulations either.

> 
....
> 
> It's no different. In this case, the card saying "I don't know what I
> am" is specified to be equivalent to it saying "I'm a US card".

You don't really want to say that anyone who does not know better is a
US citizen ;-)

> 
>>> The card is not "open", it's using the default configuration. The
>>> default configuration is that it's configured for US operation.
>>
>> No, it is not, the card pretends nothing, the driver does.
> 
> The card says to use the default, the default is US.

And this IMHO is just plain wrong. US is not the navel of the world, if
there is one at all.

> ..
> 
> We are required by law to do our best to ensure that the card complies
> with whatever regulations are in force, wherever we are in the world.
> The simplest way to do this is to ensure that we comply with every
> piece of information we have. If the card says that we're in the US
> and the user says we're in Switzerland, then we restrict it to the
> minimum of both sets of regulatory rules so that we can be sure that
> the card is, to the best of our knowledge, complying with the rules.

I know now, by inspecting the code that this is exactly what happens. I
agree with you that if the card says 'I am a US branded card' this is
the right thing to do.
I disagree though that for a card that says 'Never mind, just specify
your location' US is the right choice.

I believe instead of using

reg->country_code = CTRY_UNITED_STATES;

should be something like

reg->country_code = CTRY_NEUTRAL;

> 
> On the other hand, some cheaper manufacturers use reference designs
> and keep things default to cut costs. Therefore the manufacturer of
> the chip specifies a default which is hard coded in the driver.

Yes, but the hard coded regdomain US is doubtful.

> 
>> It's also
>>> possible that it can comply with the regulations perfectly, but has
>>> never been tested and had the EEPROM set to indicate that it can
>>> comply with them.
>>
>> Yes of course, it could be that way, but my past experience in IT leads
>> me to believe that manufacturers shy away from market specific hardware
>> design. This is why the CM9 does not specify a country code, but a
>> 'default' setting.
> 
> CM9 is getting rather old now and there are now facilities in the
> kernel to detect which region we're in from the information the phone
> would get from a cell phone tower, I don't know for sure, but I'd
> expect that this will be used in the future to ensure that we comply
> where possible.

For phones that may be a good thing, though I would not want my phone
somehow to sample my position without asking me. For things that don't
depend on the public telephone system this method is unsafe at best.

> 
...
> 
> The default is not imposed by some midwest driver author, the default
> is imposed by the manufacturer of the chip as a default when the
> regulatory information is incorrect or unavailable.

Right, in EEPROM this is unavailable, but now the driver translates this
to a hardly comprehensible region which apparently is somehow restricted.

> 
> And this will be trying to use the card against it's specifications
> and will probably be rejected because of that.

That my or may not be the case. Anyway, cfg80211 can set the card to the
world domain and can also set it to country code CH. Unfortunately the
driver is overlaying this.

I tried several CTRY settings, as I don't want to mess up unnecessarily.
CRTY_DEFAUT just makes it cough.

What is a usable CTRY code to cover the broadest possible country range,
which can then be controlled through the correct country code. I could
use something like CTRY_AUSTRALIA but then that would be as bad as
CRTY_UNITED_STATES as it is not a neutral setting.

Is there a neutral CTRY value which does not mess up the worldwide settings?

And yes, we do not need to agree on the universalness of
CTRY_UNITED_STATES ;-)

Thanks

Erich



[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]

Re: regulatory domain settings overwritten

[Julian Calaby]

Hi Erich,

The rule for dealing with invalid or default regulatory data in
Atheros cards is to use the US region.

This is specified in Atheros' documentation for the EEPROM format.

The code is working as designed, to the specification for the chipset
and as close as we can be certain to compliance with all applicable
laws.

The fact that your cards are using the defaults indicates that
somewhere between the factory and your hands someone isn't testing the
cards to verify them against a set of regulatory rules.

As far as I'm concerned, this matter is closed. The issue has been
explained to you repeatedly and in detail. Arguing with me won't
change the specification, won't change the code, and won't change the
fact that the device and driver are working exactly as they are
supposed to.

On Thu, Nov 29, 2012 at 1:43 AM, Erich Titl <erich.titl@think.ch> wrote:
> Hi Julian
>
> on 28.11.2012 09:18, Julian Calaby wrote:
>> Hi Erich,
>>
>> On Wed, Nov 28, 2012 at 6:11 PM, Erich Titl <erich.titl@think.ch> wrote:
>>> Hi Julian
>>>
> ...
>
>>
>> So it's unlikely to have been tested to comply with Swiss regulations,
>> therefore the EEPROM is set to use the defaults.
>
> It is pretty unlikely to have been tested against US regulations either.

Yes, which indicates to me that someone between the factory and you
hasn't been checking that the cards comply before selling them on.

>> It's no different. In this case, the card saying "I don't know what I
>> am" is specified to be equivalent to it saying "I'm a US card".
>
> You don't really want to say that anyone who does not know better is a
> US citizen ;-)

This has nothing to do with nationality.

>>>> The card is not "open", it's using the default configuration. The
>>>> default configuration is that it's configured for US operation.
>>>
>>> No, it is not, the card pretends nothing, the driver does.
>>
>> The card says to use the default, the default is US.
>
> And this IMHO is just plain wrong. US is not the navel of the world, if
> there is one at all.

Again, this has nothing to do with nationality. Would you complain as
much if the default was England? Spain? Afganistan?

>> We are required by law to do our best to ensure that the card complies
>> with whatever regulations are in force, wherever we are in the world.
>> The simplest way to do this is to ensure that we comply with every
>> piece of information we have. If the card says that we're in the US
>> and the user says we're in Switzerland, then we restrict it to the
>> minimum of both sets of regulatory rules so that we can be sure that
>> the card is, to the best of our knowledge, complying with the rules.
>
> I know now, by inspecting the code that this is exactly what happens. I
> agree with you that if the card says 'I am a US branded card' this is
> the right thing to do.
> I disagree though that for a card that says 'Never mind, just specify
> your location' US is the right choice.
>
> I believe instead of using
>
> reg->country_code = CTRY_UNITED_STATES;
>
> should be something like
>
> reg->country_code = CTRY_NEUTRAL;

The "neutral" regulatory rules are the "world" regulatory rules which
comply with every set of regulations out there. It is even more
restricted than the US regulatory rules.

>> On the other hand, some cheaper manufacturers use reference designs
>> and keep things default to cut costs. Therefore the manufacturer of
>> the chip specifies a default which is hard coded in the driver.
>
> Yes, but the hard coded regdomain US is doubtful.

It's specified by Atheros, the company that makes the chips, as the
domain to use when there is none set.

>>> It's also
>>>> possible that it can comply with the regulations perfectly, but has
>>>> never been tested and had the EEPROM set to indicate that it can
>>>> comply with them.
>>>
>>> Yes of course, it could be that way, but my past experience in IT leads
>>> me to believe that manufacturers shy away from market specific hardware
>>> design. This is why the CM9 does not specify a country code, but a
>>> 'default' setting.
>>
>> CM9 is getting rather old now and there are now facilities in the
>> kernel to detect which region we're in from the information the phone
>> would get from a cell phone tower, I don't know for sure, but I'd
>> expect that this will be used in the future to ensure that we comply
>> where possible.
>
> For phones that may be a good thing, though I would not want my phone
> somehow to sample my position without asking me. For things that don't
> depend on the public telephone system this method is unsafe at best.

Personally, if I were designing code that could interact with laws in
a way that could potentially get users of that code in legal trouble,
I'd take every precaution to ensure that this didn't happen. This code
is designed with that in mind.

>> The default is not imposed by some midwest driver author, the default
>> is imposed by the manufacturer of the chip as a default when the
>> regulatory information is incorrect or unavailable.
>
> Right, in EEPROM this is unavailable, but now the driver translates this
> to a hardly comprehensible region which apparently is somehow restricted.

Yes, by following the specification specified by the manufacturer of
the chipset.

>> And this will be trying to use the card against it's specifications
>> and will probably be rejected because of that.
>
> That my or may not be the case. Anyway, cfg80211 can set the card to the
> world domain and can also set it to country code CH. Unfortunately the
> driver is overlaying this.

As explained previously, you are saying that you're in Switzerland, we
have information that indicates that we may be in the USA so we use a
set of rules that comply with both.

> I tried several CTRY settings, as I don't want to mess up unnecessarily.
> CRTY_DEFAUT just makes it cough.
>
> What is a usable CTRY code to cover the broadest possible country range,
> which can then be controlled through the correct country code. I could
> use something like CTRY_AUSTRALIA but then that would be as bad as
> CRTY_UNITED_STATES as it is not a neutral setting.
>
> Is there a neutral CTRY value which does not mess up the worldwide settings?

You could use the world regulatory domain, but it's even more
restricted as it complies with _every_ set of rules.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: regulatory domain settings overwritten

[Erich Titl]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

Hi Julian

on 28.11.2012 23:01, Julian Calaby wrote:
> Hi Erich,
> 
> The rule for dealing with invalid or default regulatory data in
> Atheros cards is to use the US region.
> 
> This is specified in Atheros' documentation for the EEPROM format.
> 
> The code is working as designed, to the specification for the chipset
> and as close as we can be certain to compliance with all applicable
> laws.
> 
> The fact that your cards are using the defaults indicates that
> somewhere between the factory and your hands someone isn't testing the
> cards to verify them against a set of regulatory rules.
> 
> As far as I'm concerned, this matter is closed. The issue has been
> explained to you repeatedly and in detail. Arguing with me won't
> change the specification, won't change the code, and won't change the
> fact that the device and driver are working exactly as they are
> supposed to.

Of course it is and I don't argue that

Thanks

Erich




[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]

Re: regulatory domain settings overwritten

[Bob Copeland]

On Wed, Nov 28, 2012 at 08:11:17AM +0100, Erich Titl wrote:
> Oh, I don't pretend the developers are short sighted, just that the
> person writing the code sat possibly somewhere in the US midwest and his
> perception of the world might be restricted to the county border, been
> there, seen it. The driver IMHO should be written in a way that it can
> meet the local regulatory law, and the default should not be US imposed
> by the driver.

For what it's worth, the ath5k author lives in Greece :P

(Well, actually this code came from ath9k which is pretty much from the
horse's mouth...)

-- 
Bob Copeland %% www.bobcopeland.com

Re: regulatory domain settings overwritten

[Erich Titl]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hi Bob

on 28.11.2012 15:31, Bob Copeland wrote:
> On Wed, Nov 28, 2012 at 08:11:17AM +0100, Erich Titl wrote:
>> Oh, I don't pretend the developers are short sighted, just that the
>> person writing the code sat possibly somewhere in the US midwest and his
>> perception of the world might be restricted to the county border, been
>> there, seen it. The driver IMHO should be written in a way that it can
>> meet the local regulatory law, and the default should not be US imposed
>> by the driver.
> 
> For what it's worth, the ath5k author lives in Greece :P

Thanks for the info, well Greece has some more things to do right now
than to worry about a wireless driver :P

> 
> (Well, actually this code came from ath9k which is pretty much from the
> horse's mouth...)

Yes, it is pretty universal across the ath range. Do you know how other
implementations handle this situation, or is it just the Atheros (or
CM9) EEPROM that is undecided?

Thanks

Erich



[-- Attachment #2: S/MIME Kryptografische Unterschrift --]
[-- Type: application/pkcs7-signature, Size: 1877 bytes --]