* Question on regulatory settings. @ 2014-05-22 16:50 Ben Greear 2014-05-22 17:41 ` Ben Greear 0 siblings, 1 reply; 6+ messages in thread From: Ben Greear @ 2014-05-22 16:50 UTC (permalink / raw) To: linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on regulatory settings. 2014-05-22 16:50 Question on regulatory settings Ben Greear @ 2014-05-22 17:41 ` Ben Greear 2014-05-22 18:30 ` John W. Linville 0 siblings, 1 reply; 6+ messages in thread From: Ben Greear @ 2014-05-22 17:41 UTC (permalink / raw) To: linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on regulatory settings. 2014-05-22 17:41 ` Ben Greear @ 2014-05-22 18:30 ` John W. Linville 2014-05-22 19:14 ` Rick Farina 2014-05-22 19:46 ` Ben Greear 0 siblings, 2 replies; 6+ messages in thread From: John W. Linville @ 2014-05-22 18:30 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on regulatory settings. 2014-05-22 18:30 ` John W. Linville @ 2014-05-22 19:14 ` Rick Farina 2014-05-22 19:22 ` John W. Linville 2014-05-22 19:46 ` Ben Greear 1 sibling, 1 reply; 6+ messages in thread From: Rick Farina @ 2014-05-22 19:14 UTC (permalink / raw) To: John W. Linville, Ben Greear; +Cc: linux-wireless 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on regulatory settings. 2014-05-22 19:14 ` Rick Farina @ 2014-05-22 19:22 ` John W. Linville 0 siblings, 0 replies; 6+ messages in thread From: John W. Linville @ 2014-05-22 19:22 UTC (permalink / raw) To: Rick Farina; +Cc: Ben Greear, linux-wireless 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on regulatory settings. 2014-05-22 18:30 ` John W. Linville 2014-05-22 19:14 ` Rick Farina @ 2014-05-22 19:46 ` Ben Greear 1 sibling, 0 replies; 6+ messages in thread From: Ben Greear @ 2014-05-22 19:46 UTC (permalink / raw) To: John W. Linville; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-22 19:46 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-22 16:50 Question on regulatory settings Ben Greear 2014-05-22 17:41 ` Ben Greear 2014-05-22 18:30 ` John W. Linville 2014-05-22 19:14 ` Rick Farina 2014-05-22 19:22 ` John W. Linville 2014-05-22 19:46 ` Ben Greear
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).