On 04/12/2018 10:25 AM, solsTiCe d'Hiver wrote:
It's the second time that you (Ben and Steve) are implying that I
might break the law.

But why are you saying that ? I am not gonna repeat myself again.

If you force the NIC to use a different regulatory domain that what it
originally was tested with, then it might generate out-of-spec RF
noise on the newly available channels, and to generate invalid RF noise is
against the law in many places.

*Probably* it would be OK, but you cannot know that for certain
without some specialized RF analyzer equipment and some very detailed

And for the patch, it is also implied that I am able to write one.

Unfortunately, my opinion is that if you are unable to write one, then
you should not be mucking with the regulatory domain stuff at all.


2018-04-12 19:11 GMT+02:00 Ben Greear <gree...@candelatech.com>:
On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:


I thought I made myself clear.
I leave in France. My system(s) is/are set up to use FR as default
regulatory domain.

But when I plug in that tp-link card, I am restricted to use CN
regulatory domain. Why am I the only one to see this as a problem ?

I know that one can only have one regdom defined on the system. I have
set it up myself. So why is it changed behind my back by some card or
whatever ?
Like I said, I am left with the option, to disable crda, or to use 2
systems, one for each card !

Or may be try Windows when this is not messed up like that ??? Well,
it's not on Windows that I will be able to use monitor mode, anyway.

You can hack the ath9k-htc driver to allow over-riding the regdom
of the NIC, but that requires an out of tree patch and is probably
against the law in your country since the NIC may then not be able to
pass the regulatory requirements.


Never mind.

2018-04-12 17:52 GMT+02:00 Dan Williams <d...@redhat.com>:

On Thu, 2018-04-12 at 08:18 -0700, Steve deRosier wrote:

On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
<arend.vanspr...@broadcom.com> wrote:

On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:


This is beyond my comprehension that you could assert this is a
non issue.

Well. I am just saying that it is by design. There is no way for
regulatory code to determine where you and your hardware actually
reside so
instead it takes a conservative approach.

To say it another way: mixing regulatory domains on your host system
should result in a _smaller_ set of channels - ie only those channels
at the intersection of the two.

And another wrinkle to consider - one of the 802.11 amendments (can't
remember which one) actually causes the radio to listen to the

802.11d I believe, from the early 2000s.


around it, determine what the local regulatory domain is based on the
beacons it hears, and then lock to that regulatory domain. It's
possible for that information to be propagated up to the card's host
and the regulatory domain then would affect both cards. That's how
it's supposed to work, though I don't factually know Linux does this
in all cases.  Could it be you're somewhere where CN is the local
regulatory domain and the TL-WN722N has this feature?

In any case, as Arend points out, despite the hand-wringing that
regulatory domains cause users trying to do something particular,
between certain rules and regulations and certain manufacturers bad
interpretations and implementations around it, there's little that
be done about it. Fact is, your radio must comply to whatever
regulatory domain you are in, otherwise it's breaking the rules. And
people breaking the regulatory rules is part of what's gotten
governments to pass even worse (for us OSS guys) laws that tighten
those rules down further.

You asked who to contact. Its not the LKML - it's your relevant
government body. And certain manufacturers who improperly interpret
said rules because it's easier for them.

- Steve

Steve deRosier
Cal-Sierra Consulting LLC

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

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

Reply via email to