ath9k bug in country domain handling
Quoted 6 lines · Erwin Van de Velde
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
Quoted 19 lines · On Sunday 17 June 2012 20:16:21 Xose Vazquez Perez wrote:
Quoted 6 lines · Erwin Van de Velde
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
Quoted 3 lines
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
Quoted 10 lines · Erwin Van de Velde
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: 0x3aAs 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.
Quoted 7 lines
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!!!
Hi Erwin,
Quoted 9 lines · Erwin Van de Velde
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
Quoted 5 lines
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)
Quoted 5 lines
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,
Signature · 5 lines
Julian Calaby Email: [email protected] Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/
Quoted 4 lines · Julian Calaby
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
Hi Xose,
Quoted 8 lines · Xose Vazquez Perez
Quoted 4 lines · Julian Calaby
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.
Quoted 4 lines
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.
Quoted 5 lines
<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.
Quoted 1 line
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,
Signature · 5 lines
Julian Calaby Email: [email protected] Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/