Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 891018 - regulatory domain no longer get set
Summary: regulatory domain no longer get set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: crda
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-31 23:40 UTC by Hin-Tak Leung
Modified: 2014-07-16 15:58 UTC (History)
6 users (show)

Fixed In Version: crda-1.1.3_2013.11.27-4.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-04 06:43:16 UTC


Attachments (Terms of Use)
output of set -x /sbin/setregdomain (deleted)
2014-02-18 19:51 UTC, Hin-Tak Leung
no flags Details

Description Hin-Tak Leung 2012-12-31 23:40:43 UTC
Description of problem:
since upgraded to F18 (almost 10 days ago), I just noticed that my regulatory domain no longer get get to GB - now it defaults to world. 

Version-Release number of selected component (if applicable):
crda-1.1.2_2011.04.28-3.fc18.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Just boot up, watch dmesg
2.
3.
  
Actual results:
Only:
[29839.573489] cfg80211: Calling CRDA to update world regulatory domain
[29840.292326] cfg80211: World regulatory domain updated:
...

Expected results:
Should show:
[32275.315375] cfg80211: Calling CRDA for country: GB
[32277.522811] cfg80211: Regulatory domain changed to country: GB

Additional info:
first line of: /etc/wpa_supplicant/wpa_supplicant.conf 
COUNTRY=GB

calling crda always fails:
# COUNTRY=GB crda
Failed to set regulatory domain: -22

but doing so via iw works:
# iw reg set GB
[32275.315375] cfg80211: Calling CRDA for country: GB

After setting via iw, it fails with a different error:
# COUNTRY=GB crda
Failed to set regulatory domain: -114

BTW, the error message is very unhelpful... anyway, I started looking at this only because I have an kernel WARNING after suspend/resume, which is more serious and I'll file.

Comment 1 Hin-Tak Leung 2013-01-01 00:00:28 UTC
The last f17 kernel I booted, with mostly f17 bits, 3.6.10-2.fc17.x86_64, seems to set the regulatory domain correctly.

Comment 2 John W. Linville 2013-01-02 20:46:03 UTC
Which kernel version is it that is failing?

Comment 3 Hin-Tak Leung 2013-01-02 22:24:31 UTC
was 3.6.11-3.fc18.x86_64 . But regulatory domain does not appear to have get set since I upgraded to f18, which means all of these:

3.6.9-4.fc18.x86_64
3.6.10-5.fc18.x86_64
3.6.11-3.fc18.x86_64

(as well as the 3.6.10-2.fc17.x86_64 3.6.9-2.fc17.x86_64 which I tried to look at the suspend/resume problem).

Comment 4 Edouard Bourguignon 2013-01-04 07:58:50 UTC
I put the COUNTRY=XX in the /etc/sysconfig/network-scripts/ifcfg-Auto_SSID which is created by NetworkManager I guess. It works here on 3.6.10-4.fc18.x86_64.

Comment 5 Hin-Tak Leung 2013-01-05 01:05:48 UTC
(In reply to comment #4)
> I put the COUNTRY=XX in the /etc/sysconfig/network-scripts/ifcfg-Auto_SSID
> which is created by NetworkManager I guess. It works here on
> 3.6.10-4.fc18.x86_64.

None of my /etc/sysconfig/network-scripts/ifcfg-Auto_* have COUNTRY=... inside; AFAIK I only have in /etc/wpa_supplicant/wpa_supplicant.conf a COUNTRY=GB line, and I don't remember how it got there - it has been that way for years.

Anyway, I see two issues:

- COUNTRY=XX crda  should work according to the documentation but it does not,

- from the dozen /etc/sysconfig/network-scripts/ifcfg-Auto_* I have over the years - various hotels and other locations in UK, Belgium, US, France, China, Hong Kong, - I see that the regulatory domain should indeed be a per SSID setting, rather than a per device setting. So it seems that I have always had it set in the wrong place :-(. So it would appear that the F17 behavior was wrong, and F18 is correct to ignore per-device settings - it should be a per SSID setting. (I don't remember NetworkManager ever asked what country am in, when I try to get a hotel's etc SSID is, though!).

Comment 6 John W. Linville 2013-01-07 15:00:20 UTC
The ways this was designed to work in Fedora was for /sbin/setregdomain to be run by /usr/lib/udev/rules.d/85-regulatory.rules (i.e. by udev).  I haven't got an F18 box here, so I apologize if I'm unaware of what might have changed.

If you run /sbin/setregdomain, does that set the regulatory domain?  Or does it produce any output?  Do you have an /etc/sysconfig/clock or /etc/sysconfig/regdomain file?

The idea of setregdomain is to use your timezone setting to deduce your regulatory domain, or to let you override that with the regdomain file.  I know that systemd has changed lots of things, so maybe setregdomain needs to rely on something else for that info now...?

Comment 7 Kay Sievers 2013-01-07 15:59:31 UTC
I don't know about any specific changes here. But /etc/sysconfig/clock
is no longer used by the glibc rpm logic, the file should not exist on
recent systems.

It's not really related to systemd, in general the actual timezone should
be determined by reading the /etc/localtime symlink, the data glibc
actually uses on the system. It's more reliablethan making guesses about
distribution specific and possibly outdated config files and data.

Comment 8 John W. Linville 2013-01-07 18:29:50 UTC
OK, it looks like you are talking about the same thing as in bug 858735.  It looks like there should now be an /etc/timezone file with the info I was getting from /etc/sysconfig/clock...?

I built a test crda package, with an updated setregdomain script:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4846315

Could someone give that a try and post the results here?  Thanks!

Comment 9 Kay Sievers 2013-01-07 18:38:07 UTC
There is no /etc/timezone file. It was considered for a while, but the
idea dropped, as it is just another source of duplication and possible
outdated and irrelevant data.

Glibc reads only /etc/localtime, so today it is all encoded just in the
target of the symlink of /etc/localtime. It always reflects what the
system actually uses, not some "dead" data in distribution configuration.

(On older systems /etc/localtime could be a copy of the zoneinfo file,
and not a neccessarily a symlink, but we enforce the symlink format now)

Comment 10 John W. Linville 2013-01-07 19:55:26 UTC
OK, I was hoping to limit the ugliness of the hack that is setregdomain... :-)

Please disregard the build from comment 8.  Please test this one instead:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4846715

Note that I was too lazy to change the version between those scratch builds.  So, please be sure that you are using the correct version when testing!

Comment 11 Hin-Tak Leung 2013-01-07 20:34:39 UTC
(In reply to comment #10)
> OK, I was hoping to limit the ugliness of the hack that is setregdomain...
> :-)
> 
> Please disregard the build from comment 8.  Please test this one instead:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4846715
> 
> Note that I was too lazy to change the version between those scratch builds.
> So, please be sure that you are using the correct version when testing!

setting by hand still does not work: (is it supposed to? the man page seems to imply it should - maybe the doc needs to be updated)

# COUNTRY=GB crda
Failed to set regulatory domain: -114
# COUNTRY=US crda
Failed to set regulatory domain: -22

But just suspending/resuming now set the regulatory domain to GB for me, so that's an improvement; I suppose this would apply to reboot also.

Comment 12 Hin-Tak Leung 2013-01-08 00:55:33 UTC
(In reply to comment #6)
<snipped>
> If you run /sbin/setregdomain, does that set the regulatory domain?  Or does
> it produce any output?  Do you have an /etc/sysconfig/clock or
> /etc/sysconfig/regdomain file?
<snipped>

I have neither /etc/sysconfig/clock  nor /etc/sysconfig/regdomain . 

/etc/localtime is sym-linked to ../usr/share/zoneinfo/Europe/London

"/etc/timezone" does not exist either.

/sbin/setregdomain would have worked (I haven't tried, since since suspend/resume to trigger the udev rule does it), from using /etc/localtime . It is just curious and confusing that "iw reg set XX" works on the command line but "COUNTRY=XX crda" does not.

Comment 13 John W. Linville 2013-11-22 19:38:55 UTC
I'm not sure what is left to be done here.  It seems like if this were a general problem then there would be a lot more complaining?

I'm going to close this for now...

Comment 14 Hin-Tak Leung 2014-02-17 22:08:13 UTC
Just noticed this problem coming back (possibly with upgrading to fc20 over Christmas?)

# rpm -qf /sbin/setregdomain
crda-1.1.3_2013.02.13-4.fc20.x86_64

# rpm -qf /usr/share/zoneinfo/zone.tab
tzdata-2013i-2.fc20.noarch

no /etc/sysconfig/regdomain, /etc/localtime symlink to London.

# ls -l /etc/localtime
lrwxrwxrwx. 1 root root 35 Dec 22  2012 /etc/localtime -> ../usr/share/zoneinfo/Europe/London
# ls -l /etc/sysconfig/regdomain
ls: cannot access /etc/sysconfig/regdomain: No such file or directory

# /sbin/setregdomain
Could not determine country!  Unable to set regulatory domain.

I don't have any logs beyond 4 weeks, but grep through says it has always been 'world regulatory domain' for at least a month.

Comment 15 John W. Linville 2014-02-18 16:06:29 UTC
There was a typo in setregdomain that may be causing this for you.  Please update to crda-1.1.3_2013.11.27-3.fc20.x86_64 when it becomes available.  Or, install it from Koji:

http://koji.fedoraproject.org/koji/buildinfo?buildID=493391

Does that resolve the issue?

Comment 16 Hin-Tak Leung 2014-02-18 19:04:17 UTC
(In reply to John W. Linville from comment #15)
> Does that resolve the issue?

No.

[root@localhost ~]# rpm -q crda
crda-1.1.3_2013.11.27-3.fc20.x86_64
[root@localhost ~]# /sbin/setregdomain
Could not determine country!  Unable to set regulatory domain.

Comment 17 John W. Linville 2014-02-18 19:32:00 UTC
It's working here.  Please add a 'set -x' line near the top of /sbin/setregdomain, run it again, and post the output here...thanks!

Comment 18 Hin-Tak Leung 2014-02-18 19:51:23 UTC
Created attachment 864763 [details]
output of set -x /sbin/setregdomain

Output of
/sbin/setregdomain >& /tmp/1
after adding set -x near the top.

Comment 19 John W. Linville 2014-02-18 20:10:10 UTC
I've had similar reports from some users in bug 806221.  I'm not sure what /etc/localtime is a relative path link on some systems but a direct path link on others.

Comment 20 Hin-Tak Leung 2014-02-18 20:38:30 UTC
The symlink is quite old, but not as old as the machine itself - it is the same machine since 2008 so had gone through a few upgrades. I don't think I created that by hand.

# ls -ld /etc/localtime
lrwxrwxrwx. 1 root root 35 Dec 22  2012 /etc/localtime -> ../usr/share/zoneinfo/Europe/London

I just checked the date is a few weeks before fc18. I think I may have been impatient and upgraded to fc18 rcX when I upgraded from fc 17. (fc18 was delayed for rather longer than usual).

Comment 21 Fabrice Allibe 2014-02-21 07:07:28 UTC
Hello,

symlink is still created "relative" with f20 installer for sure, as I did not update it manually on a brand new fresh install.

I reported this issue through https://bugzilla.redhat.com/show_bug.cgi?id=806221 along with another bug inside setregdomain.

Since latest crda-1.1.3_2013.11.27-3.fc20 fix does not handle localtime with relative symlink, the bug is still there.

Comment 22 John W. Linville 2014-02-28 20:48:01 UTC
The Gnome3 Date & Time app seems to use the relative pathnames for the /etc/localtime symlink too.  That seems really wierd to me, but whatever...

Comment 23 Fedora Update System 2014-02-28 21:08:04 UTC
crda-1.1.3_2013.11.27-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/crda-1.1.3_2013.11.27-4.fc20

Comment 24 Fedora Update System 2014-03-01 14:14:09 UTC
Package crda-1.1.3_2013.11.27-4.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing crda-1.1.3_2013.11.27-4.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3303/crda-1.1.3_2013.11.27-4.fc20
then log in and leave karma (feedback).

Comment 25 Hin-Tak Leung 2014-03-03 22:52:14 UTC
(In reply to Fedora Update System from comment #24)
> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2014-3303/crda-1.1.3_2013.11.
> 27-4.fc20
> then log in and leave karma (feedback).

Works okay & left karma.

Comment 26 Fedora Update System 2014-03-04 06:43:16 UTC
crda-1.1.3_2013.11.27-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Harald Hoyer 2014-03-14 11:16:44 UTC
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 35 Sep 25 15:24 /etc/localtime -> ../usr/share/zoneinfo/Europe/Berlin

$ readlink /etc/localtime
../usr/share/zoneinfo/Europe/Berlin

$ readlink -f /etc/localtime
/usr/share/zoneinfo/Europe/Berlin


You should really change /sbin/setregdomain to

ZONE=$(readlink -f $LOCALTIME)
or use
ZONE=${ZONE#*/zoneinfo/}


Note You need to log in before you can comment on or make changes to this bug.