iwlagn driver fails to find 5GHz draft-N access point with CONFIG_WIRELESS_OLD_REGULATORY=n for all intel wireless cards

This may well be related to the CRDA integration being discussed on bug #288401. It is likely worth tracking the progress there.

I tried adding:

options cfg80211 ieee80211_regdom=EU

on my Thinkpad X200 with Intel 5300. Makes wireless stop working altogether, with the following log output:

"cfg80211: Unknown parameter `ieee80211_regdom'"

So the workaround from bug #288401 doesn't seem to be applicable here.

This problem effects all cards using the iwlagn driver. Which is basically all intel cards. I am seeing this on a 4965 & a 5350 Intel wireless cards.

Add a little more so. As described in the initial report. Any Intel Wirless card can nolonger see an 802.11a or 802.11n access point that is using the 5GHZ band.

I have confirmed this on a Thinkpad T61 with an 4965agn card and a Thinkpad x301 with an 5350 card.

Do we know why CONFIG_WIRELESS_OLD_REGULATORY was switched to "n" as opposed to "y"?

For now it is causing a regression, that is not fixed for this case even in the upstream 2.6.29 kernel for the iwlagn driver.

The regulatory setting changed to N as we now have the CRDA userspace installed which is meant to take over from the in kernel settings. This is most likely an interaction between the kernel and the wireless-crda package.

So how does one set the regulatory domain without iw (which isn't packaged in ubuntu repos) or wpa_supplicant, which is a version behind that which is needed for this functionality (needs 0.6.7)?

This issue is believed to stem from an error in the CRDA database. We are expecting to pick up an updated version shortly to fix this issue.

These links shed more light on the problem. Looks like Intel may not support CRDA for 5GHZ band till 2.6.29.

This thread sheads some light:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-10/msg11126.html

http://marc.info/?l=linux-wireless&m=123510990625914&w=2

http://osdir.com/ml/linux-wireless/2009-02/msg00776.html

Can confirm as of March 12th updates with kernel 2.6.28-9 that it now works fine with a 5350 card. So I connect to 5GHZ AP fine.

I also confirmed things are now working fine with the 4965.

Confirmed working on Thinkpad X200 with 5300 card.

Confirmed now working fine with 5100 card as of march 12th update.

Still doesn't work for me with kernel 2.6.28-9.31 and wireless-crda 1.7.Tried both a 5GHz draft-N access point (Netgear WNHDE111) and a 802.11a AP (Cisco Aironet 1220A). Neither of them is discovered unless I recompile the kernel with CONFIG_WIRELESS_OLD_REGULATORY=y. Both AP's were designed for ETSI frequencies. My laptop was sold in the US, so it probably gets the regulatory information from nearby access points.

Just as an update, I have a D-link DIR-855 purchased in Europe (I have not updated the firmware so it should be the local one) and a Thinkpad X200 with Intel 5300 purchased in the US, and it works properly for me.

I'm using a Linksys WRT600N purchased and used here in the US. Using a Thinkpad T61 with a 4965 card & a Thinkpad x301 with 5350 card. Both connect to 5GHZ range without issue using 802.11n.

@Alson
          What Intel wireless card are you using?

@Alson
                 Nevermind my first question. You reported the initial bug. I actually have a Netgear WHDE111 I will try in access point mode later this week. Though it is US.

@All -- we are expecting passive scanning to work on the N bands now following an update to the wireless CRDA database as released in the wireless-crda 1.7 upload. Could those of you affected by this on Jaunty please confirm whether this is installed and whether things work as expected with it installed.

@All -- any chance you could test with the kernels in the latest Jaunty release.

Still doesn't see my WNHDE111 with kernel 2.6.28-11.37 (amd64) and wireless-crda 1.7.

@Alson -- could you get me the dmesg output from the test kernel, and also confirm where in the world you want your machine to think it is.

Here's a fresh dmesg, more information like lspci output is in the initial bug report. I am in the Netherlands (ETSI region), both AP's I tested were sold here (I can select a country on the WNHDE111, this is set to NL, too), and set to automatically choose a free channel. Both AP's are discovered with pre-crda kernels (2.8.28-3 or so) and Windows. I'm not sure if it detects any 5GHz AP, I'll try to find overlapping channels between US and ETSI spectrums and see if that works.

Is there any way to see which regulatory domain was selected? It seems that iw only provides a reg set, no reg get command. iw reg set NL fixes it, but it's definitely a step back from working out-of-the-box like it did before crda.

The output after iw reg set:
[ 1274.636780] cfg80211: Calling CRDA for country: NL
[ 1274.675326] cfg80211: Regulatory domain changed to country: NL
[ 1274.675334] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 1274.675340] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1274.675345] (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1274.675349] (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 1274.675353] (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[ 1376.821314] wlan0: authenticate with AP 00:1e:2a:de:14:bd
[ 1377.020556] wlan0: authenticate with AP 00:1e:2a:de:14:bd
[ 1377.021019] wlan0: authenticated
[ 1377.021025] wlan0: associate with AP 00:1e:2a:de:14:bd
[ 1377.021845] wlan0: RX AssocResp from 00:1e:2a:de:14:bd (capab=0x111 status=0 aid=1)
[ 1377.021851] wlan0: associated

@Alson -- I believe that there is work afoot to help with this. To automate at least the "where you are normally" part of the issue. For the kernel side of things we have as much as we can within the requirements of having CRDA so I will therefore mark this Fix Released in wireless-crda.

Fixed in 2.6.30