[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[crocket]

ath9k supports AP mode for all chipsets, but according to people
evidences, AP mode support for AR5xxx chipsets ceases to work several
minutes after the chipsets are turned into AP mode.
Below is the amazon review of AR9280.(
http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top
)

This review is from: WLAN PCI-Express Mini-Card 802.11n/a/b/g 300 Mbps
/ Atheros AR9280 / 2Tx2R MIMO

"I purchased this adapter for a custom built router/AP. The Linux
drivers would not allow the use of the 5ghz bands limiting the speed
to 130mbit.

The reason for this is the regulatory domain stored on the card does
not contain valid settings for any region. The Linux drivers respond
by disabling this functionality.

This card works great in 2.4ghz/40mhz mode, it also works fine in 5ghz
mode but requires a recompile of the drivers to disable the
restrictions placed on the card due to it's corrupted regulatory
domain."

I guess the AP mode support in ath9k is usually not fully functional
or close to non-functional.

Do you guys know the chipsets supported by ath9k that are best for AP mode?

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Peter Stuge]

crocket wrote:
> ath9k supports AP mode for all chipsets, but according to people
> evidences, AP mode support for AR5xxx chipsets ceases to work several
> minutes after the chipsets are turned into AP mode.

If you read it on the internet, it must be true.


> I guess the AP mode support in ath9k is usually not fully functional
> or close to non-functional.

I have actually had good experience from ath9k both with 5414 and
9280 using hostapd. I have severe problems with station mode, but AP
has worked well.


//Peter

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Luis R. Rodriguez]

On Wed, Feb 23, 2011 at 06:20:27AM -0800, crocket wrote:
> ath9k supports AP mode for all chipsets, but according to people
> evidences, AP mode support for AR5xxx chipsets ceases to work several
> minutes after the chipsets are turned into AP mode.
> Below is the amazon review of AR9280.(
> http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top
> )
> 
> This review is from: WLAN PCI-Express Mini-Card 802.11n/a/b/g 300 Mbps
> / Atheros AR9280 / 2Tx2R MIMO
> 
> "I purchased this adapter for a custom built router/AP. The Linux
> drivers would not allow the use of the 5ghz bands limiting the speed
> to 130mbit.
> 
> The reason for this is the regulatory domain stored on the card does
> not contain valid settings for any region. The Linux drivers respond
> by disabling this functionality.

This is false, the *truth* that some cards are programmed by the OEM / ODM
with a world regulatory domain [1] in the EEPROM. By design these are for
world roaming, so the only thing you can do on 5 GHz is to do passive scan
upon intialization. This means you won't be able to beacon because we do not
know where we are. However, cfg80211 has this thing called beacon hints [2]
which we use to lift passive scan and no-ibss (no beaconing) flags from
a device which is world roaming on some channels (non-DFS 5 GHz channels).

This information however will be cleared upon disassociation given that when
you disassociate you may be in another country. ath9k supports a notion called
virtual wiphy [3] but new patches removed this from our current development
tree given the complexity required to support it. Our goal is to eventually
address something similar but for all drivers through cfg80211 / mac80211.
I believe 2.6.38 will be the last kernel with the specific ath9k virtual
wiphy stuff so you can likely use that to propagate learned beacon hints
from one STA wiphy to another AP wiphy. cfg80211's beacon hint learning
is propagated to *all* devices, even other drivers present.

Unfortunately due to regulatory considerations which have also come under
recent stress [4] we cannot feature-wise let users overwrite their own EEPROM,
even if they know better. This is simply the state of affairs today, but
hopefully would change. The way I see it, we should be dynamicaly figuring out
our location using GPS / other trusted feeds and propagate this to 802.11
devices but current regulatory rules prohibit this.

Given that ath9k virtual wiphy is gone, you can use either 2.6.38 as I noted
or verify the EEPROM contents of a card you purchase to ensure it fits your
own country.

[1] http://wireless.kernel.org/en/users/Drivers/ath#EEPROM_world_regulatory_domain
[2] http://wireless.kernel.org/en/developers/Regulatory/processing_rules#Beacon_hints
[3] http://wireless.kernel.org/en/users/Drivers/ath9k/debug#wiphy
[4] http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains

  Luis

[ath9k-devel] Regulatory domains

[Peter Stuge]

Luis R. Rodriguez wrote:
> Unfortunately due to regulatory considerations which have also come
> under recent stress [4] we cannot feature-wise let users overwrite
> their own EEPROM, even if they know better.

I think this is good in the driver, but there was some discussion
about writing to the EEPROM from outside the driver.


> This is simply the state of affairs today, but hopefully would
> change.

That external tool for changing EEPROM contents, or at least reg
domain, would avoid punishing users, while work continues on changing
state of affairs for the future.


> The way I see it, we should be dynamicaly figuring out our location
> using GPS / other trusted feeds and propagate this to 802.11
> devices

If you exclude user input from that set of trusted feeds you just
make yourself a lot of unfriends. :\


> you can .. verify the EEPROM contents of a card you purchase to
> ensure it fits your own country.

That's ridiculous.


//Peter

[ath9k-devel] Regulatory domains

[Adrian Chadd]

Nothing's stopping someone from forking ath9k (for example) and creating
"ath9k-without-regulatory-enforcement". :-)


Adrian

On 23 February 2011 15:40, Peter Stuge <peter@stuge.se> wrote:

> Luis R. Rodriguez wrote:
> > Unfortunately due to regulatory considerations which have also come
> > under recent stress [4] we cannot feature-wise let users overwrite
> > their own EEPROM, even if they know better.
>
> I think this is good in the driver, but there was some discussion
> about writing to the EEPROM from outside the driver.
>
>
> > This is simply the state of affairs today, but hopefully would
> > change.
>
> That external tool for changing EEPROM contents, or at least reg
> domain, would avoid punishing users, while work continues on changing
> state of affairs for the future.
>
>
> > The way I see it, we should be dynamicaly figuring out our location
> > using GPS / other trusted feeds and propagate this to 802.11
> > devices
>
> If you exclude user input from that set of trusted feeds you just
> make yourself a lot of unfriends. :\
>
>
> > you can .. verify the EEPROM contents of a card you purchase to
> > ensure it fits your own country.
>
> That's ridiculous.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110223/ea52eec9/attachment.htm 

[ath9k-devel] Regulatory domains

[Luis R. Rodriguez]

On Wed, Feb 23, 2011 at 2:56 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Nothing's stopping someone from forking ath9k (for example) and creating
> "ath9k-without-regulatory-enforcement". :-)

That only will discourage companies doing the "right thing" from doing
it. We worked hard at putting in place proper regulatory rules in
place in an open way and also worked with upstream maintainers on
propagating vendor concerns over regulatory [1], we reached a decision
to put out a statement to promote respect for regulatory in the
upstream kernel and distributions [2]. We've been working on this for
*years* and have come a long way. I think the right steps to change
legislation is to prove that proper code can be supported and that
liability should shift down to the user if they purposely break
things. This can only happen with time though but I believe it is the
right step to get us to enable dynamic regulatory to be legalized.
Step by step...

I should also note that because of this position I personally at least
vouch to simply refuse to support anyone either promoting or asking
question regarding any code which purposely breaks regulatory, either
in firmware or driver. That's just my own choice, and I'd support that
even if I didn't work for a company. Its been my position all along
even prior to joining a vendor.

[1] http://wireless.kernel.org/en/vendors/VendorSupport
[2] http://wireless.kernel.org/en/developers/Regulatory/statement

  Luis

[ath9k-devel] Regulatory domains

[Peter Stuge]

Luis R. Rodriguez wrote:
> On Wed, Feb 23, 2011 at 2:56 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > Nothing's stopping someone from forking ath9k (for example) and creating
> > "ath9k-without-regulatory-enforcement". :-)
> 
> That only will discourage companies doing the "right thing" from
> doing it.

I'd agree with that. I don't think a forked driver would get much
traction, and wouldn't make it into linux-2.6.git. But I do believe
an EEPROM utility could be useful. I might look into that if noone
else does. First there's this PCI issue that I'm having fun with.


//Peter

[ath9k-devel] Regulatory domains

[Luis R. Rodriguez]

On Wed, Feb 23, 2011 at 12:40:14PM -0800, Peter Stuge wrote:
> Luis R. Rodriguez wrote:
> > Unfortunately due to regulatory considerations which have also come
> > under recent stress [4] we cannot feature-wise let users overwrite
> > their own EEPROM, even if they know better.
> 
> I think this is good in the driver, but there was some discussion
> about writing to the EEPROM from outside the driver.

We cannot take that step for a while and specifically some countries
explicitly prohibit this.

> > This is simply the state of affairs today, but hopefully would
> > change.
> 
> That external tool for changing EEPROM contents, or at least reg
> domain, would avoid punishing users,

No one is punishing users, at least intentionally, the design
philosophy assumes that when you get your 802.11 card it is
programmed correctly. This proves to be wrong at times, but
I'm just stating the facts and current industry and regulatory
assumptions.

>  while work continues on changing
> state of affairs for the future.

If regulatory agencies would allow for such tools to be distributed
and pass liability down to the user if they do this, that likely
would make it possible to release this sort of code, but its not
the case today.

> > The way I see it, we should be dynamicaly figuring out our location
> > using GPS / other trusted feeds and propagate this to 802.11
> > devices
> 
> If you exclude user input from that set of trusted feeds you just
> make yourself a lot of unfriends. :\

Regulatory agencies like the FCC have made it 100% clear that user input
cannot be supported as a feature for selecting your country, see:

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

> > you can .. verify the EEPROM contents of a card you purchase to
> > ensure it fits your own country.
> 
> That's ridiculous.

Agreed but its what we have today. In the end I believe we stand to gain
if we were able to legally change dynamically the regulatory domain, I'd
prefer to leave the user out of this, the user does not need to be involved,
and we can use new techniques to figure with close 100% realiability your
location. I do believe this will help with communications but its just the
state where we are today.

  Luis

[ath9k-devel] Regulatory domains

[Peter Stuge]

Luis R. Rodriguez wrote:
> > there was some discussion about writing to the EEPROM from
> > outside the driver.
> 
> We cannot take that step for a while and specifically some countries
> explicitly prohibit this.

I understand, and that's fine. Someone else may be able to take the
step meanwhile, in a country which does not prohibit it. :)


> > That external tool for changing EEPROM contents, or at least reg
> > domain, would avoid punishing users,
> 
> No one is punishing users, at least intentionally, the design
> philosophy assumes that when you get your 802.11 card it is
> programmed correctly. This proves to be wrong at times, but
> I'm just stating the facts and current industry and regulatory
> assumptions.

Agreed.


> > If you exclude user input from that set of trusted feeds you just
> > make yourself a lot of unfriends. :\
> 
> Regulatory agencies like the FCC have made it 100% clear that user
> input cannot be supported as a feature for selecting your country, see:
> 
> http://wireless.kernel.org/en/developers/Regulatory/CRDA#Helping_compliance_by_allowing_to_change_regulatory_domains

I did see this link, but not read the FCC opinion, because they have
no jurisdiction over me, so their opinion is not really relevant.

This becomes the discussion we already had; users will be punished
when technology must adhere to the least common denominator of all
regulatory bodies in the world.

I agree that this can only really change from within the system, and
I wouldn't be surprised if you're doing great work to that end, but
until success users in the global marketplace will continue to be
punished by local regulation, which is pretty useless from the user's
point of view.

Ie. why should I care what the FCC thinks.


> > > you can .. verify the EEPROM contents of a card you purchase to
> > > ensure it fits your own country.
> > 
> > That's ridiculous.
> 
> Agreed but its what we have today.

Yep. Let's hope it will change sometime this decade.


> the user does not need to be involved,

This isn't really the UNIX or Linux way, so I think you'll find many
that will disagree, more or less violently. :)


> we can use new techniques to figure with close 100% realiability
> your location.

Yes, sometimes. And this is great for usability when possible! I am
all for it. But other times it will not be possible so user control
is still important at least for me. Not saying it should be in kernel
though.


//Peter

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[crocket]

I am a newbie in wireless area, so I don't understand well what you
guys talk about.
I read all messages about regulatory domain.
Do those messages imply that I can't use 5Ghz frequencies in AP mode
with ath9k and AR9280?
What other chipsets supported by ath9k support AP mode reliably at
5Ghz frequencies?

On Wed, Feb 23, 2011 at 11:20 PM, crocket <crockabiscuit@gmail.com> wrote:
> ath9k supports AP mode for all chipsets, but according to people
> evidences, AP mode support for AR5xxx chipsets ceases to work several
> minutes after the chipsets are turned into AP mode.
> Below is the amazon review of AR9280.(
> http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top
> )
>
> This review is from: WLAN PCI-Express Mini-Card 802.11n/a/b/g 300 Mbps
> / Atheros AR9280 / 2Tx2R MIMO
>
> "I purchased this adapter for a custom built router/AP. The Linux
> drivers would not allow the use of the 5ghz bands limiting the speed
> to 130mbit.
>
> The reason for this is the regulatory domain stored on the card does
> not contain valid settings for any region. The Linux drivers respond
> by disabling this functionality.
>
> This card works great in 2.4ghz/40mhz mode, it also works fine in 5ghz
> mode but requires a recompile of the drivers to disable the
> restrictions placed on the card due to it's corrupted regulatory
> domain."
>
> I guess the AP mode support in ath9k is usually not fully functional
> or close to non-functional.
>
> Do you guys know the chipsets supported by ath9k that are best for AP mode?
>

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Luis R. Rodriguez]

On Wed, Feb 23, 2011 at 11:54 PM, crocket <crockabiscuit@gmail.com> wrote:
> I am a newbie in wireless area, so I don't understand well what you
> guys talk about.
> I read all messages about regulatory domain.
> Do those messages imply that I can't use 5Ghz frequencies in AP mode
> with ath9k and AR9280?
> What other chipsets supported by ath9k support AP mode reliably at
> 5Ghz frequencies?

Every card is programmed and calibrated according to the region it is
sold for. If your card is world roaming then you won't be able to use
AP mode off the bat. I explained how you can overcome this, I cannot
do a better job than my description. If your card is not world roaming
then it is fixed to a region and you will only be allowed what that
region allows you to use. So this varies by card.

  Luis

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Peter Stuge]

crocket wrote:
> Do those messages imply that I can't use 5Ghz frequencies in AP
> mode with ath9k and AR9280?

Luis R. Rodriguez wrote:
> this varies by card.

To clarify further that's the card itself, and not the chipset that
is on the card.

The chipset is capable of "everything" but because "everything" is
not legal everywhere in the world, the chipset needs to know what
parts of "everything" should be disabled so that the user is not
breaking local laws. The information about what to disable is the
regulatory domain stuff.

Reg domain is specified in multiple places, and each reg domain clue
always disables things and never enables things. It all starts with a
value that is stored in a small memory chip besides the main chipset
on the actual wireless adapter PCB.

When that memory says "world" reg domain, because the card was not
manufactured to be sold in any particular country, the chipset is
running very much dumbed-down so that it is legal regardless of which
country it will be used in, and there is no way to increase the
capabilities from software. The regulations for 2.4GHz are somewhat
similar worldwide, for 5GHz not so much.

All companies making these products are bound by law to do nothing
about this. The only thing that will work in the short term is to
let users change the reg domain in this memory on the card. No such
tool exists just yet however.

Yes, it's a bit of a mess, as always with international law.


//Peter

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Luis R. Rodriguez]

On Thu, Feb 24, 2011 at 12:20 AM, Peter Stuge <peter@stuge.se> wrote:
> crocket wrote:
>> Do those messages imply that I can't use 5Ghz frequencies in AP
>> mode with ath9k and AR9280?
>
> Luis R. Rodriguez wrote:
>> this varies by card.
>
> To clarify further that's the card itself, and not the chipset that
> is on the card.
>
> The chipset is capable of "everything" but because "everything" is
> not legal everywhere in the world, the chipset needs to know what
> parts of "everything" should be disabled so that the user is not
> breaking local laws. The information about what to disable is the
> regulatory domain stuff.
>
> Reg domain is specified in multiple places, and each reg domain clue
> always disables things and never enables things. It all starts with a
> value that is stored in a small memory chip besides the main chipset
> on the actual wireless adapter PCB.
>
> When that memory says "world" reg domain, because the card was not
> manufactured to be sold in any particular country, the chipset is
> running very much dumbed-down so that it is legal regardless of which
> country it will be used in, and there is no way to increase the
> capabilities from software. The regulations for 2.4GHz are somewhat
> similar worldwide, for 5GHz not so much.
>
> All companies making these products are bound by law to do nothing
> about this.

all said is accurate...

> The only thing that will work in the short term is to
> let users change the reg domain in this memory on the card.

Until here.

> No such
> tool exists just yet however.
>
> Yes, it's a bit of a mess, as always with international law.

If we want proper upstream drivers we essentially want to help vendors
with their considerations, and as such we need to respect regulatory
rules in upstream code. If you want to change rules then you can write
to your local congressmen, lobby up, etc. Upstream wise we want
hardware to be supported was was designed, and as best as possible,
and we take this over some hacked up crap reversed engineered driver.

  Luis

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Peter Stuge]

Luis R. Rodriguez wrote:
> > The only thing that will work in the short term is to
> > let users change the reg domain in this memory on the card.
> 
> Until here.

Should maybe have noted that I do not think such changing should
involve the driver in any way! Also, this is of course only my
opinion of what is needed for Linux wifi to be maximally useful.


> If we want proper upstream drivers we essentially want to help vendors
> with their considerations, and as such we need to respect regulatory
> rules in upstream code. If you want to change rules then you can write
> to your local congressmen, lobby up, etc. Upstream wise we want
> hardware to be supported was was designed, and as best as possible,

Completely agreed. I understand and agree that drivers can and should
not deal with changing the reg domain of cards. But I don't see a
reason for a third party to develop a tool that allows the changes.

That would make it very clear who is responsible for doing what, in
particular chipset and card vendors are not in any way involved in
activity that could potentially lead to an end user knowingly
breaking local regulation.


> and we take this over some hacked up crap reversed engineered driver.

This is a different discussion though. I'll indulge and say that I
think re-engineered software will always be as-good if not better
than fresly engineered ditto, because none of the mistakes in the
reverse engineered version will be repeated. :)


//Peter

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[crocket]

How about http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top
?
In south korea, only a few chipsets are sold, so I can't buy AR9280 or
AR9380 in my country.
I have to buy from amazon.com, and amazon sells AR9280 but not AR9380.
Is that product messed regarding regulatory domain as the reviewer
said? or has the reviewer misunderstood?


On Thu, Feb 24, 2011 at 4:54 PM, crocket <crockabiscuit@gmail.com> wrote:
> I am a newbie in wireless area, so I don't understand well what you
> guys talk about.
> I read all messages about regulatory domain.
> Do those messages imply that I can't use 5Ghz frequencies in AP mode
> with ath9k and AR9280?
> What other chipsets supported by ath9k support AP mode reliably at
> 5Ghz frequencies?
>
> On Wed, Feb 23, 2011 at 11:20 PM, crocket <crockabiscuit@gmail.com> wrote:
>> ath9k supports AP mode for all chipsets, but according to people
>> evidences, AP mode support for AR5xxx chipsets ceases to work several
>> minutes after the chipsets are turned into AP mode.
>> Below is the amazon review of AR9280.(
>> http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top
>> )
>>
>> This review is from: WLAN PCI-Express Mini-Card 802.11n/a/b/g 300 Mbps
>> / Atheros AR9280 / 2Tx2R MIMO
>>
>> "I purchased this adapter for a custom built router/AP. The Linux
>> drivers would not allow the use of the 5ghz bands limiting the speed
>> to 130mbit.
>>
>> The reason for this is the regulatory domain stored on the card does
>> not contain valid settings for any region. The Linux drivers respond
>> by disabling this functionality.
>>
>> This card works great in 2.4ghz/40mhz mode, it also works fine in 5ghz
>> mode but requires a recompile of the drivers to disable the
>> restrictions placed on the card due to it's corrupted regulatory
>> domain."
>>
>> I guess the AP mode support in ath9k is usually not fully functional
>> or close to non-functional.
>>
>> Do you guys know the chipsets supported by ath9k that are best for AP mode?
>>
>

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Peter Stuge]

crocket wrote:
> How about http://www.amazon.com/PCI-Express-Mini-Card-802-11n-Atheros-AR9280/dp/B00383YKQ6/ref=cm_cr_pr_product_top
> ?
> In south korea, only a few chipsets are sold, so I can't buy AR9280 or
> AR9380 in my country.

One solution is of course to modify the Linux kernel driver so that
it ignores the regulatory domain completely, as the reviewer
mentions, as long as you keep in mind that this may lead to you
breaking the law.


> I have to buy from amazon.com, and amazon sells AR9280 but not AR9380.

Again, the chipset is not important for this matter, only the actual
card that the chipset is mounted on, is important.


> Is that product messed regarding regulatory domain as the reviewer
> said? or has the reviewer misunderstood?

I would guess that the reviewer did not know how the reg domain stuff
works and concludes that the card is messed up simply because it
doesn't work as expected. Without seeing dmesg from the card in a
running system I'm afraid it isn't possible to say if it behaves
different from the card that you already have. :\


//Peter

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Petr Štetiar]

Peter Stuge <peter@stuge.se> [2011-02-24 10:36:35]:

> One solution is of course to modify the Linux kernel driver so that
> it ignores the regulatory domain completely, as the reviewer
> mentions, as long as you keep in mind that this may lead to you
> breaking the law.

IANAL but I think, that I'm not breaking any laws if I modify the driver in a
way, that I force the driver to use correct regulation domain of Czech
Republic, country where I live, instead of the eeprom programmed China.  Or am
I wrong?

-- ynezz

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[David Willmore]

On Thu, Feb 24, 2011 at 3:27 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> If we want proper upstream drivers we essentially want to help vendors
> with their considerations, and as such we need to respect regulatory
> rules in upstream code. If you want to change rules then you can write
> to your local congressmen, lobby up, etc. Upstream wise we want
> hardware to be supported was was designed, and as best as possible,
> and we take this over some hacked up crap reversed engineered driver.

This all assumes Part 15 use.  What about Part 97?  We're a small enough
group that noone is going to make cards specifically for us, though our use
of them is completely legal though it's hindered by the card EPROM and
the regulatory code in the kernel.

Cheers,
David

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[David Willmore]

On Thu, Feb 24, 2011 at 10:21 AM, Petr ?tetiar <ynezz@true.cz> wrote:
> IANAL but I think, that I'm not breaking any laws if I modify the driver in a
> way, that I force the driver to use correct regulation domain of Czech
> Republic, country where I live, instead of the eeprom programmed China. ?Or am
> I wrong?

If the cards EEPROM doesn't contain calibration data for the frequencies you
want to use in CZ because they weren't tested when the card was
tested/calibrated
in China, then you might still run into legal issues as the card might transmit
improperly--wrong power level, too high of a level of sideband or
harmonic signal, etc.

Cheers,
David

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Luis R. Rodriguez]

On Thu, Feb 24, 2011 at 12:48 AM, Peter Stuge <peter@stuge.se> wrote:
> Completely agreed. I understand and agree that drivers can and should
> not deal with changing the reg domain of cards. But I don't see a
> reason for a third party to develop a tool that allows the changes.
>
> That would make it very clear who is responsible for doing what, in
> particular chipset and card vendors are not in any way involved in
> activity that could potentially lead to an end user knowingly
> breaking local regulation.

This is the right way to think about such things but I'm just saying
currently this just does not suffice legall. My take on this is that:

1) Given that we do not have laws that allow such mucking around, we
have to *pave* the way so that if such things were allowed we can show
we did the best effort to prove and show that the user's is completely
aware of the modifications being made. This should not be something
that is easily done, and we should get some formal ACK from the user.
This is part of the reason why our regulatory implementation through
CRDA (which is permissive licensed and can be used by other OSes, by
design) allows modifiers / authors of new wireless-regdbs and CRDA
binaries to provide not only integrity checks but authorship checks.
The framework is designed to pave the way so that if in the future
regulatory agencies become aware of the benefit of enhancing
communication through dynamic regulatory settings we can move forward
with this easily. It also even allows for us to take this one step
further: allow central frequency brokers to figure out the best
frequencies that *should* be used within the regulatory domain and
propagate these.

2) Its silly to get the user involved given that you can just get the
location automatically through other means; a user should just use
their device, that's it. User input should be taken into
*consideration* as it is done currently in the Linux kernel, but not
trusted blindly. We should instead work on algorithms to intelligently
enhance communication in any given spectrum our radios are on.

  Luis



  Luis

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[Luis R. Rodriguez]

On Thu, Feb 24, 2011 at 7:28 AM, David Willmore <davidwillmore@gmail.com> wrote:
> On Thu, Feb 24, 2011 at 3:27 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> If we want proper upstream drivers we essentially want to help vendors
>> with their considerations, and as such we need to respect regulatory
>> rules in upstream code. If you want to change rules then you can write
>> to your local congressmen, lobby up, etc. Upstream wise we want
>> hardware to be supported was was designed, and as best as possible,
>> and we take this over some hacked up crap reversed engineered driver.
>
> This all assumes Part 15 use. ?What about Part 97? ?We're a small enough
> group that noone is going to make cards specifically for us, though our use
> of them is completely legal though it's hindered by the card EPROM and
> the regulatory code in the kernel.

Its a good question but to me the answer becomes clearer once you
consider regulatory rules for Part 97 and the design of an 802.11
device. IANAL and this is just my opinion but Part 97 *does* require
licensed operators, so, IMHO if we wanted to do best effort by the
community's part to show we did what we could to help with regulatory
considerations we could simply upstream a driver but introduce some
sort of registration page or something which would require the user to
provide their own Call sign / something to prove they are licensed for
downloading a CRDA binary / wireless-regdb which can enable them to
use a modified driver for a cheap 802.11 device re-purposed for Part
97. Key is to prevent an average user from repurposing their on
commodity radio for something they are not allowed to do. Effort along
this area which would show best effort IMHO would enable us as geeks
to pave the way for our solutions to actually become models for other
OSes and also using the spectrum as efficient as is possible. We're
years ahead of current legislation but the model we embrace, specially
if done responsibly, can help pave the way for legislation to embrace
and help us with our goals on reusing and repurposing RF hardware for
alternative means.

  Luis

[ath9k-devel] What would be the best chipset for wireless router/AP on linux?

[David Willmore]

On Thu, Feb 24, 2011 at 11:26 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Its a good question but to me the answer becomes clearer once you
> consider regulatory rules for Part 97 and the design of an 802.11
> device. IANAL and this is just my opinion but Part 97 *does* require
> licensed operators, so, IMHO if we wanted to do best effort by the
> community's part to show we did what we could to help with regulatory
> considerations we could simply upstream a driver but introduce some
> sort of registration page or something which would require the user to
> provide their own Call sign / something to prove they are licensed for
> downloading a CRDA binary / wireless-regdb which can enable them to
> use a modified driver for a cheap 802.11 device re-purposed for Part
> 97. Key is to prevent an average user from repurposing their on
> commodity radio for something they are not allowed to do. Effort along
> this area which would show best effort IMHO would enable us as geeks
> to pave the way for our solutions to actually become models for other
> OSes and also using the spectrum as efficient as is possible. We're
> years ahead of current legislation but the model we embrace, specially
> if done responsibly, can help pave the way for legislation to embrace
> and help us with our goals on reusing and repurposing RF hardware for
> alternative means.

Yes, operation under part 97 does require a license.

I agree that the average user has little valid reason to be exceeding the
restrictions of their local RF regulation.  But, there is also needs to be room
for legitimate experimentation.  For example, there seem to be a lot of
grad students on this and other wireless mailing lists--from time to time--
asking how to do some odd stuff.  Supporting (or at least not inhibiting)
the efforts of such people benefits the ath9k driver in that more people
will become involved with working on the code.  In addition, it increases
the number of people familiar with and favorable to Atheros hardware.
Look at how popular Apple has become, that is in no small part due to
their 'buying' the education market.  You know the old addage "hook'em
while they're young."

Being a radio amateur, I'm a bit invested in this discussion having a
positive outcome. ;)  I've been bitten by the 'do what the EEPROM says
to do even if it's a bad idea' problem.  Sadly, I own an intel wireless card
from europe but I live in the USA.  There are four channels I can use at
5 GHz.  At least I'm the only person in my area up there--for now.  Should
it get crowded in the future, I have nowhere to go--though I would if I had a
true USA card--or could convince the driver/firmware that I really, truely,
do live in the USA.  *sigh*

Cheers,
David