second wifi card enforce CN reg dom

second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

hi.

I am trying to capture on 2 channels at the same time with 2 cards.

One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
an Alfa AWUS051NH v2 using rt2800usb.

I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
reproduced the issue on a netbook using archlinux x64 too using latest
kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
too)

So when the Alfa card is used alone using the default reg dom FR, one
can change to 112 channel for example (using iw dev wlan1 set channel
112)

But once the tp-link is plugged in, reg dom seems to become CN and one
can't change the alfa card to 112 channel.

iw reg get output change from
global
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
to
global
country 98: DFS-UNSET
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(57240 - 59400 @ 2160), (N/A, 28), (N/A)
(59400 - 63720 @ 2160), (N/A, 40), (N/A)
(63720 - 65880 @ 2160), (N/A, 28), (N/A)

phy#2
country CN: DFS-FCC
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 59400 @ 2160), (N/A, 28), (N/A)
(59400 - 63720 @ 2160), (N/A, 44), (N/A)
(63720 - 65880 @ 2160), (N/A, 28), (N/A)


and all the channels above 100 are marked as disabled in iw list
output (after the plug not before) for the alfa card

It is as if the TL-WN722N has CN reg dom hard-coded and that switches
it globally to CN too ???

Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??

Re: second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

Nobody cares about this ?

Should I report this as a bug to the LKML ? or elsewhere ? to
ath9k_htc dev ? to crda dev ?

Please.

2018-04-10 21:57 GMT+02:00 solsTiCe d'Hiver <solstice.dhiver@gmail.com>:
> hi.
>
> I am trying to capture on 2 channels at the same time with 2 cards.
>
> One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
> an Alfa AWUS051NH v2 using rt2800usb.
>
> I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
> reproduced the issue on a netbook using archlinux x64 too using latest
> kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
> too)
>
> So when the Alfa card is used alone using the default reg dom FR, one
> can change to 112 channel for example (using iw dev wlan1 set channel
> 112)
>
> But once the tp-link is plugged in, reg dom seems to become CN and one
> can't change the alfa card to 112 channel.
>
> iw reg get output change from
> global
> country FR: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
> to
> global
> country 98: DFS-UNSET
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
> (59400 - 63720 @ 2160), (N/A, 40), (N/A)
> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>
> phy#2
> country CN: DFS-FCC
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
> (59400 - 63720 @ 2160), (N/A, 44), (N/A)
> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>
>
> and all the channels above 100 are marked as disabled in iw list
> output (after the plug not before) for the alfa card
>
> It is as if the TL-WN722N has CN reg dom hard-coded and that switches
> it globally to CN too ???
>
> Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

On 4/12/2018 9:00 AM, solsTiCe d'Hiver wrote:
> Nobody cares about this ?
>
> Should I report this as a bug to the LKML ? or elsewhere ? to
> ath9k_htc dev ? to crda dev ?
>
> Please.

Hi,

I do not think nobody cares, but what you describe is actually no issue 
as far as I can determine. Wifi cards are typically programmed with some 
country code and both provide that as a regulatory hint to the 
regulatory framework, which adapts to a regulatory domain in which only 
channels and power limits are set that are allowed for both devices. 
That is why some of the rules in the global set #98 are matching the FR 
set and some rules match the CN set. And because FR uses ETSI DFS and CN 
uses FCC DFS you are loosing all channels that require DFS.

Regards,
Arend

>
> 2018-04-10 21:57 GMT+02:00 solsTiCe d'Hiver <solstice.dhiver@gmail.com>:
>> hi.
>>
>> I am trying to capture on 2 channels at the same time with 2 cards.
>>
>> One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
>> an Alfa AWUS051NH v2 using rt2800usb.
>>
>> I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
>> reproduced the issue on a netbook using archlinux x64 too using latest
>> kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
>> too)
>>
>> So when the Alfa card is used alone using the default reg dom FR, one
>> can change to 112 channel for example (using iw dev wlan1 set channel
>> 112)
>>
>> But once the tp-link is plugged in, reg dom seems to become CN and one
>> can't change the alfa card to 112 channel.
>>
>> iw reg get output change from
>> global
>> country FR: DFS-ETSI
>> (2402 - 2482 @ 40), (N/A, 20), (N/A)
>> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
>> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
>> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
>> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
>> to
>> global
>> country 98: DFS-UNSET
>> (2402 - 2482 @ 40), (N/A, 20), (N/A)
>> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
>> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
>> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
>> (59400 - 63720 @ 2160), (N/A, 40), (N/A)
>> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>>
>> phy#2
>> country CN: DFS-FCC
>> (2402 - 2482 @ 40), (N/A, 20), (N/A)
>> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>> (5735 - 5835 @ 80), (N/A, 30), (N/A)
>> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
>> (59400 - 63720 @ 2160), (N/A, 44), (N/A)
>> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>>
>>
>> and all the channels above 100 are marked as disabled in iw list
>> output (after the plug not before) for the alfa card
>>
>> It is as if the TL-WN722N has CN reg dom hard-coded and that switches
>> it globally to CN too ???
>>
>> Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
> Hi.
>
> 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 the 
regulatory code to determine where you and your hardware actually reside 
so instead it takes a conservative approach.

btw. can you change the global reg back to FR using iw reg set?

Regards,
Arend

> If this is a hint, then someone should take this as a hint , and not
> enforce it blindly.
>
> I loose the capability to use a lot of channels on a card because of
> the mis-behaving of another. Or the crda framework, or whatever.
>
> What is even more stupid is that the TL-W722N is a 2.4GHz only band
> and that breaks operation on the 5GHz band of the other card.
>
> I am not even speaking about the fact that I use this in monitor mode,
> hence I will never emit anything. But anyway... crda has already
> broken everyhting even before I am entering monitor mode for the
> cards.
>
> Well, non issue... sight
>
> 2018-04-12 9:48 GMT+02:00 Arend van Spriel <arend.vanspriel@broadcom.com>:
>> On 4/12/2018 9:00 AM, solsTiCe d'Hiver wrote:
>>>
>>> Nobody cares about this ?
>>>
>>> Should I report this as a bug to the LKML ? or elsewhere ? to
>>> ath9k_htc dev ? to crda dev ?
>>>
>>> Please.
>>
>>
>> Hi,
>>
>> I do not think nobody cares, but what you describe is actually no issue as
>> far as I can determine. Wifi cards are typically programmed with some
>> country code and both provide that as a regulatory hint to the regulatory
>> framework, which adapts to a regulatory domain in which only channels and
>> power limits are set that are allowed for both devices. That is why some of
>> the rules in the global set #98 are matching the FR set and some rules match
>> the CN set. And because FR uses ETSI DFS and CN uses FCC DFS you are loosing
>> all channels that require DFS.
>>
>> Regards,
>> Arend
>>
>>
>>>
>>> 2018-04-10 21:57 GMT+02:00 solsTiCe d'Hiver <solstice.dhiver@gmail.com>:
>>>>
>>>> hi.
>>>>
>>>> I am trying to capture on 2 channels at the same time with 2 cards.
>>>>
>>>> One card is TP-Link TL-W722N v1 using ath9k_htc and the second one is
>>>> an Alfa AWUS051NH v2 using rt2800usb.
>>>>
>>>> I have tried this, first, on raspberry pi 0 W  using archlinux-arm and
>>>> reproduced the issue on a netbook using archlinux x64 too using latest
>>>> kernel and drivers. (seems to happen on ubuntu 17.10 on dell laptop
>>>> too)
>>>>
>>>> So when the Alfa card is used alone using the default reg dom FR, one
>>>> can change to 112 channel for example (using iw dev wlan1 set channel
>>>> 112)
>>>>
>>>> But once the tp-link is plugged in, reg dom seems to become CN and one
>>>> can't change the alfa card to 112 channel.
>>>>
>>>> iw reg get output change from
>>>> global
>>>> country FR: DFS-ETSI
>>>> (2402 - 2482 @ 40), (N/A, 20), (N/A)
>>>> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
>>>> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
>>>> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
>>>> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
>>>> to
>>>> global
>>>> country 98: DFS-UNSET
>>>> (2402 - 2482 @ 40), (N/A, 20), (N/A)
>>>> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
>>>> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
>>>> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
>>>> (59400 - 63720 @ 2160), (N/A, 40), (N/A)
>>>> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>>>>
>>>> phy#2
>>>> country CN: DFS-FCC
>>>> (2402 - 2482 @ 40), (N/A, 20), (N/A)
>>>> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
>>>> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
>>>> (5735 - 5835 @ 80), (N/A, 30), (N/A)
>>>> (57240 - 59400 @ 2160), (N/A, 28), (N/A)
>>>> (59400 - 63720 @ 2160), (N/A, 44), (N/A)
>>>> (63720 - 65880 @ 2160), (N/A, 28), (N/A)
>>>>
>>>>
>>>> and all the channels above 100 are marked as disabled in iw list
>>>> output (after the plug not before) for the alfa card
>>>>
>>>> It is as if the TL-WN722N has CN reg dom hard-coded and that switches
>>>> it globally to CN too ???
>>>>
>>>> Is this a bug in ath9k_htc ? a bug with the TL-WN722N card ??
>>
>>

Re: second wifi card enforce CN reg dom

[Steve deRosier]

On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>
>> Hi.
>>
>> 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 the
> 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 beacons
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 can
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
https://www.cal-sierra.com/

Re: second wifi card enforce CN reg dom

[Dan Williams]

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.vanspriel@broadcom.com> wrote:
> > On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
> > > 
> > > Hi.
> > > 
> > > 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
> > the
> > 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.

Dan

> beacons
> 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
> can
> 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
> https://www.cal-sierra.com/

Re: second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

Hi.

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.

Never mind.

2018-04-12 17:52 GMT+02:00 Dan Williams <dcbw@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.vanspriel@broadcom.com> wrote:
>> > On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>> > >
>> > > Hi.
>> > >
>> > > 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
>> > the
>> > 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.
>
> Dan
>
>> beacons
>> 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
>> can
>> 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
>> https://www.cal-sierra.com/

Re: second wifi card enforce CN reg dom

[Ben Greear]

On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:
> Hi.
>
> 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.

Thanks,
Ben

>
> Never mind.
>
> 2018-04-12 17:52 GMT+02:00 Dan Williams <dcbw@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.vanspriel@broadcom.com> wrote:
>>>> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>>>>
>>>>> Hi.
>>>>>
>>>>> 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
>>>> the
>>>> 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.
>>
>> Dan
>>
>>> beacons
>>> 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
>>> can
>>> 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
>>> https://www.cal-sierra.com/
>


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

Re: second wifi card enforce CN reg dom

[solsTiCe d'Hiver]

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.

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

2018-04-12 19:11 GMT+02:00 Ben Greear <greearb@candelatech.com>:
> On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:
>>
>> Hi.
>>
>> 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.
>
> Thanks,
> Ben
>
>
>>
>> Never mind.
>>
>> 2018-04-12 17:52 GMT+02:00 Dan Williams <dcbw@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.vanspriel@broadcom.com> wrote:
>>>>>
>>>>> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>>>>>
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> 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
>>>>> the
>>>>> 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.
>>>
>>> Dan
>>>
>>>> beacons
>>>> 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
>>>> can
>>>> 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
>>>> https://www.cal-sierra.com/
>>
>>
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

Re: second wifi card enforce CN reg dom

[Ben Greear]

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
testing.


> 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.

Thanks,
Ben

>
> 2018-04-12 19:11 GMT+02:00 Ben Greear <greearb@candelatech.com>:
>> On 04/12/2018 10:05 AM, solsTiCe d'Hiver wrote:
>>>
>>> Hi.
>>>
>>> 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.
>>
>> Thanks,
>> Ben
>>
>>
>>>
>>> Never mind.
>>>
>>> 2018-04-12 17:52 GMT+02:00 Dan Williams <dcbw@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.vanspriel@broadcom.com> wrote:
>>>>>>
>>>>>> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> 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
>>>>>> the
>>>>>> 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.
>>>>
>>>> Dan
>>>>
>>>>> beacons
>>>>> 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
>>>>> can
>>>>> 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
>>>>> https://www.cal-sierra.com/
>>>
>>>
>>
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>


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

Re: second wifi card enforce CN reg dom

[Steve deRosier]

On Thu, Apr 12, 2018 at 10:25 AM, solsTiCe d'Hiver
<solstice.dhiver@gmail.com> wrote:
> It's the second time that you (Ben and Steve) are implying that I
> might break the law.
>

No implication intended. All I said is regulatory operation is
constrained by laws in various jurisdictions. And how the unit behaves
is likely simply following the rules programmed into it for those
purposes. And, there's nothing we can do to change that.

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

If the radio only works as CN and won't let you change it, it's
probably a CN radio and is hard-coded to do that. And, the
intersection of your FR regulatory domain and the CN is what it is.
Have you plugged it in alone? And if so, can you get it on FR or does
it stay on CN?

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

It seems you are already pissed off, but could you please reply inline 
instead of top posting. Its a drag to scroll up and down.

On 4/12/2018 7:05 PM, solsTiCe d'Hiver wrote:
> Hi.
>
> 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 ?

unlikely you are the only one.

> 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 ?

so:
	Alfa = rt2800usb = FR
 > country FR: DFS-ETSI
 > (2402 - 2482 @ 40), (N/A, 20), (N/A)
 > (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
 > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
 > (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
 > (57000 - 66000 @ 2160), (N/A, 40), (N/A)
	TP-Link = ath9k_htc = CN
 >country CN: DFS-FCC
 > (2402 - 2482 @ 40), (N/A, 20), (N/A)
 > (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
 > (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
 > (5735 - 5835 @ 80), (N/A, 30), (N/A)
 > (57240 - 59400 @ 2160), (N/A, 28), (N/A)
 > (59400 - 63720 @ 2160), (N/A, 44), (N/A)
 > (63720 - 65880 @ 2160), (N/A, 28), (N/A)

The FR setting may or may not be your doing. You seem to indicate having 
done 'iw reg set FR'. So as to why it changed behind your back is 
because that card indicates it is certified to work in CN regulatory 
domain and your system is configure to work in FR domain. So the 
regulatory code in the kernel has to take action and as Steve explains 
it creates an intersection domain named '98'.

 > country 98: DFS-UNSET
 > (2402 - 2482 @ 40), (N/A, 20), (N/A)
 > (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
 > (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
 > (57240 - 59400 @ 2160), (N/A, 28), (N/A)
 > (59400 - 63720 @ 2160), (N/A, 40), (N/A)
 > (63720 - 65880 @ 2160), (N/A, 28), (N/A)

So it is not as you say that your Alfa device now operates in CN domain, 
but in the 98 domain. As you can see it creates rules different from FR 
and CN picking the lowest power of the two.

> Like I said, I am left with the option, to disable crda, or to use 2
> systems, one for each card !

So yeah, plugging multiple cards in a system limits your options, but 
you still have channels to operate in unless you are otherwise 
restricted by AP(s) used.

Regards,
Arend

Re: second wifi card enforce CN reg dom

[Arend van Spriel]

On 4/12/2018 5:52 PM, Dan Williams wrote:
> 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.vanspriel@broadcom.com> wrote:
>>> On 4/12/2018 10:42 AM, solsTiCe d'Hiver wrote:
>>>>
>>>> Hi.
>>>>
>>>> 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
>>> the
>>> 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.

Correct.

Regards,
Arend