+++ This bug was initially created as a clone of Bug #806221 +++

Hi,

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):
wireless-tools-29-6.1.fc15.x86_64
kernel-3.3.0-4.fc16.x86_64
crda-1.1.1_2010.11.22-2.fc15.x86_64

  
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.

--- Additional comment from Edouard Bourguignon on 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.

--- Additional comment from Edouard Bourguignon on 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?

--- Additional comment from John W. Linville on 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)?

--- Additional comment from Fedora End Of Life on 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.

--- Additional comment from Fabrice Allibe on 2014-01-08 10:18:36 EST ---

Hello,

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
crda-1.1.3_2013.02.13-4.fc20.x86_64

I made some quick hacks to get it working fine:

[root@e4310 ~]# diff  /sbin/setregdomain.orig /sbin/setregdomain
43c43
< if [ -f $TZ ]
---
> if [ -f $LOCALTIME ]
46c46
< 	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 ?

Regards
Fabrice

--- Additional comment from epablo on 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.

--- Additional comment from John W. Linville on 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.