Raspbian Lite 4.4 on RPi 3: Wifi changes regulatory domain multiple times during boot when configured in wpa_supplicant.conf #630
Comments
|
Having the same problem since the last upgrade... Linux pi 4.4.14-2-ARCH #1 SMP Sat Jul 2 20:41:34 MDT 2016 armv7l GNU/Linux linux-firmware 20160516.80d463b-1 Bus 001 Device 006: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n ...which is using ath9k |
|
Hmmm, seams to be an upstream issue then? Anybody can conform this? I set the CRDA at /etc/defaults/crda to DK and also but nothing has changed. It is still switching around :-(
And why does it ends by switching to DE? Where does that come from? Is it hardcoded somewhere? |
|
Also tried: |
shouldn't the DE in bold be DK too, or is it just a type error from watching logs? |
|
@tuxen it is a typing error here, I did correct on my RPi. |
|
Even without any of my attempts it switches to DE |
|
thought so =) |
I have vague recollections of crda setting regulatory based on system timezone. eg. /etc/localtime. |
|
I tried to copy copy Copenhagen to /etc/locatime and rebooted, but thats doesn't make any difference: Still changing from DK and back to DE, so to begin with it is correct (DK) but then for some reason it changes to DE. Any other place where DE is configured by default?
My configs: Hmmm, the comments in /etc/default/crda (see above) actually states that setting the REGDOMAIN should change the behavior of iw, but clearly we can see that something is happening since this setting is overwritten/changed to DE. |
@Ruffio I also have another vague recollection (from trying to help a user with similar problems a year ago), that when WPA supplicant connects to an AP, the reg domain can be set to match that of the AP it is associating with during the association. Never did really understand how/why, but I wonder if your AP is hard-coded to DE. Just throwing the thought out there..... If you 'iw reg set DK' after it has associated, does that "stick", or does it change back to DE? |
|
Same issue here ! Without setting anything wlan stick comes up with reg.domain set to CN (TP-Link Atheros based stick) |
|
Guys, I really do suspect that this might be because of what the AP is broadcasting as the country code. I know that Sky broadband customers in the UK, get given an AP/Router that broadcasts DE as the regulatory country.... eg. I'm in the UK, (GB), my neighbours who are using Sky as ISP, all appear to have AP's that are broadcasting DE as the regulatory country..... |
|
Sorry for my late response, but I have been without Internet connection during the weekend and still is :-( @clivem I don't know where to see if my AP is configured to DE, it is not an open source AP. ''' That is not what I expected. I expected, to see: cfg80211: Regulatory domain changed to country: DK Mayby you are right regarding that it is the AP that sets it to use DE, because right after the link becomes ready (look above), the cfg80211 changes to DE. ''' [ 2784.283860] busconnected_show(ad9fd810) -> platform_dev ad9fd800, otg_dev ad031800 [ 2784.284197] Core is not in hibernation [ 2785.253938] inv_sel_hsic_show(ad9fd810) -> platform_dev ad9fd800, otg_dev ad031800 [ 3271.040799] busconnected_show(ad9fd810) -> platform_dev ad9fd800, otg_dev ad031800 [ 3271.041143] Core is not in hibernation [ 3271.965410] inv_sel_hsic_show(ad9fd810) -> platform_dev ad9fd800, otg_dev ad031800 [ 3329.432206] busconnected_show(ad9fd810) -> platform_dev ad9fd800, otg_dev ad031800 [ 3329.432497] Core is not in hibernation [ 3330.399228] inv_sel_hsic_show(ad9fd810) -> platform_dev ad9fd800, otg_dev ad031800 I have also found this thread, but havn't got the chance to try it out: As soon as I get my internet connection back, I will try out some more testing and report back. |
|
Sorry, this is the correct link: http://fuzon.co.uk/phpbb/viewtopic.php?f=11&t=151&sid=b4aaa56c509e6d83ec743355d502d1ec&start=20 |
Just scan, I've got a feeling that when you associate with an AP via wpa_supplicant, some kind of callback takes place, probably via udev, (/lib/udev/rules.d/85-regulatory.rules change event calls setregdomain), if a country code is set on the AP. You could probably add some sort of logging to that change event, or a wrapper around setregdomain, so you can see when those events are being generated. |
|
Here its definitely not the case. Putting the "iw reg set DE" command into rc.local switches it to DE and ETSI: [ 22.480363] cfg80211: Calling CRDA for country: DE Changing the /etc/defaults/crda domain setting to DE sets the regulatory domain to county code 98 after reboot with no ISO name just the number (98 is reported as Iran...ooops). This is definitely wrong. Why is DE converted to "98" ? |
@lfoerster I think we are heading away from what the problem actually is now, but anyway..... I think setting regdomain from software/userspace can only make things more restrictive, with regard to regulatory restictions on channels and power, not less. It will not override what is set in the EEPROM. eg. I bought a wifi dongle from an American eBay vendor. The country was set to 'US' in the EEPROM. @Ruffio Anyway, before I butt-out of this conversation, you can always monitor the udev events from userspace. Probably won't tell you what is generating the regdomain change events, but should at least make it easy to see the country code that is being sent to userspace crda (setregdomain) from the kernel. |
|
My whole point of creating this issue is that I can see that RPi3 using onboard wifi does three times of changing the regulatory domain. IMHO it should only do it one time, not three. It should be unnecessary to the two last changes and it takes time for the booting to complete. I worries me that the CRDA has been implemented but there is no guidance in how to set it correctly. In this thread (http://raspberrypi.stackexchange.com/questions/40738/jessie-cfg80211-calling-crda-to-update-world-regulatory-domain) three valid suggestions are proposed and tried but none of them are working and I find no documentation on the official RPi Forum that explains what the correct way of doing it is. I still haven't been able to test in depth yet, but will eventually get there... |
|
@Ruffio Rasmus, I don't know if this is going to help you in any way, or muddy the waters because I'm using Fedora (F24) and my network connections are managed by NetworkManager, but anyway, I think this is working correctly..... (Or at least, the way I expect things to be working.) By which I mean, that World regulatory is "updated" followed by crda setting "GB" because of my London timezone. NB. In the case of the Atheros dongle, (example 3 log), it's CN, then GB. This is because the Atheros dongle has CN (China) programmed in hardware and the ath9k driver sets the regulatory based on that before it is changed, based on timezone, via Example 1, using on-board Pi3B brcmfmac. Example 2, using mt7601u dongle. Example 3, using Atheros AR9721 dongle. |
|
Looking at my AP, I do see the country set to DE even I live in DK, so that must be the reason why the driver changes. That should IMHO be configurable not to align. with AP: BSS 8c:10:d4:9a:6f:46(on wlan0) -- associated Regarding the error [ 12.324228] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code |
The whole point of the Linux kernel wifi code respecting 802.11d, if being broadcast by an AP, is to ensure radio regulatory compliance from the Linux side of things. I'd suggest that the problem is with the configuration of your AP, not the Linux wifi stack. ;) |
|
@clivem I agree and the one part, but how do you explain the brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code before the Interface has connected to the AP? Where is it that the driver is looking for ISO3166 code and potentially misread it? As far as I can find out, that is in etc/wpa_supplicant/wpa_supplicant.conf and /etc/default/crda where I already have configured it to be DK, so why does it throw that error? |
Like the Atheros which implements a mapping table in the driver, the (BRCM) firmware is using different codes internally, to the actual 2 digit country codes. That patch you referenced implements a mechanism to lookup a country code in a driver and convert it to what they are actually using internally. (Although, I didn't notice any actual mapping table.) Also, ISTR the driver code is throwing that warning/error when it receives any country code that isn't comprised of A-Z chars. It seems to happen after the world defaults are set from cfg80211. It's possibly just the reg_notifier callback into the driver after the world defaults are set from cfg80211 driver, and can probably be ignored........ Arend Van Spriel is probably the BRCM guy you need to start talking to, for definitive answers on anything concerning BRCM wifi. His email address is in that patch you referenced. |
|
@clivem thanks for your response, and please bear over with me if/when there is something I miss/don't understand. In your response I can't quite figure out if the driver can be configured/implemented differently in the various implementation. I have tried to find out how to configure it, but I can't find any documentation regarding this on the official RPi homepage. I know that it is not supposed to be a wiki with information of everything, and that is why I have tried to use configurations that other implementation have used. Since noone can answer me how to configure it correctly so no errors are thrown, I guess that nobody really knows? I could understand it if I had configured it in a very special and never used way, but this is how it works out of the box, without any configuration. Your suggestion regarding contacting Arend, that I will follow and update this issue. Hopefully soon :-) Thanks all for your contributions. |
|
@Ruffio Sorry, I'm not doing a very good job of explaining..... Even when I have an understanding in my own head, I'm not so good at putting it into words. Let me try again.... The error you see, All this means, AFAICT, is that the country code of '00' isn't passed back to the firmware by the driver. Later, you are setting a country code of 'DK'. This is "passed" by the driver to the device firmware. I agree, that in an ideal world there would be no errors, but I think this error, that '00' is |
|
Thanks. I wrote to Arend that quickly responded with the below. I guess there is nothing more to be done here as it is working as designed, even I don't agree on throwing an error if nothing can be done/configured to prevent this. I can. This is not really a problem. The regulatory code in cfg80211 has Regards, |
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.14-v7+ #896 SMP Sat Jul 2 15:09:43 BST 2016 armv7l GNU/Linux
I have changed the wpa to below, where country DK is set as regulatory domain:
pi@raspberrypi:~ $ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf
country=DK
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP = netdev
update_config=1
network={
ssid="XXX"
psk="XXX"
}
It looks like the wifi is changing regulatory domain several times during boot, sometime to unset, sometime to DE and sometime to the correct DK:
Here is part of my dmesg:
[ 5.387541] cfg80211: World regulatory domain updated:
[ 5.387554] cfg80211: DFS Master region: unset
[ 5.387567] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 5.387585] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5.387599] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 5.387611] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 5.387632] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 5.387672] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 5.387686] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 5.387698] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 5.387710] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 5.481267] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 5.602819] systemd-journald[139]: Received request to flush runtime journal from PID 1
[ 6.424771] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[ 6.424798] brcmfmac: brcmf_add_if: ignore IF event
[ 6.430232] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 6.430277] brcmfmac: power management disabled
[ 6.980087] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 6.980221] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 7.009238] cfg80211: Regulatory domain changed to country: DK
[ 7.009253] cfg80211: DFS Master region: ETSI
[ 7.009258] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 7.009266] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 7.009274] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 7.009282] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 7.009288] cfg80211: (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2700 mBm), (0 s)
[ 7.009301] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[ 8.054473] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 8.054488] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[ 8.270289] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 8.291739] cfg80211: Regulatory domain changed to country: DE
[ 8.291754] cfg80211: DFS Master region: ETSI
[ 8.291759] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 8.291767] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 8.291775] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 8.291782] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 8.291788] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s)
[ 8.291794] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[ 12.324228] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[ 12.324257] cfg80211: World regulatory domain updated:
[ 12.324266] cfg80211: DFS Master region: unset
[ 12.324276] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 12.324290] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.324311] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.324323] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.324338] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 12.324358] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 12.324371] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 12.324383] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.324396] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 12.363960] cfg80211: Regulatory domain changed to country: DK
[ 12.363984] cfg80211: DFS Master region: ETSI
[ 12.363994] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 12.364008] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 12.364024] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 12.364057] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 12.364077] cfg80211: (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2700 mBm), (0 s)
[ 12.364090] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[ 13.833626] cfg80211: Regulatory domain changed to country: DE
[ 13.833639] cfg80211: DFS Master region: ETSI
[ 13.833645] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 13.833653] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 13.833661] cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 13.833668] cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 13.833675] cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s)
[ 13.833681] cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
The text was updated successfully, but these errors were encountered: