All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: More confusion with regulatory issues.
Date: Wed, 11 Jun 2014 07:15:44 -0700	[thread overview]
Message-ID: <53986490.40702@candelatech.com> (raw)
In-Reply-To: <CAB=NE6VDr8C=2XZZhnyFKeowDMA-K05_ySw=jDS5gz4+7xs3NA@mail.gmail.com>

On 06/11/2014 02:10 AM, Luis R. Rodriguez wrote:
> On Tue, Jun 10, 2014 at 5:11 PM, Ben Greear <greearb@candelatech.com> wrote:
>> I have a Fedora 19 system with two ath10k NICs in them.  I'm not sure
>> they have any regulatory info in them at all, based on logs
>> and some poking at what firmware reports.
>>
>> I have /etc/sysconfig/regdomain set to:
>>
>> COUNTRY=US
> 
> I don't know who thought adding a sysconfig / default file with
> regdomain with a value specified would be a good idea but users should
> then just be aware that user regulatory settings *help* compliance
> further, specially with cards that have regulatory stuff designed into
> it, like ath5k, ath9k and ath10k.

Otherwise, the OS tries to use time-zone, so one way or another
it's getting user-configurables off of the disk.

My ath10k cards are pre FCC approved (beta-ish NICs), so maybe
that is why they have no regulatory info in them.

And, I'm making test gear...I'm not just trying to use my
laptop at a coffee shop.  I understand why regulatory stuff
exists, I just need to set up a specific test to try to
debug some ath10k firmware problems.

> There is one caveat too -- Atheros sells 802.11 cards to manufacturers
> and for some time and maybe still today they set the regulatory domain
> to 0x0 and override the regulatory setting in software since this is
> economically cheaper than overriding it through changing the EEPROM /
> OTP / whatever. This is actually not allowed in certain countries like
> the US and JP, and what makes this worse is that the 0x0 regulatory
> domain maps to the US on the ath module given that that is what is
> designed by Atheros for STAs so that is what we do for ath. AP
> manufacturers have the regulatory onus on them though -- so Atheros
> cannot control what they do -- they can only provide EEPROM tools,
> etc, and if folk are doing stupid things in software or using software
> to do sloppy things -- Atheros needs to educate customers that that is
> not a feature that is supported, and actually issue a bulletin on it,
> otherwise boneheads that have been doing it for a long time will not
> change.
> 
> In short don't use the userspace stuff to set the regulatory domain
> and use the OTP / EEPROM tools to set it. Setting it in software is
> not allowed explicitly at least by the US and JP. It may be allowed in
> other countries and if your country has that option you can look at
> the ath module for some kconfig options I added before leaving Atheros
> that enables some of this functionality for those countries.
> 
> Apart from all this -- the fact that you get an intersection for all
> reg hints going for US seems rather odd and should not be happening,
> specially since if a regdomain was set to US then -EALREADY should be
> issued and that regulatory domain should just be used to set onto the
> cards (if the cards had an EEPROM / OTP thing with US). Even if the
> user sets US twice, -EALREADY and the implications of it should
> happen.

I'll try the patch Janusz suggested, maybe that will fix the problem.

For what it's worth, I added a wrapper to replace /sbin/regdb and printed
out the value of COUNTRY before calling the original regdb.  On the troubled
system, it was:  00, US, US, US, US

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


      parent reply	other threads:[~2014-06-11 14:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11  0:11 More confusion with regulatory issues Ben Greear
2014-06-11  9:10 ` Luis R. Rodriguez
2014-06-11 10:34   ` Janusz Dziedzic
2014-06-11 14:31     ` Ben Greear
2014-06-11 15:48       ` Ben Greear
2014-06-11 16:31         ` Ben Greear
2014-06-11 19:24           ` Janusz Dziedzic
2014-06-23 19:33             ` Luis R. Rodriguez
2014-06-11 14:15   ` Ben Greear [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53986490.40702@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.