On Thu, Apr 12, 2018 at 3:51 AM, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> 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/
