Question on regulatory settings.
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 19 lines · 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.
Quoted 6 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 20 lines · Ben Greear
Quoted 19 lines · 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.
Quoted 6 lines
Quoted 6 lines
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.
Quoted 2 lines
Ahh, sneaky nasty code....it was being set based on the timezone of all things!
You're welcome... ;-)
Quoted 4 lines
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
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 28 lines · John W. Linville
Quoted 20 lines · Ben Greear
Quoted 19 lines · 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.Quoted 6 lines
Quoted 6 lines
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?
Quoted 6 lines
FWIW, yes it can get this information from beacons.
Quoted 2 lines
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
Quoted 14 lines
Quoted 5 lines
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/regdomainI 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
Quoted 38 lines · Rick Farina
Quoted 28 lines · John W. Linville
Quoted 20 lines · Ben Greear
Quoted 19 lines · 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.Quoted 6 lines
Quoted 6 lines
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?
Quoted 6 lines
FWIW, yes it can get this information from beacons.
Quoted 2 lines
Ahh, sneaky nasty code....it was being set based on the timezone of all things!
You're welcome... ;-)
Quoted 7 lines
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
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 35 lines · John W. Linville
Quoted 20 lines · Ben Greear
Quoted 19 lines · 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.Quoted 6 lines
Quoted 6 lines
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.
Quoted 2 lines
Ahh, sneaky nasty code....it was being set based on the timezone of all things!
You're welcome... ;-)
Quoted 8 lines
Quoted 4 lines
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/regdomainI 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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com