ath9k bug in country domain handling

ath9k bug in country domain handling

[Erwin Van de Velde]

Dear all,

I have 802.11n cards with an atheros chipset with no default country domain. 
Upon initialization, crda is set to US domain, after which I try to change it 
to another domain, the driver only accepts further limitations: i.e. if a 
channel is allowed in the US but not in Belgium, it is disabled, but the other 
way round: if a channel is not allowed in the US, but is allowed in Belgium it 
is not enabled. 

Regards,
Erwin

Re: ath9k bug in country domain handling

[Schrober]

On Wednesday 13 June 2012 13:17:49 Erwin Van de Velde wrote:
> Dear all,
> 
> I have 802.11n cards with an atheros chipset with no default country domain.
> Upon initialization, crda is set to US domain, after which I try to change
> it to another domain, the driver only accepts further limitations: i.e. if
> a channel is allowed in the US but not in Belgium, it is disabled, but the
> other way round: if a channel is not allowed in the US, but is allowed in
> Belgium it is not enabled.

That is not a bug, but something we call restriction.

Regards,
Franz

Re: ath9k bug in country domain handling

[Erwin Van de Velde]

On Friday 15 June 2012 21:00:23 Schrober wrote:
> On Wednesday 13 June 2012 13:17:49 Erwin Van de Velde wrote:
> > Dear all,
> > 
> > I have 802.11n cards with an atheros chipset with no default country
> > domain. Upon initialization, crda is set to US domain, after which I try
> > to change it to another domain, the driver only accepts further
> > limitations: i.e. if a channel is allowed in the US but not in Belgium,
> > it is disabled, but the other way round: if a channel is not allowed in
> > the US, but is allowed in Belgium it is not enabled.
> 
> That is not a bug, but something we call restriction.
> 

What? It definitely is a bug, since it restricts something that should not be 
restricted in Belgium. I am talking about channels you are allowed to use in 
Belgium, which get disabled by the driver. How can this not be a bug?
If I call crda for the BE domain, I expect to get _all_ channels that are 
allowed in Belgium, not just some.

Regards,
Erwin

Re: ath9k bug in country domain handling

[Julian Calaby]

Hi Erwin,

On Sat, Jun 16, 2012 at 7:51 AM, Erwin Van de Velde
<erwin.vandevelde@gmail.com> wrote:
> On Friday 15 June 2012 21:00:23 Schrober wrote:
>> On Wednesday 13 June 2012 13:17:49 Erwin Van de Velde wrote:
>> > Dear all,
>> >
>> > I have 802.11n cards with an atheros chipset with no default country
>> > domain. Upon initialization, crda is set to US domain, after which I try
>> > to change it to another domain, the driver only accepts further
>> > limitations: i.e. if a channel is allowed in the US but not in Belgium,
>> > it is disabled, but the other way round: if a channel is not allowed in
>> > the US, but is allowed in Belgium it is not enabled.
>>
>> That is not a bug, but something we call restriction.
>>
>
> What? It definitely is a bug, since it restricts something that should not be
> restricted in Belgium. I am talking about channels you are allowed to use in
> Belgium, which get disabled by the driver. How can this not be a bug?
> If I call crda for the BE domain, I expect to get _all_ channels that are
> allowed in Belgium, not just some.

There are two places where the country codes and their associated
restrictions come from:
1. The user, by saying "iw reg set XX" or having some other program
set that for them.
2. The driver, by asking the card which country it's been configured for.

The kernel regulatory framework then takes these two sets of
regulatory data, finds the intersection of them, and restricts the
channels and options available for the card based on that.

Why?

I'm not sure of the exact details, but I know that most wireless cards
are configured, by which I mean calibrated, adjusted and tuned to work
in a particular country. Some are configured for the entire world, but
most are configured for a single country's requirements. The driver
cannot assume that if it asks the card to do anything outside the
country it's been configured for, that it will perform predictably.
So, for example, if the driver asks your card to use a channel that is
outside the US's regulatory requirements, the driver cannot guarantee
that, even if it instructs the card how to use that channel correctly,
it will actually use that channel in a manner consistent with
Belgium's regulatory requirements.

The driver's behaviour when it encounters the unset regulatory
information on the card will be to use the default information for
that card. Which in this case is the US regulatory restrictions.

I hate to say it, but the issue here is *not* the driver itself. The
supplier of that card has not set it up correctly for Belgium, and the
driver is compensating for that as best as it can.

I have a similar card at home in Australia, it's configured for use in
China, and thankfully the intersection of China's and Australia's
regulatory requirements are such that I can use it for the purpose I
purchased it for.

Thanks,

-- 
Julian Calaby

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

Re: ath9k bug in country domain handling

[Erwin Van de Velde]

Hi,

On Sunday 17 June 2012 12:15:47 Julian Calaby wrote:
> There are two places where the country codes and their associated
> restrictions come from:
> 1. The user, by saying "iw reg set XX" or having some other program
> set that for them.
> 2. The driver, by asking the card which country it's been configured for.
> 
> The kernel regulatory framework then takes these two sets of
> regulatory data, finds the intersection of them, and restricts the
> channels and options available for the card based on that.
> 
> Why?
> 
> I'm not sure of the exact details, but I know that most wireless cards
> are configured, by which I mean calibrated, adjusted and tuned to work
> in a particular country. Some are configured for the entire world, but
> most are configured for a single country's requirements. The driver
> cannot assume that if it asks the card to do anything outside the
> country it's been configured for, that it will perform predictably.
> So, for example, if the driver asks your card to use a channel that is
> outside the US's regulatory requirements, the driver cannot guarantee
> that, even if it instructs the card how to use that channel correctly,
> it will actually use that channel in a manner consistent with
> Belgium's regulatory requirements.
> 
> The driver's behaviour when it encounters the unset regulatory
> information on the card will be to use the default information for
> that card. Which in this case is the US regulatory restrictions.
> 
> I hate to say it, but the issue here is *not* the driver itself. The
> supplier of that card has not set it up correctly for Belgium, and the
> driver is compensating for that as best as it can.
> 
> I have a similar card at home in Australia, it's configured for use in
> China, and thankfully the intersection of China's and Australia's
> regulatory requirements are such that I can use it for the purpose I
> purchased it for.
> 

Ow., this is new to me. Thanks a lot for the explanation, now I see why things 
are like they are!

Thanks a lot!
Erwin

Re: ath9k bug in country domain handling

[Julian Calaby]

Hi Xose,

On Thu, Jun 21, 2012 at 8:30 AM, Xose Vazquez Perez
<xose.vazquez@gmail.com> wrote:
> On 06/19/2012 01:46 AM, Julian Calaby wrote:
>
>> As I explained previously, the cards are tuned and configured for a
>> particular regulatory domain when they're manufactured. The driver
>> cannot assume that the card will be capable of complying with another
>> regulatory domain.
>
>
> That's false.
>
> Atheros does not produce distinct chips for different countries or
> markets.

That's not what I meant.

I meant that the *card* not the *chip* is configured. It would be
incredibly wasteful for Atheros to produce different chips per market.

IIRC the card can sometimes be built / configured to work properly
within certain frequencies while disregarding the functionality of
others, much like how some hardware expects to be used with Windows
and fails utterly when Linux does things ever-so-slightly differently.
As I understand it, the country code stored in the EEPROM is a way of
making sure that the driver knows what to expect of the hardware so
that it can stay within the known working range of the hardware.

> <http://marc.info/?l=linux-wireless&m=125072768530674>
>
> There is only ONE chip, with custom "regdomain" values in the EEPROM.
> And the *driver* applies constraints based on that value. No more no less.
> Then, crda/wireless-regdb only can narrows things a bit more.

Exactly.

> Atheros chips can go beyond IEEE 802.11 frecuencies.

Of course, a wireless card is essentially a software controlled radio
transceiver with firmware designed to do IEEE 802.11. There is
precious little that would prevent anyone from making it do other
things, the Libertas chips used by the OLPC devices are an example, as
is a group of people who were modifying Prism cards to work as
stand-alone devices. Hardware can often be much more capable than what
it's used for, for example, a certain type of TV tuner card can be
turned into a quite powerful software defined radio, I have no reason
to believe that this couldn't be done with a wireless card.

Thanks,

-- 
Julian Calaby

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

Re: ath9k bug in country domain handling

[Xose Vazquez Perez]

On 06/19/2012 01:46 AM, Julian Calaby wrote:

> As I explained previously, the cards are tuned and configured for a
> particular regulatory domain when they're manufactured. The driver
> cannot assume that the card will be capable of complying with another
> regulatory domain.

That's false.

Atheros does not produce distinct chips for different countries or
markets.

<http://marc.info/?l=linux-wireless&m=125072768530674>

There is only ONE chip, with custom "regdomain" values in the EEPROM.
And the *driver* applies constraints based on that value. No more no less.
Then, crda/wireless-regdb only can narrows things a bit more.


Atheros chips can go beyond IEEE 802.11 frecuencies.

dd-wrt is selling "DD-WRT Superchannel Extension":
http://www.dd-wrt.com/shop/catalog/product_info.php?cPath=22&products_id=717
[...]
SuperChannel allows you to use special frequencies
from 2.3 Ghz - 2.7 Ghz (802.11g capable devices only)
and 4.9 Ghz - 6.1 Ghz (802.11a capable devices only).
[...]
Please note that the DD-WRT Superchannel license can only be
applied to certain routers equipped with Atheros based WLAN-hardware.
http://www.qsl.net/kb9mwr/projects/wireless/ddwrt-ham.jpg

Mikrotik also sells a 'code' to unlock "custom" frequencies:
http://www.mikrotik.com/documentation//manual_2.7/Interface/Wireless.html#ht2761782821

Ubiquiti used to do it: http://www.qsl.net/kb9mwr/projects/wireless/airos-ham.jpg



You can read further info in: http://www.qsl.net/kb9mwr/projects/wireless/modify.html

Re: ath9k bug in country domain handling

[Julian Calaby]

Hi Erwin,

On Mon, Jun 18, 2012 at 10:25 PM, Erwin Van de Velde
<erwin.vandevelde@gmail.com> wrote:
>
> The output I get is:
> [ 8.931463] ath: EEPROM regdomain: 0x0
> [ 8.931483] ath: EEPROM indicates default country code should be used
> [ 8.931502] ath: doing EEPROM country->regdmn map search
> [ 8.931526] ath: country maps to regdmn code: 0x3a
> [ 8.931544] ath: Country alpha2 being used: US
> [ 8.931561] ath: Regpair used: 0x3a
>
> As I see it, the regdomain is 00 and not US, so why does the ath9k driver
> decide to put me in the US? US should not be the default country code, but
> world reg domain. The preferred solution in my opinion is that the driver
> would require a regdomain to be given if it is not already set by the card.
> Choosing US as a default seems purely random .

No, US is the *default*. It's not just flipping a coin and choosing
one, it's choosing the default. Choosing the US as the default is
probably specified in the specification of the chipset by Atheros. (A
US-based company)

> It would make far more sense to
> have no restricions by default if no regdomain is given and require it as a
> parameter, so everyone can set it correctly to his correct domain. The current
> method not only disallows valid channels to be used, but can also allow for
> legally forbidden channels to be used, which could be even worse.

As I explained previously, the cards are tuned and configured for a
particular regulatory domain when they're manufactured. The driver
cannot assume that the card will be capable of complying with another
regulatory domain.

The cfg80211 regulatory code is trying to produce the best result it
can that both complies with the regulatory restrictions in force and
allows you to use your card. Producing a set of rules that are the
intersection of the US and Belgium restrictions is the best way to do
this. The card says it's in the US, you say you're in Belgium - the
intersection of the restrictions is the only way to satisfy both of
those regulatory requirements and ensure that the card is working as
required by whichever laws are in effect.

Thanks,

-- 
Julian Calaby

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

Re: ath9k bug in country domain handling

[Xose Vazquez Perez]

On 06/18/2012 02:25 PM, Erwin Van de Velde wrote:

> The output I get is:
> [ 8.931463] ath: EEPROM regdomain: 0x0
> [ 8.931483] ath: EEPROM indicates default country code should be used
> [ 8.931502] ath: doing EEPROM country->regdmn map search
> [ 8.931526] ath: country maps to regdmn code: 0x3a
> [ 8.931544] ath: Country alpha2 being used: US
> [ 8.931561] ath: Regpair used: 0x3a
>
> As I see it, the regdomain is 00 and not US, so why does the ath9k driver
> decide to put me in the US? US should not be the default country code, but

It seems natural to think that 0x0 is a 'neutral' region, far from it.
0x0 is US.

> world reg domain. The preferred solution in my opinion is that the driver
> would require a regdomain to be given if it is not already set by the card.
> Choosing US as a default seems purely random . It would make far more sense to
> have no restricions by default if no regdomain is given and require it as a
> parameter, so everyone can set it correctly to his correct domain. The current
> method not only disallows valid channels to be used, but can also allow for
> legally forbidden channels to be used, which could be even worse.

You didn't read any links of my previous e-mail, please do it.


I can provide you some info how to fix it, out of this mailing list.
Because it's a bit annoying to buy a Atheros  wireless card, and ignore their
programmed values. Manufacturers: yellow stickers are cheap and visible!!!

Re: ath9k bug in country domain handling

[Erwin Van de Velde]

On Sunday 17 June 2012 20:16:21 Xose Vazquez Perez wrote:
> Erwin Van de Velde wrote:
> > I have 802.11n cards with an atheros chipset with no default country
> > domain. Upon initialization, crda is set to US domain, after which I try
> > to change it to another domain, the driver only accepts further
> > limitations: i.e. if a channel is allowed in the US but not in Belgium,
> > it is disabled, but the other way round: if a channel is not allowed in
> > the US, but is allowed in Belgium it is not enabled.
> 
> "no default country domain" :-???
> 
> # dmesg | grep ath:
> 
> look for:
> ath: EEPROM regdomain: XXX
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: XX
> ath: Regpair used: XXX
> 
> 
> This is a Atheros *driver* feature.
> Channels are restricted based on the EEPROM value.
> And crda/wireless-regdb only can makes things _worse_.

The output I get is:
[ 8.931463] ath: EEPROM regdomain: 0x0
[ 8.931483] ath: EEPROM indicates default country code should be used
[ 8.931502] ath: doing EEPROM country->regdmn map search
[ 8.931526] ath: country maps to regdmn code: 0x3a
[ 8.931544] ath: Country alpha2 being used: US
[ 8.931561] ath: Regpair used: 0x3a

As I see it, the regdomain is 00 and not US, so why does the ath9k driver 
decide to put me in the US? US should not be the default country code, but 
world reg domain. The preferred solution in my opinion is that the driver 
would require a regdomain to be given if it is not already set by the card. 
Choosing US as a default seems purely random . It would make far more sense to 
have no restricions by default if no regdomain is given and require it as a 
parameter, so everyone can set it correctly to his correct domain. The current 
method not only disallows valid channels to be used, but can also allow for 
legally forbidden channels to be used, which could be even worse.

Regards,
Erwin

Re: ath9k bug in country domain handling

[Xose Vazquez Perez]

Erwin Van de Velde wrote:

> I have 802.11n cards with an atheros chipset with no default country domain.
> Upon initialization, crda is set to US domain, after which I try to change it
> to another domain, the driver only accepts further limitations: i.e. if a
> channel is allowed in the US but not in Belgium, it is disabled, but the other
> way round: if a channel is not allowed in the US, but is allowed in Belgium it
> is not enabled.

"no default country domain" :-???

# dmesg | grep ath:

look for:
ath: EEPROM regdomain: XXX
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: XX
ath: Regpair used: XXX


This is a Atheros *driver* feature.
Channels are restricted based on the EEPROM value.
And crda/wireless-regdb only can makes things _worse_.

Solutions:
- modify the driver
- reprogramming of the EEPROM
- buy another board and keep away from Atheros chipsets

You should read:
http://wireless.kernel.org/en/users/Drivers/ath#Regulatory
http://marc.info/?l=linux-wireless&m=125072768530674
http://marc.info/?l=linux-wireless&m=125078520924477
http://wiki.openwrt.org/doc/howto/wireless.utilities?s[]=regulatory#iw  see "Note:"

In linux source code, see regd* files:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/net/wireless/ath