[ath9k-devel] Ath9k: changing regulatory domain

[Adrien Decostre]

Hello all,

I am quite new to the ath9k driver and I am currently trying to use this
driver for an access point on the 5GHz band.

The problem is that my card has a regulation domain set to WORA_WORLD 0x6A
which prevents the card to do active probing on any 5GHz channel. I tried
setting different country codes but this does not improve the situation, so
I suspect that the limitation comes from the regulatory domain.

So I am now looking to a way to adapt the reg_domain on the EEPROM of the
Wifi card. On some posts, I found references to the ath_info tool to modify
the reg_domain on the EEPROM but I did not even manage to install this tool
yet.

So, would someone know any other method to adapt the reg_domain?

Thanks in advance for any answers or advices.

Best regards

[Luis R. Rodriguez]

Post by Adrien Decostre
Hello all,
I am quite new to the ath9k driver and I am currently trying to use this
driver for an access point on the 5GHz band.
The problem is that my card has a regulation domain set to WORA_WORLD 0x6A
which prevents the card to do active probing on any 5GHz channel. I tried
setting different country codes but this does not improve the situation, so I
suspect that the limitation comes from the regulatory domain.
So I am now looking to a way to adapt the reg_domain on the EEPROM of the
Wifi card. On some posts, I found references to the ath_info tool to modify
the reg_domain on the EEPROM but I did not even manage to install this tool
yet.
So, would someone know any other method to adapt the reg_domain?
Thanks in advance for any answers or advices.

Changing your EEPROM is not allowed by regulatory agencies and may require
you to recalibrate your card to conform to different regulatory domains (CTLS).
Because of this this is not something we support today for the end user to do.

Luis

[Peter Stuge]

Post by Luis R. Rodriguez

Post by Adrien Decostre
I am quite new to the ath9k driver and I am currently trying to
use this driver for an access point on the 5GHz band.
The problem is that my card has a regulation domain set to
WORA_WORLD 0x6A which prevents the card to do active probing on
any 5GHz channel.

..

Post by Luis R. Rodriguez
Changing your EEPROM is not allowed by regulatory agencies

It is not allowed by *some* regulatory agencies. So far I've been
told that this is USA and Japan.

It's stupid, so personally I would have no problem changing the
EEPROM regulatory domain regardless.

Post by Luis R. Rodriguez
and may require you to recalibrate your card to conform to
different regulatory domains (CTLS).

This is an important piece of the puzzle. If the card doesn't have
calibration data for 5GHz I guess it might actually not be useful
even if the EEPROM reg domain is changed.

Post by Luis R. Rodriguez
Because of this this is not something we support today for the end user to do.

I think that's very understandable. But we users in the community can
of course experiment at our own risk. It would be interesting to get
into the details of calibration. I think a first step is to start
looking at if and how cards with more restricted reg domains in
EEPROM are calibrated for the restricted spectrum.


//Peter

[Adrian Chadd]

Post by Peter Stuge
It is not allowed by *some* regulatory agencies. So far I've been
told that this is USA and Japan.
It's stupid, so personally I would have no problem changing the
EEPROM regulatory domain regardless.

Post by Luis R. Rodriguez
and may require you to recalibrate your card to conform to
different regulatory domains (CTLS).

This is an important piece of the puzzle. If the card doesn't have
calibration data for 5GHz I guess it might actually not be useful
even if the EEPROM reg domain is changed.
I think that's very understandable. But we users in the community can
of course experiment at our own risk. It would be interesting to get
into the details of calibration. I think a first step is to start
looking at if and how cards with more restricted reg domains in
EEPROM are calibrated for the restricted spectrum.

Well, a non-5ghz card won't have 5ghz data in it.

The channel edges can be investigated by perusing the eeprom data - ctlIndex
and ctlData. You can then see what the TX power calibration code is doing in
those areas.

There's some more subtle things though, especially for 5ghz where the range
of frequencies differs quite a bit. In 2ghz mode, there's only a couple of
channels either side of the range which are/aren't allowed based on where
you are, but 5ghz frequencies are a lot more varied.

There's calibration data programmed into the card which control the actual
TX power curve (and power amplifier biases for the AR9160) for a given
frequency; and it's possible that your card won't have information for the
whole possible range of 5ghz frequencies. The driver code interpolates all
of the TX power calibration curve values (and their equivalent when doing
open-loop TX calibration, just to be complete here) and these interpolated
values may be very wrong if the card frequency is too far away from what's
been calibrated.

The same is true for 2ghz but the cards I've seen have calibration data for
say, channels 1, 6 and 11; the relevant code just interpolates between those
as needed. Channel 13 in Japan would likely also be calibrated, but I don't
have a Japan 2ghz card to see.

The only way to check is to hook it up to a spectrum analyser and check. You
may be distorting without even knowing it. :-)


Adrian

[Adrien Decostre]

Adrian, Peter and Luis,

Thanks for your answers.

Just 1 more question for curiosity.
Would it be more acceptable by regulatory agencies to specify the reg_domain
to use when loading the driver?

For example, in "ath_reg_init", the reg_domain would be hard-coded (this was
just a quick test to see how it works):
reg->current_rd=ETSI1_WORLD

There is nothing changed in the EEPROM so I don't think this would break the
module certification.

Best regards

Post by Adrian Chadd

Post by Peter Stuge
It is not allowed by *some* regulatory agencies. So far I've been
told that this is USA and Japan.
It's stupid, so personally I would have no problem changing the
EEPROM regulatory domain regardless.

Post by Luis R. Rodriguez
and may require you to recalibrate your card to conform to
different regulatory domains (CTLS).

This is an important piece of the puzzle. If the card doesn't have
calibration data for 5GHz I guess it might actually not be useful
even if the EEPROM reg domain is changed.
I think that's very understandable. But we users in the community can
of course experiment at our own risk. It would be interesting to get
into the details of calibration. I think a first step is to start
looking at if and how cards with more restricted reg domains in
EEPROM are calibrated for the restricted spectrum.

Well, a non-5ghz card won't have 5ghz data in it.
The channel edges can be investigated by perusing the eeprom data -
ctlIndex and ctlData. You can then see what the TX power calibration code is
doing in those areas.
There's some more subtle things though, especially for 5ghz where the range
of frequencies differs quite a bit. In 2ghz mode, there's only a couple of
channels either side of the range which are/aren't allowed based on where
you are, but 5ghz frequencies are a lot more varied.
There's calibration data programmed into the card which control the actual
TX power curve (and power amplifier biases for the AR9160) for a given
frequency; and it's possible that your card won't have information for the
whole possible range of 5ghz frequencies. The driver code interpolates all
of the TX power calibration curve values (and their equivalent when doing
open-loop TX calibration, just to be complete here) and these interpolated
values may be very wrong if the card frequency is too far away from what's
been calibrated.
The same is true for 2ghz but the cards I've seen have calibration data for
say, channels 1, 6 and 11; the relevant code just interpolates between those
as needed. Channel 13 in Japan would likely also be calibrated, but I don't
have a Japan 2ghz card to see.
The only way to check is to hook it up to a spectrum analyser and check.
You may be distorting without even knowing it. :-)
Adrian
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[Adrian Chadd]

Again from what I understand the problem is, is that the channels that have
been calibrated (including the channel edges and per-frequency TX power
limits) may be specific to the regulatory domain.

I can't really say much more without spending more time surveying various
NICs (including the increasing number I have here) and see exactly what the
story is. But without adequate research, I can't really say with authority
what is/isn't going on. I can just say what -may- be going on.

HTH,



Adrian

Post by Adrien Decostre
Adrian, Peter and Luis,
Thanks for your answers.
Just 1 more question for curiosity.
Would it be more acceptable by regulatory agencies to specify the
reg_domain to use when loading the driver?
For example, in "ath_reg_init", the reg_domain would be hard-coded (this
reg->current_rd=ETSI1_WORLD
There is nothing changed in the EEPROM so I don't think this would break
the module certification.
Best regards

Post by Adrian Chadd

Post by Peter Stuge
It is not allowed by *some* regulatory agencies. So far I've been
told that this is USA and Japan.
It's stupid, so personally I would have no problem changing the
EEPROM regulatory domain regardless.

Post by Luis R. Rodriguez
and may require you to recalibrate your card to conform to
different regulatory domains (CTLS).

This is an important piece of the puzzle. If the card doesn't have
calibration data for 5GHz I guess it might actually not be useful
even if the EEPROM reg domain is changed.
I think that's very understandable. But we users in the community can
of course experiment at our own risk. It would be interesting to get
into the details of calibration. I think a first step is to start
looking at if and how cards with more restricted reg domains in
EEPROM are calibrated for the restricted spectrum.

Well, a non-5ghz card won't have 5ghz data in it.
The channel edges can be investigated by perusing the eeprom data -
ctlIndex and ctlData. You can then see what the TX power calibration code is
doing in those areas.
There's some more subtle things though, especially for 5ghz where the
range of frequencies differs quite a bit. In 2ghz mode, there's only a
couple of channels either side of the range which are/aren't allowed based
on where you are, but 5ghz frequencies are a lot more varied.
There's calibration data programmed into the card which control the actual
TX power curve (and power amplifier biases for the AR9160) for a given
frequency; and it's possible that your card won't have information for the
whole possible range of 5ghz frequencies. The driver code interpolates all
of the TX power calibration curve values (and their equivalent when doing
open-loop TX calibration, just to be complete here) and these interpolated
values may be very wrong if the card frequency is too far away from what's
been calibrated.
The same is true for 2ghz but the cards I've seen have calibration data
for say, channels 1, 6 and 11; the relevant code just interpolates between
those as needed. Channel 13 in Japan would likely also be calibrated, but I
don't have a Japan 2ghz card to see.
The only way to check is to hook it up to a spectrum analyser and check.
You may be distorting without even knowing it. :-)
Adrian
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[Peter Stuge]

Post by Adrien Decostre
Would it be more acceptable by regulatory agencies to specify the
reg_domain to use when loading the driver?

I can just guess. I think this could keep you safe wrt. modifying the
hardware, but as Adrian explained there is still a risk that
calibration data for the channels that you have "unlocked" is so
wrong that the hardware will violate emission regulations.


//Peter

[Larry Vaden]

Post by Peter Stuge

Post by Adrien Decostre
Would it be more acceptable by regulatory agencies to specify the
reg_domain to use when loading the driver?

I can just guess. I think this could keep you safe wrt. modifying the
hardware, but as Adrian explained there is still a risk that
calibration data for the channels that you have "unlocked" is so
wrong that the hardware will violate emission regulations.

Peter and Adrian,

If this post is essentially asking to peek behind Atheros' kimono,
please disregard this post.

Is there any chance that the only diff between any two units is likely
to be the mac address and the regdomain?

IOW, do we know for certain whether the entire set of data required
for compliance in every country is stored on each and every chip?

kind regards/ldv

[Peter Stuge]

Hi Larry,

Post by Larry Vaden
Is there any chance that the only diff between any two units is
likely to be the mac address and the regdomain?

There's a chance, but I don't know how likely it is. I guess it
depends on how close a given adapter design is to the reference
design provided by Atheros. Also I think it depends on the workflow
for the adapter designers wrt. to the EEPROM. Ie. I could imagine
that there is a reference design with suggested calibration data, but
I also expect that simply manufacturing that design with zero changes
in two different production plants may give slightly different
behavior from the units.

Post by Larry Vaden
IOW, do we know for certain whether the entire set of data required
for compliance in every country is stored on each and every chip?

Nope. This is what I meant would be good to gather information about,
with a tool that can preferably also decode EEPROM contents.


//Peter

[Larry Vaden]

Post by Peter Stuge
I could imagine
that there is a reference design with suggested calibration data, but
I also expect that simply manufacturing that design with zero changes
in two different production plants may give slightly different
behavior from the units.

Hi Peter,

I know there's a possibility that you have used up most of your clue
sticks before I came on the OpenWrt scene and your reorder is yet to
arrive, but if you've got one more clue stick, please hit me with it
and help me understand.

e.g., are you talking about variances in an analog portion of the
radio that might occur at two different production plants?

kind regarads/ldv

[Peter Stuge]

Post by Larry Vaden

Post by Peter Stuge
I also expect that simply manufacturing that design with zero changes
in two different production plants may give slightly different
behavior from the units.

(I don't know if the difference would be big enough to actually be
significant though.)

Post by Larry Vaden
e.g., are you talking about variances in an analog portion of the
radio that might occur at two different production plants?

Right, e.g. different methods or materials while fabricate the PCBs
would give different results, maybe to the point where calibration
data would be needed, maybe not. I don't know the details of the
calibration at all. It could also be much more coarse, in which case
we eager EEPROM patchers would be in much better shape. :)


//Peter

[Larry Vaden]

Post by Peter Stuge
I don't know the details of the
calibration at all. It could also be much more coarse, in which case
we eager EEPROM patchers would be in much better shape. :)

Perhaps, at least for Ubiquiti radios, Country Code "Compliance Test"
is what some might be looking for?

[Larry Vaden]

Post by Peter Stuge
I don't know the details of the
calibration at all. It could also be much more coarse, in which case
we eager EEPROM patchers would be in much better shape. :)

Peter, now that I've had more time to think about it, MikroTik treats
the issue as a revenue enhancement called a Super Channel license.

[Larry Vaden]

Post by Peter Stuge

Post by Larry Vaden
IOW, do we know for certain whether the entire set of data required
for compliance in every country is stored on each and every chip?

Nope. This is what I meant would be good to gather information about,
with a tool that can preferably also decode EEPROM contents.

I know that Ubiquiti radios have a Country Code selection available
called "Compliance Test" which, per my best guess, is essentially an
out-out filter on available frequencies and my guess is therefore that
the data for all countries is available, I dunno.

regards/ldv

[Adrian Chadd]

Post by Larry Vaden
Peter and Adrian,
If this post is essentially asking to peek behind Atheros' kimono,
please disregard this post.
Is there any chance that the only diff between any two units is likely
to be the mac address and the regdomain?
IOW, do we know for certain whether the entire set of data required
for compliance in every country is stored on each and every chip?

No idea. I'm just saying I don't know for certain. I have EEPROM dumps, I've
just not sat down and investigated that.

As Luis has said however, the US (and Japan?) regdomain requires that card
domains aren't modified. I don't understand the exactness of the situation,
but as I've said, it's likely that merely ignoring/overriding the regdomain
is grounds for breaking the rules.



Adrian

[Larry Vaden]

Post by Adrian Chadd

Post by Larry Vaden
Peter and Adrian,
If this post is essentially asking to peek behind Atheros' kimono,
please disregard this post.
Is there any chance that the only diff between any two units is likely
to be the mac address and the regdomain?
IOW, do we know for certain whether the entire set of data required
for compliance in every country is stored on each and every chip?

No idea. I'm just saying I don't know for certain. I have EEPROM dumps, I've
just not sat down and investigated that.
As Luis has said however, the US (and Japan?) regdomain requires that card
domains aren't modified. I don't understand the exactness of the situation,
but as I've said, it's likely that merely ignoring/overriding the regdomain
is grounds for breaking the rules.

Adrian,

Me thinks a lot of our differences in point of view is that, IIRC, you
use the miniPCI cards in your development work and we have used the
integrated units since 2006.

Further, one who immediately loads 3rd party firmware onto an
integrated unit may miss this:

<http://www.ubnt.com/wiki/AirOS_5.3> says, in part:

[quote]
Country Code: Different countries will have different power levels and
possible frequency selections. To ensure device operation follows
regulatory compliance rules, please make sure to select your correct
country where the device will be used. The channel list, output power
limits, IEEE 802.11 and Channel Spectrum Width modes will be tuned
according to the regulations of the selected country. Additionally,
please consult the compliance guide for further explanation of
international compliance requirements.
[/quote]

IMHO, said devices are mostly a reference design provided by Atheros.

Remember me trying to say here a couple a weeks ago something about
"guilt by association." One can't take on the country code of the AP
one is associating with and be certain that one is in compliance.

kind regards/ldv

[Adrien Decostre]

Peter, Adrian,

Thanks a lot for these fast answers and important precisions about this
calibration issue.

Best regards

Post by Peter Stuge

Post by Adrien Decostre
Would it be more acceptable by regulatory agencies to specify the
reg_domain to use when loading the driver?

I can just guess. I think this could keep you safe wrt. modifying the
hardware, but as Adrian explained there is still a risk that
calibration data for the channels that you have "unlocked" is so
wrong that the hardware will violate emission regulations.
//Peter
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel