Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[John S. Skogtvedt]

Hello,

As the subject says, using ath5k on 2.6.32 I am not able to connect to
an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
fails to associate). I'm in Norway, and the card is bought in Norway.

With 2.6.26 and 2.6.30, I am able to connect to the AP if I use the
cfg80211 ieee80211_regdom=EU option (necessary at least on 2.6.26).
For 2.6.32, I've tried without the option as well as ieee80211_regdom=NO.

I'm running Debian Squeeze, and the kernel version is
linux-image-2.6-686=2.6.32+23. The changelog for the kernel package is
available at:
http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-5/changelog

As the AP doesn't appear when doing a scan, I didn't capture the
wpa_supplicant output.

dmesg output:
[    7.205952] cfg80211: Using static regulatory domain info
[    7.205956] cfg80211: Regulatory domain: US
[    7.206243] cfg80211: Calling CRDA for country: US
[    7.305635] ath5k 0000:01:0a.0: PCI INT A -> Link[APC1] -> GSI 16
(level, high) -> IRQ 16
[    7.305709] ath5k 0000:01:0a.0: registered as 'phy0'
[    7.887265] ath: EEPROM regdomain: 0x80d0
[    7.887267] ath: EEPROM indicates we should expect a country code
[    7.887270] ath: doing EEPROM country->regdmn map search
[    7.887272] ath: country maps to regdmn code: 0x37
[    7.887275] ath: Country alpha2 being used: DK
[    7.887277] ath: Regpair used: 0x37
[    8.288352] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
[    8.288607] cfg80211: Calling CRDA for country: DK

lspci:
01:0a.0 Ethernet controller: Atheros Communications Inc. Atheros
AR5001X+ Wireless Network Adapter (rev 01)
        Subsystem: D-Link System Inc D-Link AirPlus DWL-G520 Wireless
PCI Adapter(rev.B)
        Kernel driver in use: ath5k

iw list output:
Wiphy phy0
        Band 1:
                Frequencies:
                        * 2412 MHz [1] (20.0 dBm)
                        * 2417 MHz [2] (20.0 dBm)
                        * 2422 MHz [3] (20.0 dBm)
                        * 2427 MHz [4] (20.0 dBm)
                        * 2432 MHz [5] (20.0 dBm)
                        * 2437 MHz [6] (20.0 dBm)
                        * 2442 MHz [7] (20.0 dBm)
                        * 2447 MHz [8] (20.0 dBm)
                        * 2452 MHz [9] (20.0 dBm)
                        * 2457 MHz [10] (20.0 dBm)
                        * 2462 MHz [11] (20.0 dBm)
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
...


iw reg get output:
country US:
        (2402 - 2472 @ 40), (6, 27)
        (5170 - 5190 @ 40), (6, 23)
        (5190 - 5210 @ 40), (6, 23)
        (5210 - 5230 @ 40), (6, 23)
        (5230 - 5330 @ 40), (6, 23)
        (5735 - 5835 @ 40), (6, 30)

I tried "iw reg set NO" without effect.

Please let me know if you need any more information. (Also, please CC me
on replies as I'm not on the list.)

Thank you,

John.

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Bob Copeland]

On Sun, Jan 24, 2010 at 4:12 PM, John S. Skogtvedt <jss@bzz.no> wrote:
> Hello,
>
> As the subject says, using ath5k on 2.6.32 I am not able to connect to
> an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
> fails to associate). I'm in Norway, and the card is bought in Norway.

> dmesg output:
> [    7.205952] cfg80211: Using static regulatory domain info
> [    7.205956] cfg80211: Regulatory domain: US
> [    7.206243] cfg80211: Calling CRDA for country: US

Well, there's your problem, AFAICT.  You have
CONFIG_WIRELESS_OLD_REGULATORY=y?  And ieee80211_regdom=EU doesn't work?

> [    7.887265] ath: EEPROM regdomain: 0x80d0
> [    7.887267] ath: EEPROM indicates we should expect a country code
> [    7.887270] ath: doing EEPROM country->regdmn map search
> [    7.887272] ath: country maps to regdmn code: 0x37
> [    7.887275] ath: Country alpha2 being used: DK
> [    7.887277] ath: Regpair used: 0x37
> [    8.288352] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
> [    8.288607] cfg80211: Calling CRDA for country: DK

Denmark, which should allow the channels in question.

> iw list output:
> Wiphy phy0
>        Band 1:
>                Frequencies:
>                        * 2412 MHz [1] (20.0 dBm)
>                        * 2417 MHz [2] (20.0 dBm)
>                        * 2422 MHz [3] (20.0 dBm)
>                        * 2427 MHz [4] (20.0 dBm)
>                        * 2432 MHz [5] (20.0 dBm)
>                        * 2437 MHz [6] (20.0 dBm)
>                        * 2442 MHz [7] (20.0 dBm)
>                        * 2447 MHz [8] (20.0 dBm)
>                        * 2452 MHz [9] (20.0 dBm)
>                        * 2457 MHz [10] (20.0 dBm)
>                        * 2462 MHz [11] (20.0 dBm)
>                        * 2467 MHz [12] (disabled)
>                        * 2472 MHz [13] (disabled)
>                        * 2484 MHz [14] (disabled)
> ...
>
>
> iw reg get output:
> country US:
>        (2402 - 2472 @ 40), (6, 27)
>        (5170 - 5190 @ 40), (6, 23)
>        (5190 - 5210 @ 40), (6, 23)
>        (5210 - 5230 @ 40), (6, 23)
>        (5230 - 5330 @ 40), (6, 23)
>        (5735 - 5835 @ 40), (6, 30)
>
> I tried "iw reg set NO" without effect.

CCed Luis in case he has anything to add.

-- 
Bob Copeland %% www.bobcopeland.com

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Gábor Stefanik]

On Mon, Jan 25, 2010 at 6:51 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Sun, Jan 24, 2010 at 4:12 PM, John S. Skogtvedt <jss@bzz.no> wrote:
>> Hello,
>>
>> As the subject says, using ath5k on 2.6.32 I am not able to connect to
>> an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
>> fails to associate). I'm in Norway, and the card is bought in Norway.
>
>> dmesg output:
>> [    7.205952] cfg80211: Using static regulatory domain info
>> [    7.205956] cfg80211: Regulatory domain: US
>> [    7.206243] cfg80211: Calling CRDA for country: US
>
> Well, there's your problem, AFAICT.  You have
> CONFIG_WIRELESS_OLD_REGULATORY=y?  And ieee80211_regdom=EU doesn't work?
>
>> [    7.887265] ath: EEPROM regdomain: 0x80d0
>> [    7.887267] ath: EEPROM indicates we should expect a country code
>> [    7.887270] ath: doing EEPROM country->regdmn map search
>> [    7.887272] ath: country maps to regdmn code: 0x37
>> [    7.887275] ath: Country alpha2 being used: DK
>> [    7.887277] ath: Regpair used: 0x37
>> [    8.288352] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
>> [    8.288607] cfg80211: Calling CRDA for country: DK
>
> Denmark, which should allow the channels in question.

However, does the DK regdomain really get set? Is CRDA installed?

>
>> iw list output:
>> Wiphy phy0
>>        Band 1:
>>                Frequencies:
>>                        * 2412 MHz [1] (20.0 dBm)
>>                        * 2417 MHz [2] (20.0 dBm)
>>                        * 2422 MHz [3] (20.0 dBm)
>>                        * 2427 MHz [4] (20.0 dBm)
>>                        * 2432 MHz [5] (20.0 dBm)
>>                        * 2437 MHz [6] (20.0 dBm)
>>                        * 2442 MHz [7] (20.0 dBm)
>>                        * 2447 MHz [8] (20.0 dBm)
>>                        * 2452 MHz [9] (20.0 dBm)
>>                        * 2457 MHz [10] (20.0 dBm)
>>                        * 2462 MHz [11] (20.0 dBm)
>>                        * 2467 MHz [12] (disabled)
>>                        * 2472 MHz [13] (disabled)
>>                        * 2484 MHz [14] (disabled)
>> ...
>>
>>
>> iw reg get output:
>> country US:
>>        (2402 - 2472 @ 40), (6, 27)
>>        (5170 - 5190 @ 40), (6, 23)
>>        (5190 - 5210 @ 40), (6, 23)
>>        (5210 - 5230 @ 40), (6, 23)
>>        (5230 - 5330 @ 40), (6, 23)
>>        (5735 - 5835 @ 40), (6, 30)
>>
>> I tried "iw reg set NO" without effect.
>
> CCed Luis in case he has anything to add.
>
> --
> Bob Copeland %% www.bobcopeland.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Luis R. Rodriguez]

2010/1/25 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Mon, Jan 25, 2010 at 6:51 PM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Sun, Jan 24, 2010 at 4:12 PM, John S. Skogtvedt <jss@bzz.no> wrote:
>>> Hello,
>>>
>>> As the subject says, using ath5k on 2.6.32 I am not able to connect to
>>> an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
>>> fails to associate). I'm in Norway, and the card is bought in Norway.
>>
>>> dmesg output:
>>> [    7.205952] cfg80211: Using static regulatory domain info
>>> [    7.205956] cfg80211: Regulatory domain: US
>>> [    7.206243] cfg80211: Calling CRDA for country: US
>>
>> Well, there's your problem, AFAICT.  You have
>> CONFIG_WIRELESS_OLD_REGULATORY=y?  And ieee80211_regdom=EU doesn't work?

OLD_REG is exactly that, old regulatory, new regulatory stuff does not
know anything about EU as EU is not a country. OLD_REG is in fact
removed from the latest wireless-testing.git so I recommend debian
just abandon it.

>>> [    7.887265] ath: EEPROM regdomain: 0x80d0
>>> [    7.887267] ath: EEPROM indicates we should expect a country code
>>> [    7.887270] ath: doing EEPROM country->regdmn map search
>>> [    7.887272] ath: country maps to regdmn code: 0x37
>>> [    7.887275] ath: Country alpha2 being used: DK
>>> [    7.887277] ath: Regpair used: 0x37
>>> [    8.288352] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
>>> [    8.288607] cfg80211: Calling CRDA for country: DK
>>
>> Denmark, which should allow the channels in question.
>
> However, does the DK regdomain really get set? Is CRDA installed?
>
>> CCed Luis in case he has anything to add.

Yea not sure if debian ships crda and wireless-regdb yet.

  Luis

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Kalle Valo]

"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:

>> However, does the DK regdomain really get set? Is CRDA installed?
>>
>>> CCed Luis in case he has anything to add.
>
> Yea not sure if debian ships crda and wireless-regdb yet.

I'm running debian unstable and haven't seen crda yet.

-- 
Kalle Valo

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Luis R. Rodriguez]

On Tue, Jan 26, 2010 at 2:20 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> "Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
>
>>> However, does the DK regdomain really get set? Is CRDA installed?
>>>
>>>> CCed Luis in case he has anything to add.
>>
>> Yea not sure if debian ships crda and wireless-regdb yet.
>
> I'm running debian unstable and haven't seen crda yet.

Kel, curious if you might be aware of the debian's packaging status of
CRDA and wireless-regdb. Also can you recommend a kernel contact, I'd
like to recommend to not use CONFIG_WIRELESS_OLD_REGULATORY for a few
reasons [1] as it seems to be the default on the current 2.6.32
kernel.

[1] http://wireless.kernel.org/en/developers/Regulatory#Old_regulatory_implementation

  Luis

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Kel Modderman]

Hey Luis,

On Wednesday 27 January 2010 05:06:11 Luis R. Rodriguez wrote:
> On Tue, Jan 26, 2010 at 2:20 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> > "Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
> >
> >>> However, does the DK regdomain really get set? Is CRDA installed?
> >>>
> >>>> CCed Luis in case he has anything to add.
> >>
> >> Yea not sure if debian ships crda and wireless-regdb yet.
> >
> > I'm running debian unstable and haven't seen crda yet.
> 
> Kel, curious if you might be aware of the debian's packaging status of
> CRDA and wireless-regdb.

Yeah, I am reluctantly aware. My life circumstances have been turbulent
recently (eg. moving overseas and back again, work etc.) so I've been moving
very slow on the packaging-wireless-stuff-for-Debian front, as you observed
already. In my defense, I have never declared my intent to package this stuff
in Debian exactly so I would not stop anyone else going ahead and doing just
that, nobody has done anything afaik :(

To top off the story, I am not a Debian Developer and thus am not trusted to
introduce or update software in the archive without the help of mentors. This
is why the pkg-wpa-devel group was formed with 4 members. 1 just declared he
will no longer participate due to change in interests, 1 went MIA over a year
or two ago, and the other one never had any interest in working much on stuff,
just uploading hostapd to the archive once or twice a year. I've had little
time to seek help from others, and in the past I already sought help and noone
I asked gave a crap. So, maybe I'm not the best candidate to get this software
and associated changes into Debian.

Having said all that, I found time to package and test crda/wireless-regdb
on my travels and here is a summary:

wireless-regdb
--------------
Vcs-Svn: svn://svn.debian.org/pkg-wpa/wireless-regdb/trunk
Vcs-Browser: http://svn.debian.org/wsvn/pkg-wpa/wireless-regdb/trunk/
* contains patch to use two argument db2bin.py command and thus not signing
  regulatory.bin - which will no doubt disappoint you. I cannot for the life
  of me fathom how we can manage to sanely manage upload of a source package
  to a bunch of other hosts to be built (arch buildd's) and still manage to
  sign each binary with a private key. Don't sign it, and I cannot see any
  problems from the logistical point of view, but then I begin to think about
  legal consequences of distributing a crda binary which will read any unsigned
  regulatory data it is given. Need to send this patch to you.
  (not sure that runtime reading of pem pubsert helps with this much at all,
  while that is a nice new feature.)
* a friend sent me some patches to enhance the package a bit, still sitting
  in my inbox

[0] http://svn.debian.org/wsvn/pkg-wpa/wireless-regdb/trunk/debian/patches/disable_pubkeys.patch

crda
----
Vcs-Svn: svn://svn.debian.org/pkg-wpa/crda/trunk
Vcs-Browser: http://svn.debian.org/wsvn/pkg-wpa/crda/trunk/
* a friend sent me some patches to enhance the package a bit, still sitting
  in my inbox, needs to be updated to new release too.
* added a patch to disable linking to gcrypt [1], crda binary is not linked
  to anything which currently lives under /usr thus totally avoiding problems
  associated with a set of partition/filesystem schemes. It doesn't need
  any crypto stuff anyway, wireless-regdb is currently unsigned. I need to
  send this patch to you.
* After looking at the fedora/redhat package, I noticed they had a udev rule
  which called a script when ieee80211 subsystem was added and this script
  then tries to find out the timezone configuration of the system, then
  parse a file which maps the timezone to an ISO 3166 code and then calls
  iw to set it. This seemed like a good faith attempt at setting a default
  in the absence of any other technology (like geoclue?) so ported it to
  Debian using dpkg triggers to prepare a map of timezone -> iso code
  at package install/update time rather than doing it at runtime.
* btw, Makefile has a typo -> s/make noverify/make all_noverify/

[1] http://svn.debian.org/wsvn/pkg-wpa/crda/trunk/debian/patches/disable_gcrypt.patch

Common stuff
------------
* file ITP's for both packages and defend/explain myself to curious
  developers
* find a long term mentor - preferably one that is interested in more than
  just uploading the software, helping with bugs and giving guidance would
  be a bonus
    or
  cutting the red tape and becoming a Debian-Maintainer and conning a short
  term mentor that I am perfectly able to take care of this stuff myself, which
  I am not really
    or
  getting some other person to do it all and walking away from it :)
* influence the Debian kernel people to make required changes. Communicating
  with some of them is similar to recording the running of long strong
  fingernails down a blackboard, and replaying the recording in an endless
  loop on the car stereo while driving to the dentist. Only joking, but
  some of the team seem to be a bit funny. You could definitely help with
  this, but I reckon it'd be easier if crda/wireless-regdb packaging was
  already finalised in good shape and in the archive. This requires a wishlist
  bug report to be made against linux-latest-2.6 and some further discussion
  with 'em about it.
* getting the initial uploads done, passing through NEW checks and then
  working on any teething problems thereafter


Am happy for anyone else to pick up my stuff, take it change it and get a
painless, just working, set of the software in Debian. Or even just the latter
bit :)

> Also can you recommend a kernel contact, I'd
> like to recommend to not use CONFIG_WIRELESS_OLD_REGULATORY for a few
> reasons [1] as it seems to be the default on the current 2.6.32
> kernel.

Debian Kernel Team <debian-kernel@lists.debian.org>, more details at:
http://packages.qa.debian.org/l/linux-latest-2.6.html

> 
> [1] http://wireless.kernel.org/en/developers/Regulatory#Old_regulatory_implementation
> 
>   Luis
> 

Thanks, Kel.

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Luis R. Rodriguez]

On Thu, Jan 28, 2010 at 5:27 AM, Kel Modderman <kel@otaku42.de> wrote:

> Am happy for anyone else to pick up my stuff, take it change it and get a
> painless, just working, set of the software in Debian. Or even just the latter
> bit :)
>
>> Also can you recommend a kernel contact, I'd
>> like to recommend to not use CONFIG_WIRELESS_OLD_REGULATORY for a few
>> reasons [1] as it seems to be the default on the current 2.6.32
>> kernel.
>
> Debian Kernel Team <debian-kernel@lists.debian.org>, more details at:
> http://packages.qa.debian.org/l/linux-latest-2.6.html

Thanks for all your work and details, I'll go poke
debian-kernel@lists.debian.org now to see if I can help. I can try to
help with the packaging and see if there are any questions regarding
that stuff or CONFIG_WIRELESS_OLD_REGULATORY.

  Luis

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[John S. Skogtvedt]

Gábor Stefanik skrev:
> On Mon, Jan 25, 2010 at 6:51 PM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Sun, Jan 24, 2010 at 4:12 PM, John S. Skogtvedt <jss@bzz.no> wrote:
>>> Hello,
>>>
>>> As the subject says, using ath5k on 2.6.32 I am not able to connect to
>>> an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
>>> fails to associate). I'm in Norway, and the card is bought in Norway.
>>> dmesg output:
>>> [    7.205952] cfg80211: Using static regulatory domain info
>>> [    7.205956] cfg80211: Regulatory domain: US
>>> [    7.206243] cfg80211: Calling CRDA for country: US
>> Well, there's your problem, AFAICT.  You have
>> CONFIG_WIRELESS_OLD_REGULATORY=y?  And ieee80211_regdom=EU doesn't work?
>>
>>> [    7.887265] ath: EEPROM regdomain: 0x80d0
>>> [    7.887267] ath: EEPROM indicates we should expect a country code
>>> [    7.887270] ath: doing EEPROM country->regdmn map search
>>> [    7.887272] ath: country maps to regdmn code: 0x37
>>> [    7.887275] ath: Country alpha2 being used: DK
>>> [    7.887277] ath: Regpair used: 0x37
>>> [    8.288352] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
>>> [    8.288607] cfg80211: Calling CRDA for country: DK
>> Denmark, which should allow the channels in question.
> 
> However, does the DK regdomain really get set? Is CRDA installed?
> 

Thank you, with CRDA installed it does work.
(Debian doesn't currently package it, but I found a source package in
the RFP bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536502
)

However, shouldn't it work without CRDA with
CONFIG_WIRELESS_OLD_REGULATORY=y and ieee80211_regdom=EU?

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[Luis R. Rodriguez]

2010/1/25 John S. Skogtvedt <jss@bzz.no>:
> Gábor Stefanik skrev:
>> On Mon, Jan 25, 2010 at 6:51 PM, Bob Copeland <me@bobcopeland.com> wrote:
>>> On Sun, Jan 24, 2010 at 4:12 PM, John S. Skogtvedt <jss@bzz.no> wrote:
>>>> Hello,
>>>>
>>>> As the subject says, using ath5k on 2.6.32 I am not able to connect to
>>>> an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
>>>> fails to associate). I'm in Norway, and the card is bought in Norway.
>>>> dmesg output:
>>>> [    7.205952] cfg80211: Using static regulatory domain info
>>>> [    7.205956] cfg80211: Regulatory domain: US
>>>> [    7.206243] cfg80211: Calling CRDA for country: US
>>> Well, there's your problem, AFAICT.  You have
>>> CONFIG_WIRELESS_OLD_REGULATORY=y?  And ieee80211_regdom=EU doesn't work?
>>>
>>>> [    7.887265] ath: EEPROM regdomain: 0x80d0
>>>> [    7.887267] ath: EEPROM indicates we should expect a country code
>>>> [    7.887270] ath: doing EEPROM country->regdmn map search
>>>> [    7.887272] ath: country maps to regdmn code: 0x37
>>>> [    7.887275] ath: Country alpha2 being used: DK
>>>> [    7.887277] ath: Regpair used: 0x37
>>>> [    8.288352] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)
>>>> [    8.288607] cfg80211: Calling CRDA for country: DK
>>> Denmark, which should allow the channels in question.
>>
>> However, does the DK regdomain really get set? Is CRDA installed?
>>
>
> Thank you, with CRDA installed it does work.
> (Debian doesn't currently package it, but I found a source package in
> the RFP bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536502
> )
>
> However, shouldn't it work without CRDA with
> CONFIG_WIRELESS_OLD_REGULATORY=y and ieee80211_regdom=EU?

No, Atheros cards by default abide by a custom strict world regulatory
domain if CRDA is not present.

  Luis

Re: Bug: 2.6.32 ath5k, unable to connect to AP on channel 13

[John S. Skogtvedt]

Bob Copeland skrev:
> On Sun, Jan 24, 2010 at 4:12 PM, John S. Skogtvedt <jss@bzz.no> wrote:
>> Hello,
>>
>> As the subject says, using ath5k on 2.6.32 I am not able to connect to
>> an AP on channel 13 (i.e. wpa_supplicant doesn't find the AP and thus
>> fails to associate). I'm in Norway, and the card is bought in Norway.
> 
>> dmesg output:
>> [    7.205952] cfg80211: Using static regulatory domain info
>> [    7.205956] cfg80211: Regulatory domain: US
>> [    7.206243] cfg80211: Calling CRDA for country: US
> 
> Well, there's your problem, AFAICT.  You have
> CONFIG_WIRELESS_OLD_REGULATORY=y?  And ieee80211_regdom=EU doesn't work?
> 

Yes, CONFIG_WIRELESS_OLD_REGULATORY=y. And neither ieee80211_regdom=EU
or ieee80211_regdom=NO works.