Bug 806221 - Wireless: wrong regulatory domain/country is set up at boot
Wireless: wrong regulatory domain/country is set up at boot
Product: Fedora
Classification: Fedora
Component: crda (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
Depends On:
Blocks: 1057220
  Show dependency treegraph
Reported: 2012-03-23 05:05 EDT by Răzvan Sandu
Modified: 2017-03-16 15:43 EDT (History)
8 users (show)

See Also:
Fixed In Version: crda-1.1.3_2013.11.27-3.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1057220 (view as bug list)
Last Closed: 2014-02-19 19:41:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Răzvan Sandu 2012-03-23 05:05:33 EDT

I'm using wireless on a stock Dell Inspiron 1520 laptop. Wireless adapter (integrated) is "Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)", managed by the b43 kernel module.

All possible regional settings for the laptop are set to Romanian (RO).

Wireless access point is a Linksys WAP4410N, regulatory domain set for "Europe". Via the firmware, the access point is able to set/unset the wireless Worldwide Mode feature (802.11d).

All tests are made on stock Fedora 16 x86_64, Gnome.

Description of problem:

Wireless connection was unstable (frequent disconnection), with no apparent reason. While debugging it, I've noted that dmesg shows:

[   46.368748] cfg80211: Regulatory domain changed to country: GB

(if Worldwide mode is set to OFF)  or

[   46.368748] cfg80211: Regulatory domain changed to country: DE

(if Worldwide mode is set to ON).

Using the setregdomain utility, I am able to manually change the regulatory domain to my country (RO), but the setting is lost during reboot.

Version-Release number of selected component (if applicable):

Actual results:

There is no apparent way to SEE THE STATUS of the wireless regulatory domain/country and/or the Worldwide Mode (802.11d) (neither in NetworkManager, nor via command line).

There is no apparent way to permanently SET the wireless regulatory domain/country and/or the Worldwide Mode (802.11d) (neither in NetworkManager, nor in the /etc/sysconfig hierarchy).

Expected results:

Wireless regulatory domain/country and Worldwide Mode (802.11d) settings should be seen and changed via both X utilities (NetworkManager ?) and command line tools. The configuration file where the settings are stored must be documented appropriately (maybe a file under /etc/sysconfig ?). 

The situation in which the laptop's wireless is used in AD-HOC mode must be taken into account.
Comment 1 Edouard Bourguignon 2013-01-04 02:45:26 EST
In the file /etc/sysconfig/network-scripts/ifcfg-Auto_SSID you can set COUNTRY=XX and it works. I try it by luck, no documentation anywhere. I don't find any way to set the default regulatory domain... The NetworkManager applet don't have any country selector.
Comment 2 Edouard Bourguignon 2013-01-04 02:50:38 EST
The default regulatory domain on Fedora 18 is US by the way, preventing users in other countries to reach some channels forbiden in the US (ie 12 and 13), and therefor preventing any connection to their AP. How do we change the default regulator domain?
Comment 3 John W. Linville 2013-01-07 10:19:43 EST
The /sbin/setregdomain script should be getting run by udev.  It should deduce your regulatory domain based on your timezone setting.  You can override that using /etc/sysconfig/regdomain instead.  Does that work for you?  If not, can you try running /sbin/setregdomain manually (as root)?
Comment 4 Fedora End Of Life 2013-12-21 03:34:21 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 Fabrice Allibe 2014-01-08 10:18:36 EST

I faced a similar issue on brand new F20 installed from scratch.
Regulatory domain was not set based on my timezone setting, which was defined as following at installation time:

[root@e4310 ~]# ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 34 23 déc.  10:24 /etc/localtime -> ../usr/share/zoneinfo/Europe/Paris

It appears that /sbin/setregdomain, correctly called from /usr/lib/udev/rules.d/85-regulatory.rules at boot time, was failing because of two issues in the script (one related to wrong var $TZ and other related to broken substitution on $ZONE).

[root@e4310 ~]# rpm -qf /sbin/setregdomain

I made some quick hacks to get it working fine:

[root@e4310 ~]# diff  /sbin/setregdomain.orig /sbin/setregdomain
< if [ -f $TZ ]
> if [ -f $LOCALTIME ]
< 	ZONE=${ZONE#/usr/share/zoneinfo/}
> 	ZONE=${ZONE#../usr/share/zoneinfo/}

Should I create a bug related to crda on f20, or can you update this bug to link it with new fedora version and component ?

Comment 6 epablo 2014-01-23 02:38:56 EST
Got the same problem on Fedora 20.

Quick workaround was:
echo "COUNTRY=DE" > /etc/sysconfig/regdomain

This will probably stay until the bug is fixed.
Comment 7 John W. Linville 2014-01-23 11:13:14 EST
epablo's work-around should fix affected systems.

Fabrice, thanks for pointing-out the typo in setregdomain!  I'll apply a patch, but mine is a bit different.  In particular, the change to the 'ZONE=...' line should not be required, and I'm adding quotes around the '-f "$LOCALTIME"' test.  Please be sure to test the build when it becomes available.
Comment 8 Fedora Update System 2014-01-23 12:51:50 EST
crda-1.1.3_2013.11.27-3.fc20 has been submitted as an update for Fedora 20.
Comment 9 Fedora Update System 2014-01-24 21:19:48 EST
Package crda-1.1.3_2013.11.27-3.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-3.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 10 Fabrice Allibe 2014-01-26 15:50:12 EST
Hello John,

OK for the patch but the change is unfortunately not sufficient, because of the way the symlink /etc/localtime was created (../usr/share/zoneinfo/Europe/Paris instead of /usr/share/zoneinfo/Europe/Paris) when systemd package was installed:
[root@e4310 ~]# ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 34 23 déc.  10:24 /etc/localtime -> ../usr/share/zoneinfo/Europe/Paris
[root@e4310 ~]# rpm -qf /etc/localtime 

Thus the script can not find the right timezone with following string substitution
	ZONE=$(readlink $LOCALTIME)

That's the reason why I had included in my quick fix

Maybe should we only include both lines, to give the script ability to handle both /etc/localtime configurations, which would give something like:
	ZONE=$(readlink $LOCALTIME)

There may be also a smarter way to retrieve localtime parameters.

Or you consider it is more a "systemd" bug to get such strange "../" and then we should ask for a systemd bugfix.

Comment 11 John W. Linville 2014-02-11 08:56:58 EST
I have no idea how your /etc/localtime got that way.  Mine is setup with a non-relative path:

[linville-x1.hq.tuxdriver.com]:> ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 36 Feb 21  2013 /etc/localtime -> /usr/share/zoneinfo/America/New_York
Comment 12 epablo 2014-02-11 09:05:43 EST
my /etc/localtime is also linked via a relative path:

[epablo@keymaker ~]$ ls -l /etc/localtime
lrwxrwxrwx. 1 root root 35 Jan 20 22:38 /etc/localtime -> ../usr/share/zoneinfo/Europe/Berlin
Comment 13 John W. Linville 2014-02-18 15:08:52 EST
Let's move the relative path stuff to bug 891018 for now...
Comment 14 Fedora Update System 2014-02-19 19:41:38 EST
crda-1.1.3_2013.11.27-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Harald Reindl 2017-03-16 14:25:34 EDT
why can't Fedora not have a config file like every other distribution?

/etc/sysconfig/regdomain is at least on F25 ignored

man crda

Environment variable
Set the COUNTRY environment variable with a specific ISO / IEC 3166 alpha2 country code and then run crda without arguments. This will send a regulatory domain for that alpha2 to the kernel

yeah, that won't work with udev stuff

[root@srv-rhsoft:~]$ crda
COUNTRY environment variable not set.
[root@srv-rhsoft:~]$ cat /etc/sysconfig/regdomain
[root@srv-rhsoft:~]$ export COUNTRY=AT; crda
nl80211 not found.

"nl80211 not found" is https://bugzilla.redhat.com/show_bug.cgi?id=1422247

so with F25 and the new 4.10.3 kernel no hostapd....
Comment 16 John W. Linville 2017-03-16 14:33:16 EDT
You would be better off with "man setregdomain"...

Could you post the contents of:


Also, post the output of "rpm -ql crda"?

TBH, you probably should open a new bug instead of hijacking one that was closed three years ago...
Comment 17 Harald Reindl 2017-03-16 14:39:39 EDT
"man setregdomain" talks about /etc/sysconfig/regdomain and as you can see above crda don't care about - i responsed to *that* buegrport *because* /etc/sysconfig/regdomain is mentioned in above responses

https://ask.fedoraproject.org/en/question/88141/where-is-the-config-file-of-crda-in-fedora/ with no useful answer also points out that other distributions have /etc/default/crda

frankly also before 4.10.x i see early failed crda calls in the logs for many months while at the end when hostapd starts it got fixed somehow 

[root@srv-rhsoft:~]$ crda
nl80211 not found.

[root@srv-rhsoft:~]$ cat /lib/udev/rules.d/85-regulatory.rules
# Runs CRDA for kernel wireless regulatory events.
# For more information see:
# http://wireless.kernel.org/en/developers/Regulatory/CRDA

SUBSYSTEM=="ieee80211", ACTION=="add", RUN+="/usr/sbin/setregdomain"

KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/usr/sbin/crda"
Comment 18 John W. Linville 2017-03-16 15:14:01 EDT
I believe if you look at /usr/sbin/setregdomain, you will see that it does care what is in /etc/sysconfig/regdomain.

Is the timezone properly set on your machine?

What happens when you run (as root) /usr/sbin/setregdomain manually?

I don't really care if other distros have /etc/default/crda or not. Some also seem to have a version of setregdomain that I wrote 8 years ago and which they have never updated in the meantime...
Comment 19 Harald Reindl 2017-03-16 15:20:19 EDT
[root@srv-rhsoft:~]$ setregdomain
[root@srv-rhsoft:~]$ dmesg
[Do Mär 16 20:19:43 2017] Firewall Portscan: IN=br-wan OUT= MAC=00:50:8d:b5:cc:de:00:01:5c:24:68:01:08:00 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
[root@srv-rhsoft:~]$ cat messages
Mar 16 20:19:43 srv-rhsoft systemd-udevd: Process '/usr/sbin/crda' failed with exit code 251.
Mar 16 20:19:46 srv-rhsoft systemd-udevd: Process '/usr/sbin/crda' failed with exit code 251.
Comment 20 John W. Linville 2017-03-16 15:41:35 EDT
Just checking...had you already run crda since the last reboot?

It is important for to reboot, and only run setregdomain after the reboot -- never fun crda by hand.
Comment 21 Harald Reindl 2017-03-16 15:43:34 EDT
most likely it's "just" https://bugzilla.redhat.com/show_bug.cgi?id=1422247 and anything else is additional fallout trying to find out what is going on and get the wlan-ap's working again - hopefully we will seee a useable 4.10.x for F25 soon

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