Bug 806221
Summary: | Wireless: wrong regulatory domain/country is set up at boot | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Răzvan Sandu <rsandu2004> | |
Component: | crda | Assignee: | John W. Linville <linville> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 20 | CC: | dcbw, epablo, fabrice.allibe, harald, h.reindl, linville, madko, swadeley | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
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) | Environment: | ||
Last Closed: | 2014-02-20 00:41:38 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1057220 |
Description
Răzvan Sandu
2012-03-23 09:05:33 UTC
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. 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? 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)? 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. 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 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. 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. crda-1.1.3_2013.11.27-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/crda-1.1.3_2013.11.27-3.fc20 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: https://admin.fedoraproject.org/updates/FEDORA-2014-1480/crda-1.1.3_2013.11.27-3.fc20 then log in and leave karma (feedback). 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 systemd-208-9.fc20.x86_64 Thus the script can not find the right timezone with following string substitution ZONE=$(readlink $LOCALTIME) ZONE=${ZONE#/usr/share/zoneinfo/} That's the reason why I had included in my quick fix ZONE=${ZONE#../usr/share/zoneinfo/} 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) ZONE=${ZONE#/usr/share/zoneinfo/} ZONE=${ZONE#../usr/share/zoneinfo/} 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. Cheers Fabrice 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 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 Let's move the relative path stuff to bug 891018 for now... 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. 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 COUNTRY=AT [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.... You would be better off with "man setregdomain"... Could you post the contents of: /lib/udev/rules.d/85-regulatory.rules 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... "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" 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... [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=123.249.79.241 DST=62.178.103.85 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. [root@srv-rhsoft:~]$ 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. 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 |