[ath9k-devel] Country code setting issue

[ath9k-devel] Country code setting issue

[mason]

Hi,

By setting country code as US, all of the features implemented iin ath9k
almost seem to be working well unitil now.
But I checked several countries such as China, Japan, North and South
Korea whether their code settings are working well or not.
I think wireless-regdb information can be referenced from the follwing URL
http://wireless.kernel.org/download/wireless-regdb/.**



country CN: (wireless-regdb information)

               (2402 - 2482 @ 40), (N/A, 20)

               (5735 - 5835 @ 40), (N/A, 30)



root at Smart# iw reg set CN (setting at OpenWrt)

root at Smart# iw reg get

country CN:

(2402 - 2482 @ 40), (N/A, 20)

     (5735 - 5835 @ 40), (N/A, 30)



country JP:

               (2402 - 2472 @ 40), (N/A, 20)

               (2457 - 2482 @ 20), (N/A, 20)

               (2474 - 2494 @ 20), (N/A, 20), NO-OFDM

               (4910 - 4930 @ 10), (N/A, 23)

               (4910 - 4990 @ 40), (N/A, 23)

               (4930 - 4950 @ 10), (N/A, 23)

               (5030 - 5045 @ 10), (N/A, 23)

               (5030 - 5090 @ 40), (N/A, 23)

               (5050 - 5060 @ 10), (N/A, 23)

               (5170 - 5250 @ 40), (N/A, 20)

               (5250 - 5330 @ 40), (N/A, 20), DFS

               (5490 - 5710 @ 40), (N/A, 23), DFS



root at Smart#  iw reg set JP

root at Smart:/bin# iw reg get

country JP:

        (2402 - 2472 @ 40), (N/A, 20)

        (2457 - 2482 @ 20), (N/A, 20)

        (2474 - 2494 @ 20), (N/A, 20), NO-OFDM

        (4910 - 4930 @ 10), (N/A, 23)

        (4910 - 4990 @ 40), (N/A, 23)

        (4930 - 4950 @ 10), (N/A, 23)

        (5030 - 5045 @ 10), (N/A, 23)

        (5030 - 5090 @ 40), (N/A, 23)

        (5050 - 5060 @ 10), (N/A, 23)

        (5170 - 5250 @ 40), (N/A, 20)

        (5250 - 5330 @ 40), (N/A, 20), DFS

        (5490 - 5710 @ 40), (N/A, 23), DFS



country KP:

               (2402 - 2482 @ 40), (N/A, 20)

               (5170 - 5330 @ 40), (3, 20)

               (5160 - 5250 @ 40), (3, 20), DFS

               (5490 - 5630 @ 40), (3, 30), DFS

               (5735 - 5815 @ 40), (3, 30)



root at Smart#   iw reg set KP

root at Smart# iw reg get

country KP:

        (2402 - 2482 @ 40), (N/A, 20)

        (5160 - 5250 @ 40), (3, 20), DFS

        (5170 - 5330 @ 40), (3, 20)

        (5490 - 5630 @ 40), (3, 30), DFS

        (5735 - 5815 @ 40), (3, 30)



country KR:

               (2402 - 2482 @ 20), (N/A, 20)

               (5170 - 5250 @ 20), (3, 20)

               (5250 - 5330 @ 20), (3, 20), DFS

               (5490 - 5630 @ 20), (3, 30), DFS

               (5735 - 5815 @ 20), (3, 30)



KR

root at Smart# iw reg set KR

root at Smart# iw reg get

country KR:

        (2402 - 2482 @ 20), (N/A, 20)

        (5170 - 5250 @ 20), (3, 20)

        (5250 - 5330 @ 20), (3, 20), DFS

        (5490 - 5630 @ 20), (3, 30), DFS

        (5735 - 5815 @ 20), (3, 30)



Appraently, they are the same but I found one thing is differently
distinguished.



Except KR country, a wireless mobile can easily access to the AP set by
the rest of the countries' code. The wireless client shows the AP's ssid and
connect to the AP without any problem. When KR code is set, the the client
cannot find any ssid from the AP set by KR. Thus, it cannot associate
with the AP. Before using the trunk version, with KR setting. the kernel
caused booting error and thus the AP cannot be booted normally. With the
trunk version, this situation seems to be resolved but the wireless client
cannot associate its AP and the AP's ssid cannot be disiplayed in client's
scan list.



Thus, how I can resolve into thie country code setting issue? Any comments
are appreciated in advance.

-

mason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20101206/06751cde/attachment-0001.htm 

[ath9k-devel] Country code setting issue

[Luis R. Rodriguez]

On Sun, Dec 5, 2010 at 10:33 PM, mason <myongsu.choe@gmail.com> wrote:
> Appraently, they are the same but I found one thing is differently
> distinguished.

Every country has its own entry even though a lot of them share the
same information. This was done because there is an inherent
complexity that is simply not worth to maintain if you try to group
countries together as with how Atheros used to bundle regulatory
domains together. In the long run this is simply complex and a
maintenance nightmare.

> Except KR country, a wireless mobile can easily access to the AP set by
> the?rest of the countries' code.

No. ath9k cards always respect the regulatory domain programmed into
the hardware's EEPROM, the APIs for users only let the user help
compliance further, never to allow more channels.

Simply avoid setting the regulatory domain unless you really want to
go out of your way to help with things, but things should already be
taken care of for you.

  Luis

[ath9k-devel] Country code setting issue

[Alexander Simon]

> No. ath9k cards always respect the regulatory domain programmed into
> the hardware's EEPROM, the APIs for users only let the user help
> compliance further, never to allow more channels.
Which is a really stupid behaviour as the country code never is correctly set.
I have never seen any card in my country with the correct country code in its 
eeprom.

Additionally, most card have 00 in their eeprom which means "default". 
Personally i would interprete "default" as "ask cfg80211" or "dont give a 
driver hint", but some braindead programmer intrepreted it as "United States".

If you get the message when loading "EEPROM indicates default country code 
should be used", iw reg get will show you US!

The most easiest fix for this case is to look for
reg->country_code = CTRY_UNITED_STATES;
in drivers/net/wireless/ath/regd.c and change it to your country from regd.h.

[ath9k-devel] Country code setting issue

[Luis R. Rodriguez]

On Wed, Dec 8, 2010 at 5:03 AM, Alexander Simon <simon_alex@web.de> wrote:
>> No. ath9k cards always respect the regulatory domain programmed into
>> the hardware's EEPROM, the APIs for users only let the user help
>> compliance further, never to allow more channels.
>
> Which is a really stupid behaviour as the country code never is correctly set.
> I have never seen any card in my country with the correct country code in its
> eeprom.

That's beyond the scope of what code can do, but current legislations
forces us to respect this and not allow users to say they know better.
This can be corrected once legislations allows us to shift liability
down to the user if the user chooses to indicate they know better and
they are wrong.

> Additionally, most card have 00 in their eeprom which means "default".

No, 00 on Atheros cards which are built for STAs means US by design:

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

> Personally i would interprete "default" as "ask cfg80211" or "dont give a
> driver hint", but some braindead programmer intrepreted it as "United States".

No, by design 00 on Atheros cards is the US for cards shipped on
client cards. And without knowing what country you are in cfg80211
defaults to the world regulatory domain which is the intersection of
all regulatory domains.

> If you get the message when loading "EEPROM indicates default country code
> should be used", iw reg get will show you US!

Maybe I'll change the print message to make it clearer to you that
this is by design and not a programmer's choice.

  Luis

[ath9k-devel] Country code setting issue

[Alexander Simon]

Am Mittwoch, 8. Dezember 2010, 19:06:40 schrieben Sie:
> That's beyond the scope of what code can do, but current legislations
> forces us to respect this and not allow users to say they know better.
> This can be corrected once legislations allows us to shift liability
> down to the user if the user chooses to indicate they know better and
> they are wrong.
Isn't that already the case? I mean it's open source. Anyone could see that 
the user would have overwritten a eeprom setting.
Additionally there are Windows drivers that allow some user to enable eg 
channel 12 and 13.  Madwifi had an modoption for that.

> No, 00 on Atheros cards which are built for STAs means US by design:
As i understand regd.c, there is no check if the card is driven as a AP.
I have a SR71-A which i would say is an industrial card, not only STA...

> No, by design 00 on Atheros cards is the US for cards shipped on
> client cards. And without knowing what country you are in cfg80211
> defaults to the world regulatory domain which is the intersection of
> all regulatory domains.
I didn't find this piece of code in madwifi?!?? So it does not seem to be 
"standard".

> Maybe I'll change the print message to make it clearer to you that
> this is by design and not a programmer's choice.
Well, I understand the problem and also did before.
Of course, the problem is caused by Atheros (or card suppliers) and their 
wrong EEPROMs, but personally I don't think they will fix it.

So the problem remains: As Long as there is no card with a proper EEPROM, all 
this doesn't make any sense.
This piece of code is responsible that no european user can use channel 12&13.
But all these card operate at 27dBm on 2.4GHz which is NOT covered by any 
european legislation.
So, by allowing the user setting the CC, you couldn't make it worse.

[ath9k-devel] Country code setting issue

[Luis R. Rodriguez]

On Thu, Dec 9, 2010 at 4:35 AM, Alexander Simon <simon_alex@web.de> wrote:
> Am Mittwoch, 8. Dezember 2010, 19:06:40 schrieben Sie:
>> That's beyond the scope of what code can do, but current legislations
>> forces us to respect this and not allow users to say they know better.
>> This can be corrected once legislations allows us to shift liability
>> down to the user if the user chooses to indicate they know better and
>> they are wrong.
>
> Isn't that already the case? I mean it's open source. Anyone could see that
> the user would have overwritten a eeprom setting.

That's the thing, the user would be the one overriding such a
parameter, in Linux we simply do not expose APIs to users to allow
things to be overridden since we want to comply with local regulatory
rules. Sure, people can hack firmware/EEPROM/code, that is well
understood, but the same hacked stuff won't go upstream, nor will it
be supported. The best we can do upstream is to support the hardware
in compliance with local regulatory laws to enable vendors to
participate in hardware enablement and provide APIs to help
compliance, not to override it. I do believe that in the end things
need to change, and local regulatory agencies should consider allowing
a user change their own regulatory domain, at which point liability
can pass down to them. But not sure how long this will take. In fact
what is likley a better solution is to leave the user out of the
equation and expand on geo location learning. For example there are
these ideas floating of pegging a location onto beacons through 11v,
then propagating this through different APs. In this case you will
only need one single AP with a GPS device to know accurately what
country you are in. If we can start relying on this data blindly for
proper regulatory changes we can more efficiently world roam and use
the spectrum. In the future I even expect that allowed spectrum usage
will be also restricted further down to enable dynamic communication
by defining local regulatory rules which should be followed due to
some computations being done by some agent that sits there and
analyzes the local spectrum. So yes, we're years behind but we have to
take baby steps. The beauty of the solution we have in Linux is that
what I described above is all possible today with our own
infrastructure, its just a matter of laws changing to enable us to use
these technologies in such ways.

> Additionally there are Windows drivers that allow some user to enable eg
> channel 12 and 13. ?Madwifi had an modoption for that.

Supported official drivers will never let you do this today.
Specifically in the US the FCC has made it clear they don't want any
user configurable button to allow you to select countries or channels.
See:

http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains

>> No, 00 on Atheros cards which are built for STAs means US by design:
> As i understand regd.c, there is no check if the card is driven as a AP.

Bingo - there is a discrepancy here for cards shipped in APs that we
are going to address.

> I have a SR71-A which i would say is an industrial card, not only STA...

Heh, we get into semantics here, and I don't play the language game,
I'm just trying to address proper solutions for vendors. Ultimately I
agree with you but we can't simply enable random channels here unless
we know for sure what the ODM/OEM intended with their programmed
EEPROM. Some ODMs have considered 0x0 as a "regulatory debug" domain,
and this is incorrect, and we have clarified this on the page I gave
you. So likely your card was designed for the US. The discrepancy I
noted applies today to a few APs out there but this will be addressed.

>> No, by design 00 on Atheros cards is the US for cards shipped on
>> client cards. And without knowing what country you are in cfg80211
>> defaults to the world regulatory domain which is the intersection of
>> all regulatory domains.
> I didn't find this piece of code in madwifi?!?? So it does not seem to be
> "standard".

MadWifi is a legacy driver, its deprecated, we're addressing support
for all 802.11 cards on Linux upstream and that's what cfg80211 is
for.

>> Maybe I'll change the print message to make it clearer to you that
>> this is by design and not a programmer's choice.
> Well, I understand the problem and also did before.
> Of course, the problem is caused by Atheros (or card suppliers) and their
> wrong EEPROMs, but personally I don't think they will fix it.

Right, the problem lies in between the fine line between the ODMs, and
what they end up choosing for the EEPROM. This is why the safe thing
to do is to simply pick a world regulatory domain, and that is why the
world regulatory domains are the most popular regulatory domains on
Atheros cards. Again, the problem is complex if all you want to do is
pick one single country but what makes it more difficult is local
regulatory rules. I've noted how these things can be resolved but we
can only do so much with current laws.

> So the problem remains: As Long as there is no card with a proper EEPROM, all
> this doesn't make any sense.
> This piece of code is responsible that no european user can use channel 12&13.
> But all these card operate at 27dBm on 2.4GHz which is NOT covered by any
> european legislation.

If a card is programmed for a country that country has its own high
EIRP limits which are followed.

> So, by allowing the user setting the CC, you couldn't make it worse.

As I noted, its wishful thinking and I tend to agree with you if you
can somehow aid the user or ensure they are making the right choice,
however, its simply not something allowed today by local regulatory
laws. My preference is to automate this and not let the user be
involved and expand the way we propagate location learning
information.

  Luis

[ath9k-devel] Country code setting issue

[Peter Stuge]

Luis R. Rodriguez wrote:
> My preference is to automate this and not let the user be involved
> and expand the way we propagate location learning information.

Meanwhile, what is needed is a simple tool to reconfigure cards to
have the actual correct country information.

I agree with the Linux approach, but of course noone outside the US
cares the least about what the FCC wants. (and should not!)

Is it known how to write the EEPROM in-system, or would that have to
be reverse engineered? (Of course it's trivial with an external
programmer.)


//Peter

[ath9k-devel] Country code setting issue

[Luis R. Rodriguez]

On Thu, Dec 9, 2010 at 2:25 PM, Peter Stuge <peter@stuge.se> wrote:
> Luis R. Rodriguez wrote:
>> My preference is to automate this and not let the user be involved
>> and expand the way we propagate location learning information.
>
> Meanwhile, what is needed is a simple tool to reconfigure cards to
> have the actual correct country information.
>
> I agree with the Linux approach, but of course noone outside the US
> cares the least about what the FCC wants. (and should not!)

Sure, agreed, but some other countries like Japan also do not allow
country selection. As a matter of fact US and JP are the only ones I
am aware of that have this explicit restriction.

> Is it known how to write the EEPROM in-system, or would that have to
> be reverse engineered? (Of course it's trivial with an external
> programmer.)

I have considered opening up a tool that lets you do this if we can
determine your country is not US or JP by using GeoClue. I already had
some initial glue code with geoclue for iw but that needs to be
re-written to use the GeoClue master provider instead or querying for
specific providers. If we can rely on the user having  a GPS device
present I think we can support this, so long as the user is not in the
US or JP.

  Luis

[ath9k-devel] Country code setting issue

[Peter Stuge]

Luis R. Rodriguez wrote:
> some other countries like Japan also do not allow country selection.
> As a matter of fact US and JP are the only ones I am aware of that
> have this explicit restriction.

Aha! Well, there are lots of users in other countries. :) It would be
nice for us to have a method.


> > Is it known how to write the EEPROM in-system, or would that have to
> > be reverse engineered? (Of course it's trivial with an external
> > programmer.)
> 
> I have considered opening up a tool that lets you do this if we can
> determine your country is not US or JP by using GeoClue. I already
> had some initial glue code with geoclue for iw

Great idea to add this to iw!


> but that needs to be re-written to use the GeoClue master provider
> instead or querying for specific providers. If we can rely on the
> user having  a GPS device present I think we can support this, so
> long as the user is not in the US or JP.

I think this would be a major improvement for everyone outside US/JP!

(And I guess it's a pretty simple addition?)


//Peter

[ath9k-devel] Country code setting issue

[Luis R. Rodriguez]

On Thu, Dec 9, 2010 at 2:43 PM, Peter Stuge <peter@stuge.se> wrote:
> Luis R. Rodriguez wrote:
>> some other countries like Japan also do not allow country selection.
>> As a matter of fact US and JP are the only ones I am aware of that
>> have this explicit restriction.
>
> Aha! Well, there are lots of users in other countries. :) It would be
> nice for us to have a method.
>
>
>> > Is it known how to write the EEPROM in-system, or would that have to
>> > be reverse engineered? (Of course it's trivial with an external
>> > programmer.)
>>
>> I have considered opening up a tool that lets you do this if we can
>> determine your country is not US or JP by using GeoClue. I already
>> had some initial glue code with geoclue for iw
>
> Great idea to add this to iw!

Patch was posted a while ago, but yeah I just have to rewrite it, but
Johannes also didn't seem too thrilled to have this as part of iw.
Perhaps its better to just have this as a separate app. Not sure.

>> but that needs to be re-written to use the GeoClue master provider
>> instead or querying for specific providers. If we can rely on the
>> user having ?a GPS device present I think we can support this, so
>> long as the user is not in the US or JP.
>
> I think this would be a major improvement for everyone outside US/JP!
>
> (And I guess it's a pretty simple addition?)

Indeed, we wanted to have a solution for embedded to though and APs
neither have nor can get GPS devices on them and GeoClue is a bit of
bloat for embedded as well. So we'll likely have to find an
alternative solution for embedded.b

 Luis

[ath9k-devel] Country code setting issue

[Peter Stuge]

Luis R. Rodriguez wrote:
> >> I have considered opening up a tool that lets you do this if we can
> >> determine your country is not US or JP by using GeoClue. I already
> >> had some initial glue code with geoclue for iw
> >
> > Great idea to add this to iw!
> 
> Patch was posted a while ago, but yeah I just have to rewrite it, but
> Johannes also didn't seem too thrilled to have this as part of iw.
> Perhaps its better to just have this as a separate app. Not sure.

I think it would be fine to also have it in a separate app. Any way
it can be released works for me!

Can you give me a hint what to search for to find the patch? I found

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

but it is just about setting regdomain from GeoClue. That's VERY
different from writing the EEPROM, the only useful solution IMO.


> we wanted to have a solution for embedded to though and APs
> neither have nor can get GPS devices on them and GeoClue is a bit
> of bloat for embedded as well. So we'll likely have to find an
> alternative solution for embedded.b

Hmm, you have "runtime" config in mind, I was more thinking of an
administrative tool that is run just once and never again, unless
the device gets moved. Yes, it needs more administration.


//Peter

[ath9k-devel] Country code setting issue

[Luis R. Rodriguez]

On Thu, Dec 9, 2010 at 9:47 PM, Peter Stuge <peter@stuge.se> wrote:
> Luis R. Rodriguez wrote:
>> >> I have considered opening up a tool that lets you do this if we can
>> >> determine your country is not US or JP by using GeoClue. I already
>> >> had some initial glue code with geoclue for iw
>> >
>> > Great idea to add this to iw!
>>
>> Patch was posted a while ago, but yeah I just have to rewrite it, but
>> Johannes also didn't seem too thrilled to have this as part of iw.
>> Perhaps its better to just have this as a separate app. Not sure.
>
> I think it would be fine to also have it in a separate app. Any way
> it can be released works for me!
>
> Can you give me a hint what to search for to find the patch? I found
>
> http://www.spinics.net/lists/linux-wireless/msg54532.html
>
> but it is just about setting regdomain from GeoClue. That's VERY
> different from writing the EEPROM, the only useful solution IMO.

Right. Like I said, baby steps, the trust worthiness of that hint is
not so accurate. We want to also use the master provider and then
request we want an accuracy within a country realm.

>> we wanted to have a solution for embedded to though and APs
>> neither have nor can get GPS devices on them and GeoClue is a bit
>> of bloat for embedded as well. So we'll likely have to find an
>> alternative solution for embedded.b
>
> Hmm, you have "runtime" config in mind, I was more thinking of an
> administrative tool that is run just once and never again, unless
> the device gets moved. Yes, it needs more administration.

Same here actually.

 Luis