CRDA and ath5k with no country code in EEPROM

CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

Hi,

I'm not sure I get it right:
I have an ath5k card without a country code in EEPROM. I think such card
is supposed to not force any additional restrictions, am I wrong?
The problem is "no country code" is effectively equal to US, i.e. it's
forcing additional US restrictions no matter what the actual regdomain
is.

Linux 2.6.33.

ath5k 0000:00:0d.0: registered as 'phy0'
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'pid'
ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy0: RF5112B multiband radio found (0x36)
cfg80211: Calling CRDA for country: US
cfg80211: Regulatory domain changed to country: US
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
    (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)

Then I "iw reg set PL":

cfg80211: Calling CRDA for country: PL
cfg80211: Regulatory domain changed to country: PL
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
    (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
    (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)

and I still get:
# iw list|grep disabled
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
                        * 5600 MHz [120] (disabled)
                        * 5620 MHz [124] (disabled)
                        * 5640 MHz [128] (disabled)
while at least channels 12 and 13 should be enabled here (and they are
when I plug a card with European country code).

I'm told ath9k does the same.

Comments?
Please Cc: me, thanks.
--
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Sun, Mar 28, 2010 at 1:52 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Hi,
>
> I'm not sure I get it right:
> I have an ath5k card without a country code in EEPROM. I think such card
> is supposed to not force any additional restrictions, am I wrong?
> The problem is "no country code" is effectively equal to US, i.e. it's
> forcing additional US restrictions no matter what the actual regdomain
> is.
>
> Linux 2.6.33.
>
> ath5k 0000:00:0d.0: registered as 'phy0'
> ath: EEPROM regdomain: 0x0

I've documented this specific case here:

http://wireless.kernel.org/en/users/Drivers/ath/#The_0x0_regulatory_domain

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

> I've documented this specific case here:
>
> http://wireless.kernel.org/en/users/Drivers/ath/#The_0x0_regulatory_domain

Thanks.

I'm not sure how the modified regulatory.bin could work, though:
I really don't want to use restricted frequencies etc. when the
regulatory domain is set to US (i.e. when operating in USA), I only want
to use the extra channels etc. when in e.g. Europe. IOW I should be able
to iw reg set US and get the US freqs only.

A driver modification to ignore the default restrictions (while obeying
the regulatory.bin, on a 0-country cards only, of course) - that would
work.
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Mon, Mar 29, 2010 at 12:15 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
>> I've documented this specific case here:
>>
>> http://wireless.kernel.org/en/users/Drivers/ath/#The_0x0_regulatory_domain
>
> Thanks.
>
> I'm not sure how the modified regulatory.bin could work, though:
> I really don't want to use restricted frequencies etc. when the
> regulatory domain is set to US (i.e. when operating in USA), I only want
> to use the extra channels etc. when in e.g. Europe.

I agree with that wishful thinking, however current legislation does
now allow for dynamic enabling of frequencies on devices certified
under part 15 rules. We can likely work towards changing the
legislation for this but that's something I haven't seen many
companies willing to lobby for. We'd need a big company to help with
this lobby.

> IOW I should be able
> to iw reg set US and get the US freqs only.
>
> A driver modification to ignore the default restrictions (while obeying
> the regulatory.bin, on a 0-country cards only, of course) - that would
> work.

And it would also make our drivers break regulatory rules. We're not
going to do that on Linux because proving that we can be responsible
is in fact what does allow us to get proper vendor support for 802.11
drivers.

See:

http://wireless.kernel.org/en/developers/Regulatory/statement

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

>> I'm not sure how the modified regulatory.bin could work, though:
>> I really don't want to use restricted frequencies etc. when the
>> regulatory domain is set to US (i.e. when operating in USA), I only want
>> to use the extra channels etc. when in e.g. Europe.
>
> I agree with that wishful thinking, however current legislation does
> now allow for dynamic enabling of frequencies on devices certified
> under part 15 rules. We can likely work towards changing the
> legislation for this but that's something I haven't seen many
> companies willing to lobby for. We'd need a big company to help with
> this lobby.

But... isn't the modifying of the regulatory.bin (the US part of it)
to include channels valid in e.g. Europe breaking the (US) rules? I'm
not asking you for a legal advice binding Atheros as the manufacturer in
the USA, I'm asking how to enable the user to be technically compliant
here in Europe where the hardware is sold, and also in the USA if the
user gets there and sets the regdomain (and elsewhere in the world, in
fact).

Modifying regulatory.bin doesn't seem to help here, does it?

>> A driver modification to ignore the default restrictions (while obeying
>> the regulatory.bin, on a 0-country cards only, of course) - that would
>> work.
>
> And it would also make our drivers break regulatory rules. We're not
> going to do that on Linux because proving that we can be responsible
> is in fact what does allow us to get proper vendor support for 802.11
> drivers.

I'm not asking you to do that, I only need to know if it's the correct
(and only?) way of fixing this problem (while still providing
compliance of the whole device). Fortunately I'm not responsible for the
legalities.


The other thing is the meaning of country=0 in case of Mikrotik cards
(and maybe others). Perhaps they should get them back. I wonder if
their drivers break the FCC rules, allowing "0" (=US) cards to use
channels restricted in the US.
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Mon, Mar 29, 2010 at 12:49 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
>>> I'm not sure how the modified regulatory.bin could work, though:
>>> I really don't want to use restricted frequencies etc. when the
>>> regulatory domain is set to US (i.e. when operating in USA), I only want
>>> to use the extra channels etc. when in e.g. Europe.
>>
>> I agree with that wishful thinking, however current legislation does
>> now allow for dynamic enabling of frequencies on devices certified
>> under part 15 rules. We can likely work towards changing the
>> legislation for this but that's something I haven't seen many
>> companies willing to lobby for. We'd need a big company to help with
>> this lobby.
>
> But... isn't the modifying of the regulatory.bin (the US part of it)
> to include channels valid in e.g. Europe breaking the (US) rules?

Not if you sign off on it, which is exactly why the whole singing
thing was invented. You would do this if say, you sell an AP and you
verify and tested regulatory compliance against a different regulatory
region.

> I'm
> not asking you for a legal advice binding Atheros as the manufacturer in
> the USA, I'm asking how to enable the user to be technically compliant
> here in Europe where the hardware is sold, and also in the USA if the
> user gets there and sets the regdomain (and elsewhere in the world, in
> fact).

The only way to be legally compliant is if the vendor who you bought
the device from got regulatory testing for the device. That's all. Its
not cheap to do this work, so its also likely a reason why legislation
does not address this yet, and why SDR certification seems to be a
pain in the ass and no one I know is doing it these days.

IMHO the easy way to address this in legislation is simply to say that
if the user changes some regulatory components the liability passes on
to them. That would take care of the legal issues AFAICT. But we're
not there yet.

> Modifying regulatory.bin doesn't seem to help here, does it?
>
>>> A driver modification to ignore the default restrictions (while obeying
>>> the regulatory.bin, on a 0-country cards only, of course) - that would
>>> work.
>>
>> And it would also make our drivers break regulatory rules. We're not
>> going to do that on Linux because proving that we can be responsible
>> is in fact what does allow us to get proper vendor support for 802.11
>> drivers.
>
> I'm not asking you to do that, I only need to know if it's the correct
> (and only?) way of fixing this problem (while still providing
> compliance of the whole device). Fortunately I'm not responsible for the
> legalities.
>
>
> The other thing is the meaning of country=0 in case of Mikrotik cards
> (and maybe others). Perhaps they should get them back. I wonder if
> their drivers break the FCC rules, allowing "0" (=US) cards to use
> channels restricted in the US.

country code programmed to 0 is defined by Atheros documentation to be
in the "US". Mikrotek likely does their own testing for what they
allow, vendors who sell APs or hardware for APs have to anyway, as
Atheros does not do this for those customers.

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Christian Lamparter]

On Monday 29 March 2010 21:49:59 Krzysztof Halasa wrote:
> The other thing is the meaning of country=0 in case of Mikrotik cards
> (and maybe others). Perhaps they should get them back. I wonder if
> their drivers break the FCC rules, allowing "0" (=US) cards to use
> channels restricted in the US.

why should they? You can _easily_ edit the whole eeprom content
and change the country code to your heart's delight.

Just get a _tool_ called: ath_info and read the instructions how to use it.
If you have doubts, you can also connect eeprom (24c16) to a i2c-bus and
reprogram it, it's as simple as that....

Regards,
	Chr

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

>> But... isn't the modifying of the regulatory.bin (the US part of it)
>> to include channels valid in e.g. Europe breaking the (US) rules?
>
> Not if you sign off on it, which is exactly why the whole singing
> thing was invented. You would do this if say, you sell an AP and you
> verify and tested regulatory compliance against a different regulatory
> region.

So what exactly do I change? Can the regulatory.bin change the default
country?

Remember I need to be compliant to the US freq sets as well - when the
regdomain is set to US. IOW I can't allow the user operating the device
to set e.g. channel 12 when the user selects country=US (so there is a
big difference between country 0=US and the real country=US).

> country code programmed to 0 is defined by Atheros documentation to be
> in the "US".

But the driver says:
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a

At least for the driver 0 doesn't mean US, it means "default country".
Perhaps the meaning of "default country" depends on maybe location of
the hw and/or sw manufacturer?
Then maybe what I really need to do is substituting "EU" as the default
country and enforcing EU restrictions, even when the country selected by
the user is outside EU (e.g. enforcing EU+US in US)?
And when the user gets a card with country=US (not 0), the EU
restictions would be dropped (when physically in USA)?

I think this all reduces to the meaning of country=0 for cards sold (in
this case) in Europe (and maybe manufactured here).


If the driver said "EEPROM regdomain: 0x0 = US" I'd return the cards to
the manufacturer, simple (realistically they'd fix the EEPROM instead).
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

Christian Lamparter <chunkeey@googlemail.com> writes:

> why should they? You can _easily_ edit the whole eeprom content
> and change the country code to your heart's delight.

Because I can't (and don't want to) do that to every card.
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Mon, Mar 29, 2010 at 1:04 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Monday 29 March 2010 21:49:59 Krzysztof Halasa wrote:
>> The other thing is the meaning of country=0 in case of Mikrotik cards
>> (and maybe others). Perhaps they should get them back. I wonder if
>> their drivers break the FCC rules, allowing "0" (=US) cards to use
>> channels restricted in the US.
>
> why should they? You can _easily_ edit the whole eeprom content
> and change the country code to your heart's delight.
>
> Just get a _tool_ called: ath_info and read the instructions how to use it.
> If you have doubts, you can also connect eeprom (24c16) to a i2c-bus and
> reprogram it, it's as simple as that....

I'll note this is out of the scope of what is supported, so if you
muck with ath_info you're on your own.

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Mon, Mar 29, 2010 at 1:48 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
>>> But... isn't the modifying of the regulatory.bin (the US part of it)
>>> to include channels valid in e.g. Europe breaking the (US) rules?
>>
>> Not if you sign off on it, which is exactly why the whole singing
>> thing was invented. You would do this if say, you sell an AP and you
>> verify and tested regulatory compliance against a different regulatory
>> region.
>
> So what exactly do I change? Can the regulatory.bin change the default
> country?

Huh?

> Remember I need to be compliant to the US freq sets as well - when the
> regdomain is set to US. IOW I can't allow the user operating the device
> to set e.g. channel 12 when the user selects country=US (so there is a
> big difference between country 0=US and the real country=US).

Huh?

>> country code programmed to 0 is defined by Atheros documentation to be
>> in the "US".
>
> But the driver says:
> ath: EEPROM regdomain: 0x0
> ath: EEPROM indicates default country code should be used
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x3a
> ath: Country alpha2 being used: US
> ath: Regpair used: 0x3a
>
> At least for the driver 0 doesn't mean US, it means "default country".
> Perhaps the meaning of "default country" depends on maybe location of
> the hw and/or sw manufacturer?

I just pointed to some documentation for you which indicated 0x0 means "US".

> Then maybe what I really need to do is substituting "EU" as the default
> country and enforcing EU restrictions, even when the country selected by
> the user is outside EU (e.g. enforcing EU+US in US)?
> And when the user gets a card with country=US (not 0), the EU
> restictions would be dropped (when physically in USA)?
>
> I think this all reduces to the meaning of country=0 for cards sold (in
> this case) in Europe (and maybe manufactured here).
>
>
> If the driver said "EEPROM regdomain: 0x0 = US" I'd return the cards to
> the manufacturer, simple (realistically they'd fix the EEPROM instead).

Whatever works for you. I'm telling you what Atheros supports on its
documentation, if an ODM does something wacky, that's on them.

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Holger Schurig]

> But the driver says:
> ath: EEPROM regdomain: 0x0
> ath: EEPROM indicates default country code should be used
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x3a
> ath: Country alpha2 being used: US
> ath: Regpair used: 0x3a

I ignored all this bullshit an US rules that won't apply to germany anyway. So 
I simply added a patch to my devices kernel that overwrote the EEPROM 
regdomain. That's way cheaper than to reprogram each device.

Some people live in a wishful world where they think that every manufacturer 
reads all docs of the chipset producer and where only the correctly programmed 
cards submerge in the correct markets.

Creating my won regdomain bin with my own signature was way too much for me.


> If the driver said "EEPROM regdomain: 0x0 = US" I'd return the cards to
> the manufacturer, simple (realistically they'd fix the EEPROM instead).

And the supplies has this card form some chinese source and can't get them to 
get reprogrammed. Also returning a bunch of 250 cards is quite an 
administrative hassle, not to say that during that time you cannot produce 250 
devices, because you're then short of supply (substitute "250" with any number 
you like).

Really, country stuff in EEPROM is b......t, and I'm simply ignoring this 
concept --- for my specific usage domain.

-- 
http://www.holgerschurig.de

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

>> So what exactly do I change? Can the regulatory.bin change the default
>> country?
>
> Huh?
>
>> Remember I need to be compliant to the US freq sets as well - when the
>> regdomain is set to US. IOW I can't allow the user operating the device
>> to set e.g. channel 12 when the user selects country=US (so there is a
>> big difference between country 0=US and the real country=US).
>
> Huh?

Not sure what do you mean. Are my expectations unrealistic?

>> But the driver says:
>> ath: EEPROM regdomain: 0x0
>> ath: EEPROM indicates default country code should be used
>> ath: doing EEPROM country->regdmn map search
>> ath: country maps to regdmn code: 0x3a
>> ath: Country alpha2 being used: US
>> ath: Regpair used: 0x3a
>>
>> At least for the driver 0 doesn't mean US, it means "default country".
>> Perhaps the meaning of "default country" depends on maybe location of
>> the hw and/or sw manufacturer?
>
> I just pointed to some documentation for you which indicated 0x0 means
> "US".

Yes, but the meaning depends on the POV. What is important to me is what
does that mean to a) the software I use, b) the hardware I use (cards).
The driver doesn't say 0=US, perhaps it should? Then things would be
very different.
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

Holger Schurig <holgerschurig@gmail.com> writes:

> Creating my won regdomain bin with my own signature was way too much for me.

I can do that but I don't think it solves the problem. Overriding the
"default" country in EEPROM or in the driver, sure it does.

I can't simply change the freq ranges assigned to US to those valid in
EU and pretend it's "fixed".
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Tue, Mar 30, 2010 at 4:41 AM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
>>> So what exactly do I change? Can the regulatory.bin change the default
>>> country?
>>
>> Huh?
>>
>>> Remember I need to be compliant to the US freq sets as well - when the
>>> regdomain is set to US. IOW I can't allow the user operating the device
>>> to set e.g. channel 12 when the user selects country=US (so there is a
>>> big difference between country 0=US and the real country=US).
>>
>> Huh?
>
> Not sure what do you mean. Are my expectations unrealistic?
>
>>> But the driver says:
>>> ath: EEPROM regdomain: 0x0
>>> ath: EEPROM indicates default country code should be used
>>> ath: doing EEPROM country->regdmn map search
>>> ath: country maps to regdmn code: 0x3a
>>> ath: Country alpha2 being used: US
>>> ath: Regpair used: 0x3a
>>>
>>> At least for the driver 0 doesn't mean US, it means "default country".
>>> Perhaps the meaning of "default country" depends on maybe location of
>>> the hw and/or sw manufacturer?
>>
>> I just pointed to some documentation for you which indicated 0x0 means
>> "US".
>
> Yes, but the meaning depends on the POV. What is important to me is what
> does that mean to a) the software I use, b) the hardware I use (cards).
> The driver doesn't say 0=US, perhaps it should? Then things would be
> very different.

My point was that this is not something meant to be interpreted by
anyone for what "default country" means, the documentation I pointed
out clearly states that 0x0 is designed to mean to match the "US" by
Atheros hardware as per hardware documentation provided to ODMs.

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

> My point was that this is not something meant to be interpreted by
> anyone for what "default country" means, the documentation I pointed
> out clearly states that 0x0 is designed to mean to match the "US" by
> Atheros hardware as per hardware documentation provided to ODMs.

I understand this, but the reality is that I have to work with hardware
and software, not with the docs provided by Atheros to some other
parties.

Software (the official Atheros driver, to be precise) says 0 isn't
exactly US.
Hardware (card) manufacturer says 0 isn't US.

What do you think can I do?

I obviously would go the regulatory.bin way, if it was possible. But
I think regulatory.bin simply describes frequencies etc. valid in
different countries, and if the file contains correct data (and it seems
it does), there is nothing I can "fix" there.

For now I think the best I can do is to add
CONFIG_*80211_DEFAULT_COUNTRY (with default = "US"), and to treat 0 as
this DEFAULT_COUNTRY. This way I don't enable users to disobey the rules
(more than they're already able, since they can patch and recompile
anyway), and at the same time I don't put the (inappropriate for many
people) default country in the sources.
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Tue, Mar 30, 2010 at 11:21 AM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
>> My point was that this is not something meant to be interpreted by
>> anyone for what "default country" means, the documentation I pointed
>> out clearly states that 0x0 is designed to mean to match the "US" by
>> Atheros hardware as per hardware documentation provided to ODMs.
>
> I understand this, but the reality is that I have to work with hardware
> and software, not with the docs provided by Atheros to some other
> parties.
>
> Software (the official Atheros driver, to be precise) says 0 isn't
> exactly US.
> Hardware (card) manufacturer says 0 isn't US.

Would it make you happy if I send a patch to clarify that?

> What do you think can I do?

I've indicated that your card is already working as it was designed.
The EEPROM is not something that was designed for end users to modify.
Who programmed your EEPROM choose that for a reason, and only they and
as per Atheros's documentation would know what the goal was,
regardless of what you see in software. I have tried clarifying to you
what the goal was, and if software uses a macro for "DEFAULT" for 0x0
just ignore that, I am telling you that is supposed to be "US".

If you want to muck with the EEPROM/code for regulatory compliance
that is up to you and that is simply not supported due to a few
things. One of them is calibration data which may or not be available
for the region you would choose blindly. Properly enabling users to
change their regulatory domain at their own whim really requires more
involvement, sure you'd be able to use some additional channels but it
by no means would mean that they are in compliance or that the EIRP
you use hits the actual desired target. The important part really is
compliance.

The regulatory code on for the Atheros drivers enables usage only of
the channels dictated by the EEPROM and what we in software match that
EEPROM code to tables in software. This is by design. The Linux
regulatory framework allows you to further restrict the device further
but for Atheros cards if you change countries you will not get new
channels if your original programmed regulatory domain does not allow
for it.

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Christian Lamparter]

On Tuesday 30 March 2010 20:21:36 Krzysztof Halasa wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
> 
> > My point was that this is not something meant to be interpreted by
> > anyone for what "default country" means, the documentation I pointed
> > out clearly states that 0x0 is designed to mean to match the "US" by
> > Atheros hardware as per hardware documentation provided to ODMs.
> 
> I understand this, but the reality is that I have to work with hardware
> and software, not with the docs provided by Atheros to some other
> parties.
> 
> Software (the official Atheros driver, to be precise) says 0 isn't
> exactly US.
> Hardware (card) manufacturer says 0 isn't US.

Are you sure, you (or the hw manufacturer for that matter) didn't confuse
the country code with regdomain code?

because while they have more or less the same function, they do have different
mappings. The 0x00 country code is reserved for the FCC (US), while the 0x00
regdomain code is a described as "debug" with supposedly no limitations?!

Regards,
	Chr

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Tue, Mar 30, 2010 at 11:49 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Tuesday 30 March 2010 20:21:36 Krzysztof Halasa wrote:
>> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>>
>> > My point was that this is not something meant to be interpreted by
>> > anyone for what "default country" means, the documentation I pointed
>> > out clearly states that 0x0 is designed to mean to match the "US" by
>> > Atheros hardware as per hardware documentation provided to ODMs.
>>
>> I understand this, but the reality is that I have to work with hardware
>> and software, not with the docs provided by Atheros to some other
>> parties.
>>
>> Software (the official Atheros driver, to be precise) says 0 isn't
>> exactly US.
>> Hardware (card) manufacturer says 0 isn't US.
>
> Are you sure, you (or the hw manufacturer for that matter) didn't confuse
> the country code with regdomain code?
>
> because while they have more or less the same function, they do have different
> mappings. The 0x00 country code is reserved for the FCC (US), while the 0x00
> regdomain code is a described as "debug" with supposedly no limitations?!

That debug regulatory domain is not a valid regulatory domain
supported in the field, it was a debug hack. It is simply not a
regulatory domain which ODMs / OEMs calibrate their cards for.

  Luis

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

>> Software (the official Atheros driver, to be precise) says 0 isn't
>> exactly US.
>> Hardware (card) manufacturer says 0 isn't US.
>
> Would it make you happy if I send a patch to clarify that?

That would fix a good part of the problem, yes. TIA.

> I've indicated that your card is already working as it was designed.

But that's not the case.

The Atheros _chips_ are probably working as designed. The card(s) does
not, since it was designed for European market, and its designer
confirms this. Yet, by default, this card (+ driver) enables channels
which should be disabled in Europe, and disables others, which should be
available.

This is caused by interaction between two pieces - the driver and the
card. Most probably each one of them, alone, is not at fault.

> The EEPROM is not something that was designed for end users to modify.

Though I'm not end user, I will leave it for others to modify, no
problem. I only need a proof (such as the driver printing "US") it
should be modified.

> Who programmed your EEPROM choose that for a reason, and only they and
> as per Atheros's documentation would know what the goal was,

and those who were told about it. The stated goal is known, and I assume
the calibration data is available as well (I don't have these cards
physically ATM).

> If you want to muck with the EEPROM/code for regulatory compliance
> that is up to you and that is simply not supported due to a few
> things. One of them is calibration data which may or not be available
> for the region you would choose blindly. Properly enabling users to
> change their regulatory domain at their own whim really requires more
> involvement, sure you'd be able to use some additional channels but it
> by no means would mean that they are in compliance or that the EIRP
> you use hits the actual desired target. The important part really is
> compliance.

Precisely. To be compliant I have to restrict usage to a specific set of
frequencies. Unfortunately it's a different set than the one in US.

> The regulatory code on for the Atheros drivers enables usage only of
> the channels dictated by the EEPROM and what we in software match that
> EEPROM code to tables in software. This is by design. The Linux
> regulatory framework allows you to further restrict the device further
> but for Atheros cards if you change countries you will not get new
> channels if your original programmed regulatory domain does not allow
> for it.

Yes, and it fits the needs nicely - if the card manufacturer's idea
about meaning of the EEPROM matches the driver.
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

Christian Lamparter <chunkeey@googlemail.com> writes:

> Are you sure, you (or the hw manufacturer for that matter) didn't confuse
> the country code with regdomain code?
>
> because while they have more or less the same function, they do have different
> mappings. The 0x00 country code is reserved for the FCC (US), while the 0x00
> regdomain code is a described as "debug" with supposedly no limitations?!

I meant regdomain, is the country code (two letters) stored in the
EEPROM as well? If so and if others were talking about it instead of
regdomain, then I was/am really confused.

ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a

(This is for other, old card but I think the ones I need to use produce
the same output).

Then again: does the regdomain = 0 means "US" or "default country" (or
something completely different), according to Atheros' docs?
-- 
Krzysztof Halasa

Re: CRDA and ath5k with no country code in EEPROM

[Luis R. Rodriguez]

On Tue, Mar 30, 2010 at 1:33 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:

> Then again: does the regdomain = 0 means "US" or "default country" (or
> something completely different), according to Atheros' docs?

As per Atheros documentation 0x0 means "US". I've already provided
links for you. I'm sending this from an Atheros e-mail address, not
sure if this helps get this through to you or not.

 Luis

Re: CRDA and ath5k with no country code in EEPROM

[Christian Lamparter]

On Tuesday 30 March 2010 22:33:25 Krzysztof Halasa wrote:
> Christian Lamparter <chunkeey@googlemail.com> writes:
> 
> > Are you sure, you (or the hw manufacturer for that matter) didn't confuse
> > the country code with regdomain code?
> >
> > because while they have more or less the same function, they do have different
> > mappings. The 0x00 country code is reserved for the FCC (US), while the 0x00
> > regdomain code is a described as "debug" with supposedly no limitations?!
> 
> I meant regdomain, is the country code (two letters) stored in the
> EEPROM as well?

There's a 16-bit space for either (custom) regdomain pair, or country code.
(There's also another 16-bit _extension_, but this feature is 
 currently unused...)

But I think, I've to _correct_ myself... ;)
I was a confused, but let me tell why:

Country codes consists of a flag 0x8000 which is OR'd
to the ISO 3166-1 numeric value of (your) country.

Regdomains pairs on the other hand don't have any "precise definition".
It's up to the vendor/manufacture to decide what is what and
this _mapping_ has changed between madwifi and ath5k/ath9k.

Here's the example: 
The old legacy madwifi project 
(http://madwifi-project.org/wiki/UserDocs/CountryCode
 Note the: "This is by no means a valid or complete list and should be revised and added to. " )

lists your regdomain setting (0x0000) as a wild-card.
However, the kernel code regd.c (which is from ath9k) uses a completely
different range (0x006x) for "wild-cards" (or world wide roaming).

And here is the REAL twist: 0x0000 regdomain becomes the country code 0x8348 => "US",
whereas country code 0x8000 will be _sanitized_ to 0x0064 regdomain (world wide roaming).

so...
what about some extra madwifi compat code for ath5k (only)?
All we need to do is to convert those 0x00 && 0xff legacy
regdomain pairs to the new WWR 0x0064?

> If so and if others were talking about it instead of
> regdomain, then I was/am really confused.
> 
> ath: EEPROM regdomain: 0x0
> ath: EEPROM indicates default country code should be used
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x3a
> ath: Country alpha2 being used: US
> ath: Regpair used: 0x3a
> 
> (This is for other, old card but I think the ones I need to use produce
> the same output).
> 
> Then again: does the regdomain = 0 means "US" or "default country" (or
> something completely different), according to Atheros' docs?

Well, there's another pov: Mikrotik HW is surprisingly cheap
and widely available. I'm suspecting they are are subsidizing their HW
and squeezing an extra penny form their software product sales.
(which of course works out-of-the-box)

Regards,
	Chr

Re: CRDA and ath5k with no country code in EEPROM

[Krzysztof Halasa]

"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:

>> Then again: does the regdomain = 0 means "US" or "default country" (or
>> something completely different), according to Atheros' docs?
>
> As per Atheros documentation 0x0 means "US". I've already provided
> links for you. I'm sending this from an Atheros e-mail address, not
> sure if this helps get this through to you or not.

Why are you writing like this? Christian noted there is a difference
between regdomain and country, and you (sort of) confirmed it. This
doesn't seem to be that black and white as you say it is, and it has
nothing to do with you working for Atheros.

BTW is this documentation publicly available? Or perhaps the fragment
listing the possible regdomains? Are the docs limited to specific chips
only? Did the previous versions of the docs, if any, differ in this
matter?

Obviously I'm not saying the following has any authority, and I assume
it may have changed:

http://madwifi-project.org/wiki/UserDocs/CountryCode

This is a preliminary list of regdomains for people who want to play
with changing their regdomain using the ar5k utility

 0x00 (wildcarded)
 0x10 (FCC)
 0x20 (DOC)
 0x30 (ETSI)
 0x31 (Spain)
 0x32 (France)
 0x37 (South Africa)
 0x40 (MKK-Japan)
 0xFF (debug)
 Most "universal/worldwide" cards use zero as the value, some 0xFF

I don't know what the binary HAL did, but this regdomain thing is at
least confusing, not only for me, but apparently also for card
manufacturers with access to the current (and maybe previous) Atheros
docs (and no, this isn't only about Mikrotik).

Unfortunately this confusion makes it easy for the following to not
happen (though probably only outside USA):

    * Average users should not accidentally fail to comply with
      regulations if at all possible;
    * The Linux kernel should offer necessary and reasonable regulatory
      enforcement mechanisms in order to facilitate implementation of a
      broad variety of regulatory policies;
    * Options to disable or circumvent regulatory enforcement should not
      be included in kernels from any public source; and,
    * It is unacceptable for either distributions or community
      developers to knowingly violate the principles stated above.

You also wrote:

> My point was that this is not something meant to be interpreted by
> anyone for what "default country" means, the documentation I pointed
> out clearly states that 0x0 is designed to mean to match the "US" by
> Atheros hardware as per hardware documentation provided to ODMs.

Is the documentation you pointed out more verbose than the following?
http://wireless.kernel.org/en/users/Drivers/ath/#The_0x0_regulatory_domain

> So be aware, 0x0 will always map to the US. If the manufacturer did
> not intend to do that they can provide their own regulatory.bin to
> customers where they can map "US" to their own defined regulatory
> domain.

Could you please show some short example how to do that, according to
the four rules?

Do you mean changing the mapping regdomain 0 -> "US" to another country,
or simply overriding the following:

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)

(IOW, including frequencies which are not legal in US under the "country
US", thus violating the 4 and other rules)?

Still confused,
-- 
Krzysztof Halasa

(and yes, changing anything in the EEPROM is trivial for me - am I wrong
that I wish this cleared without doing this?).