Wireless regdomain misteriously set to two different values

LeonardK · 2015-04-12 14:16:36

Hello,

There seem to be quite a few people having problems with wireless regdomains but no solutions working elsewhere did it for me.
So far I found those threads:
https://bbs.archlinux.org/viewtopic.php?id=164279
https://bbs.archlinux.org/viewtopic.php?id=146052
https://bbs.archlinux.org/viewtopic.php?id=132079
https://bbs.archlinux.org/viewtopic.php?id=136482
Diverse other sources from other threads that pop up on Google... (maybe I'll add them later, quite some)

The problem:
My WLAN card is a Broadcom BCM43228, driver b43/broadcom-wl (both tried, same thing).

Basically what happens when connecting via netctl(-auto) is that "Calling CRDA for country: DE" is triggered, then "Calling CRDA to update world regulatory domain" and then the DE-update again.
Without crda and wireless-regdb this ofcourse only triggers the update but still interferes with connecting to the WiFi as the link is set down and up again:

WPA association/authentication failed for interface 'wlpXXX'

To this point I did NOT change the regdomain manually or did anything. This is on a plain install.

My idea was to override either, setting it to "DE" (which astonishingly is correct) or to "00". So I installed aforementioned packages and edited once both, once only one:

/etc/wpa_supplicant/wpa_supplicant.conf (country=XX)
/etc/conf.d/wireless-regdom

to once "DE", once "00". Either way, something is setting "DE", something is setting "00".

So I tried to find out which was setting the regdomain to either one further, but I'm not sure yet.

My research began doing:

dmesg | grep CRDA

which showed me that actually the thing is the following:

First, regdom is called to set to 00 twice, then back to DE.

When I'm then starting netctl-auto (disabled for testing) the regdomain is set as follows: DE, 00, DE (and so it continues). wpa_supplicant however is running.

So it seems that netctl-auto triggers "something" that sets the regulatory domain to either "00" or "DE".
The "other" thing that changes the regdom *might* be the firmware.

So, to me, either thing is possible:
A)
The firmware sets the regdom to "00" (an indicator also would be that the earliest CRDA call is 00).
Something behind netctl-auto is setting "DE", after getting reset to "00" by the firmware it insists on "DE". But sadly, all this back and forth makes the WiFi not work.
Additionally this could be probable by netctl being "such a wizard" as detecting either your location/TimeZone or using the output of an equivalent of "iw dev wlpXXX scan" on the router I'm connecting to to set the regdomain accordingly. I have no other clue where it should know my country from.

B)
The other theory would be that the firmware is actually setting the regulatory domain to "DE". Why could this be? I'm dual-booting Windows and maybe the Windows driver installs a different firmware for "DE" which not completely gets overriden by the firmware install by linux.
Then netctl sets it back to "00".

Personally I think the former is the case but it still does not help me

I did some more researching and tried to connect without netctl but with wpa_supplicant solely ( -> wiki-page used):
After "Trying to associate" I get "CTRL-EVENT-DISCONNECTED bssid=XX:XX:XX:XX:XX:XX reason=0" directly followed by "CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD".

This is followed by:

Associated with XX:XX:XX:XX:XX:XX
WPA: Failed to set PTK to the driver ...
CTRL-EVENT-DISCONNECTED bssid=XX:XX:XX:XX:XX:XX reason=1 locally_generated=1
WPA: 4-Way Handshake failed – pre-shared key may be incorrect [it was correct]

This is everything I could gather so far.

It seems that the regdom somehow interferes with the authentication handshake?
And: I'm NOT connecting to a WiFi that uses DE-specific channels. It should work if my regdom was set to 00. The problem is the change it seems.

Last edited by LeonardK (2015-04-16 17:01:46)

LeonardK · 2015-04-16 17:09:55

UPDATE:

So I digged a bit further and on the linux wiki I found an entry for the broadcom softmac driver (not one of mine, but this seems to be irrelevant here):

Regulatory Implementation for brcmsmac
This generation of chips contain additional regulatory support independent of the driver. The devices use a single worldwide regulatory domain, with channels 12-14 (2.4 GHz band) and channels 52-64 and 100-140 (5 GHz band) restricted to passive operation. Transmission on those channels is suppressed until appropriate other traffic is observed on those channels. Within the driver, we use the ficticious country code “X2” to represent this worldwide regulatory domain. There is currently no interface to configure a different domain. The driver reads the SROM country code from the chip and hands it up to mac80211 as the regulatory hint, however this information is otherwise unused with the driver.

That's why it springs back to 00 all the time but sadly I still do not know why it wants to use DE sometimes.

I removed GeoClue installed as a qt5-webkit dependency but this didn't solve it either. It may be those "beacon hints" So my router says "it's German" and thus something calls CRDA to update the regdom – but as the device does not allow this, it springs back. If so, I need a way to turn this off.

Is there any possibility to debug what triggers those updates?
dmesg just says "cfg80211".

I also tried uninstalling wireless-regdb and crda and instead using a modprobe parameter on cfg80211, but this does have no effect at all.
I even can set wpa_supplicant.conf's 'country=' option to whatever I like, this does not show up in dmesg, neither does a change in wireless-regdb have any effect.

I'm no totally clueless, do you have any idea on how to solve this or where I might have something else to read into?
I have nothing against rebuilding wireless-regdb but it rather seems that the problem is the continuous change than the 00-setting :-/

LeonardK · 2015-05-19 09:22:02

A small update as I didn't get much further: Both triggers (DE and 00) are kernel-space (atleast dmesg -f kern displays them all). This limits the possibilities where this weird "DE" comes from – is there a possibility to check what is calling the CRDA exactly, I mean: not cfg80211, but what triggers that update?

Arch Linux

#1 2015-04-12 14:16:36

Wireless regdomain misteriously set to two different values

#2 2015-04-16 17:09:55

Re: Wireless regdomain misteriously set to two different values

#3 2015-05-19 09:22:02

Re: Wireless regdomain misteriously set to two different values

Board footer