Question on regulatory settings.

Question on regulatory settings.

[Ben Greear]

Hello!

I'm having issues where when we add several ath10k NICs to a system,
the regulatory domain goes quite restricted..  There is an ath9k NIC
with eeprom over-ride hack, and user-space sets regdomain to 'US'.

Later, when registering ath10k, at least one of those NICs registeres
as 'TW'.  The ending domain looks like this:

[root@lf1011-13060017 ~]# iw reg get
country 98: DFS-UNSET
	(2402 - 2472 @ 40), (N/A, 30)
	(5270 - 5330 @ 40), (N/A, 17), DFS
	(5735 - 5835 @ 80), (N/A, 30)


I tried adding a hack to ath10k to zero out the ar->ath_common.regulatory.current_rd,
but in fact it seems to be reported as zero to begin with.

I am obviously missing something.  Either my hacks to ath10k are not
sufficient, or possibly the system is getting regulatory info from
somewhere else?

Any ideas where else it might be getting the idea it should be in TW
domain?  Can it get this from beacons from other systems?

Thanks,
Ben

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

Re: Question on regulatory settings.

[Ben Greear]

On 05/22/2014 09:50 AM, Ben Greear wrote:
> Hello!
> 
> I'm having issues where when we add several ath10k NICs to a system,
> the regulatory domain goes quite restricted..  There is an ath9k NIC
> with eeprom over-ride hack, and user-space sets regdomain to 'US'.
> 
> Later, when registering ath10k, at least one of those NICs registeres
> as 'TW'.  The ending domain looks like this:
> 
> [root@lf1011-13060017 ~]# iw reg get
> country 98: DFS-UNSET
> 	(2402 - 2472 @ 40), (N/A, 30)
> 	(5270 - 5330 @ 40), (N/A, 17), DFS
> 	(5735 - 5835 @ 80), (N/A, 30)
> 
> 
> I tried adding a hack to ath10k to zero out the ar->ath_common.regulatory.current_rd,
> but in fact it seems to be reported as zero to begin with.
> 
> I am obviously missing something.  Either my hacks to ath10k are not
> sufficient, or possibly the system is getting regulatory info from
> somewhere else?
> 
> Any ideas where else it might be getting the idea it should be in TW
> domain?  Can it get this from beacons from other systems?

Ahh, sneaky nasty code....it was being set based on the timezone
of all things!

Looks like you can override this behaviour with the command
below if you are of a mind to do so:

echo COUNTRY=US > /etc/sysconfig/regdomain


Thanks,
Ben

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

Re: Question on regulatory settings.

[John W. Linville]

On Thu, May 22, 2014 at 10:41:55AM -0700, Ben Greear wrote:
> On 05/22/2014 09:50 AM, Ben Greear wrote:
> > Hello!
> > 
> > I'm having issues where when we add several ath10k NICs to a system,
> > the regulatory domain goes quite restricted..  There is an ath9k NIC
> > with eeprom over-ride hack, and user-space sets regdomain to 'US'.
> > 
> > Later, when registering ath10k, at least one of those NICs registeres
> > as 'TW'.  The ending domain looks like this:
> > 
> > [root@lf1011-13060017 ~]# iw reg get
> > country 98: DFS-UNSET
> > 	(2402 - 2472 @ 40), (N/A, 30)
> > 	(5270 - 5330 @ 40), (N/A, 17), DFS
> > 	(5735 - 5835 @ 80), (N/A, 30)
> > 
> > 
> > I tried adding a hack to ath10k to zero out the ar->ath_common.regulatory.current_rd,
> > but in fact it seems to be reported as zero to begin with.
> > 
> > I am obviously missing something.  Either my hacks to ath10k are not
> > sufficient, or possibly the system is getting regulatory info from
> > somewhere else?
> > 
> > Any ideas where else it might be getting the idea it should be in TW
> > domain?  Can it get this from beacons from other systems?

FWIW, yes it can get this information from beacons.

> Ahh, sneaky nasty code....it was being set based on the timezone
> of all things!

You're welcome... ;-)

> Looks like you can override this behaviour with the command
> below if you are of a mind to do so:
> 
> echo COUNTRY=US > /etc/sysconfig/regdomain

I don't know any better way to set a reasonable default for the
regulatory domain.  If you have other suggestions, I'd be interested
in hearing them.

Thanks,

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Question on regulatory settings.

[Rick Farina]

On 05/22/2014 02:30 PM, John W. Linville wrote:
> On Thu, May 22, 2014 at 10:41:55AM -0700, Ben Greear wrote:
>> On 05/22/2014 09:50 AM, Ben Greear wrote:
>>> Hello!
>>>
>>> I'm having issues where when we add several ath10k NICs to a system,
>>> the regulatory domain goes quite restricted..  There is an ath9k NIC
>>> with eeprom over-ride hack, and user-space sets regdomain to 'US'.
>>>
>>> Later, when registering ath10k, at least one of those NICs registeres
>>> as 'TW'.  The ending domain looks like this:
>>>
>>> [root@lf1011-13060017 ~]# iw reg get
>>> country 98: DFS-UNSET
>>> 	(2402 - 2472 @ 40), (N/A, 30)
>>> 	(5270 - 5330 @ 40), (N/A, 17), DFS
>>> 	(5735 - 5835 @ 80), (N/A, 30)
>>>
>>>
>>> I tried adding a hack to ath10k to zero out the ar->ath_common.regulatory.current_rd,
>>> but in fact it seems to be reported as zero to begin with.
>>>
>>> I am obviously missing something.  Either my hacks to ath10k are not
>>> sufficient, or possibly the system is getting regulatory info from
>>> somewhere else?
>>>
>>> Any ideas where else it might be getting the idea it should be in TW
>>> domain?  Can it get this from beacons from other systems?
> 
> FWIW, yes it can get this information from beacons.
> 
>> Ahh, sneaky nasty code....it was being set based on the timezone
>> of all things!
> 
> You're welcome... ;-)

To be fair, when I travel I rarely set my timezone at all, and when I do
I normally make sure the offset is right and not much else.  It's easily
possible to have timezone set for a country you aren't in just because
the offset matches.

I'm not saying I have a better idea, but I am saying that timezone is
very unreliable to determine position.

Thanks,
Zero_Chaos
> 
>> Looks like you can override this behaviour with the command
>> below if you are of a mind to do so:
>>
>> echo COUNTRY=US > /etc/sysconfig/regdomain
> 
> I don't know any better way to set a reasonable default for the
> regulatory domain.  If you have other suggestions, I'd be interested
> in hearing them.
> 
> Thanks,
> 
> John
> 

Re: Question on regulatory settings.

[John W. Linville]

On Thu, May 22, 2014 at 03:14:09PM -0400, Rick Farina wrote:
> 
> 
> On 05/22/2014 02:30 PM, John W. Linville wrote:
> > On Thu, May 22, 2014 at 10:41:55AM -0700, Ben Greear wrote:
> >> On 05/22/2014 09:50 AM, Ben Greear wrote:
> >>> Hello!
> >>>
> >>> I'm having issues where when we add several ath10k NICs to a system,
> >>> the regulatory domain goes quite restricted..  There is an ath9k NIC
> >>> with eeprom over-ride hack, and user-space sets regdomain to 'US'.
> >>>
> >>> Later, when registering ath10k, at least one of those NICs registeres
> >>> as 'TW'.  The ending domain looks like this:
> >>>
> >>> [root@lf1011-13060017 ~]# iw reg get
> >>> country 98: DFS-UNSET
> >>> 	(2402 - 2472 @ 40), (N/A, 30)
> >>> 	(5270 - 5330 @ 40), (N/A, 17), DFS
> >>> 	(5735 - 5835 @ 80), (N/A, 30)
> >>>
> >>>
> >>> I tried adding a hack to ath10k to zero out the ar->ath_common.regulatory.current_rd,
> >>> but in fact it seems to be reported as zero to begin with.
> >>>
> >>> I am obviously missing something.  Either my hacks to ath10k are not
> >>> sufficient, or possibly the system is getting regulatory info from
> >>> somewhere else?
> >>>
> >>> Any ideas where else it might be getting the idea it should be in TW
> >>> domain?  Can it get this from beacons from other systems?
> > 
> > FWIW, yes it can get this information from beacons.
> > 
> >> Ahh, sneaky nasty code....it was being set based on the timezone
> >> of all things!
> > 
> > You're welcome... ;-)
> 
> To be fair, when I travel I rarely set my timezone at all, and when I do
> I normally make sure the offset is right and not much else.  It's easily
> possible to have timezone set for a country you aren't in just because
> the offset matches.
> 
> I'm not saying I have a better idea, but I am saying that timezone is
> very unreliable to determine position.

Yes, but no less reliable than nothing at all.  And if you _do_
set it properly, so much the better.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Question on regulatory settings.

[Ben Greear]

On 05/22/2014 11:30 AM, John W. Linville wrote:
> On Thu, May 22, 2014 at 10:41:55AM -0700, Ben Greear wrote:
>> On 05/22/2014 09:50 AM, Ben Greear wrote:
>>> Hello!
>>>
>>> I'm having issues where when we add several ath10k NICs to a system,
>>> the regulatory domain goes quite restricted..  There is an ath9k NIC
>>> with eeprom over-ride hack, and user-space sets regdomain to 'US'.
>>>
>>> Later, when registering ath10k, at least one of those NICs registeres
>>> as 'TW'.  The ending domain looks like this:
>>>
>>> [root@lf1011-13060017 ~]# iw reg get
>>> country 98: DFS-UNSET
>>> 	(2402 - 2472 @ 40), (N/A, 30)
>>> 	(5270 - 5330 @ 40), (N/A, 17), DFS
>>> 	(5735 - 5835 @ 80), (N/A, 30)
>>>
>>>
>>> I tried adding a hack to ath10k to zero out the ar->ath_common.regulatory.current_rd,
>>> but in fact it seems to be reported as zero to begin with.
>>>
>>> I am obviously missing something.  Either my hacks to ath10k are not
>>> sufficient, or possibly the system is getting regulatory info from
>>> somewhere else?
>>>
>>> Any ideas where else it might be getting the idea it should be in TW
>>> domain?  Can it get this from beacons from other systems?
> 
> FWIW, yes it can get this information from beacons.
> 
>> Ahh, sneaky nasty code....it was being set based on the timezone
>> of all things!
> 
> You're welcome... ;-)
> 
>> Looks like you can override this behaviour with the command
>> below if you are of a mind to do so:
>>
>> echo COUNTRY=US > /etc/sysconfig/regdomain
> 
> I don't know any better way to set a reasonable default for the
> regulatory domain.  If you have other suggestions, I'd be interested
> in hearing them.

It would be nice to have something in the logs detailing the source/reason
of the configuration setting.  I mostly got lucky when searching for
the problem...even with adding a WARN_ON(1) in the kernel to catch
it, you only see that 'iw' made the change...hard to know what called iw.

I don't have a better suggestion for default config, except that maybe
if it were manually set with 'iw' already then you would not set it
again based on the timezone.  That probably wouldn't have helped me
anyway since the automated thing will be faster than any normal user,
though.

Thanks,
Ben



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