Various wireless drivers don't see !US wireless channels on UK laptop [intrepid regression]

Setting importance to High since wireless cards are a core component and non-US is a major portion of users.

The only proper fix I can see for this is to have some kind of preference in something like Network Manager. It would have to be a user configurable setting because many people take their laptops to other countries which have different channel options. I guess it could also be possible to link it to the Locations for the clock. Or even a separate mini-system configuration GUI util.

I am disappointed that this was set to low importance in Bug #272407. It is a serious regression for European laptop users, I would have thought this group of users to be of a least a little importance.

The very least that could be done is to document the temporary fix in Bug #272407 so that when it hits mainstream users they will know how to fix it.

Sorry Linuxjedi - I set the importance on the original bug quite early on, without truly understanding the full impact. In hindsight, it was not the correct decision

This is a regression because of the new regulatory infrastructure in the kernel. The regulatory domain should be automatically set, either based on information from your access point or your wireless cards EEPROM (or at least that is what I understand from reading http://wireless.kernel.org/en/developers/Regulatory/CRDA). In cases where this fails, it appears that the workaround documented in this bug report is needed.

If this regression is affecting a lot of non-US users, it may warrant a release note entry.

Ah, thanks for this Chris, yes your interpretation of this document makes sense. The impact of this bug may be lower than I originally anticipated then.

It may warrant some documentation somewhere (I would certainly appreciate it when helping fellow Ubuntu users). I would imagine people in Europe will try and take advantage of channel 13, and it appears to affect this particular model of wifi chip more than most. It will be tricky to estimate impact because it depends on several factors (chip firmware and local access points mainly).

Thanks again for looking into this.

Its likely that older Access Points are not broadcasting a regulatory domain information element in the beacon, or have not been configured for operation outside of the US. In either case, I imagine most US manufacturers of wireless adapters default to the US channel set.

Release notes text added:

== Only US wireless channels enabled by default on Intel 3945 ==

The iwl3945 wireless driver defaults to the US regulatory domain for wireless, so wireless networks on channels forbidden by US regulations but permitted by European or Japanese regulations will not work out of the box. This affects IEEE 802.11b/g channels 12 (Europe and Japan), 13 (Europe and Japan), and 14 (Japan only), as well as all 802.11a channels. (Some other wireless drivers may be affected; this is the only one we are sure of so far.)

To work around this, add the following line to the `/etc/modprobe.d/options` file if you use this driver and need to use European wireless channels: {{{
options cfg80211 ieee80211_regdom=EU
}}}

Alternatively, add the following line if you use this driver and need to use Japanese wireless channels: {{{
options cfg80211 ieee80211_regdom=JP
}}}

@James - if possible it would be interesting to see if the iwl3945 has problems associating on channels 12 and 13 when other wireless adapters do work, such as iwl4965.

I've got a similar problem with channel 13.
I can't join ibss networks (ad-hoc) on channel 13, so I
tried to add options cfg80211 ieee80211_regdom=JP and options cfg80211 ieee80211_regdom=EU to /etc/modprobe.d/options,
but it doesn't work.
dmesg says:
WARNING: at /build/buildd/linux-2.6.27/net/mac80211/main.c:987
eth1: IBSS not allowed on frequency 2472 MHz
The full demsg output as attachment, hope it helps...

Best Regards

Andreas

Tim Gardner <email address hidden> writes:

> @James - if possible it would be interesting to see if the iwl3945 has
> problems associating on channels 12 and 13 when other wireless adapters
> do work, such as iwl4965.

The WAP in question is my home WAP; so this isn't trivial to test (as
opposed to if it were a WAP in the office, f.e.), but I'll see if I
can find a non-iwl3945 laptop to test with.

--
James

the workaround does not work for me.

Why did you change the ubuntu-release-notes task to Invalid? Please be more specific - what doesn't work for you?

@Chris

This Workaround does not work as aspected i tried options cfg80211 ieee80211_regdom=EU
and also options cfg80211 ieee80211_regdom=JP

i can find now non us channel but can´t join them
dmesg says:
WARNING: at /build/buildd/linux-2.6.27/net/mac80211/main.c:987
eth1: IBSS not allowed on frequency 2472 MHz
More dmesg output:
http://launchpadlibrarian.net/19230400/wlan-dmesg.txt

sorry for changing ubuntu-release-notes to invalid, may iam not familar enough with the status thing..

Thanks in advanced

Andreas

I live in the UK and I had a similar problem to this with the b43 driver. It took me a very long time to work out what the issue was. There definitely needs to be a GUI to set/override the location (both for when it is determined wrongly and for when people move from one geographical location to another).

By the way, prior to Intrepid, the connection process failed mysteriously half-way through. At Intrepid, it didn't list the network n the disallowed channel.

Another option to try is to install linux-backports-modules-2.6.27.

No, linux-backpors-modules also need the patch
lbm_cw_cfg80211 ieee80211_regdom=EU
(On my computer with intrepid at least)

This is a complex issue as there clearly has to be a userspace framework to support the new regulatry infrastructure. This project is the topic for the Jaunty UDS.

This bug was reported in the Intrepid development cycle; removing regression-potential and marking as regression-release.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I too have the same issue in Europe with the b43 driver in Intrepid. Should be b43 driver issue be filed as a separate bug?

Creating /etc/modprobe.d/wireless with the following line allows connecting to all allowed channels(after a reload of modules).
options lbm_cw_cfg80211 ieee80211_regdom=EU

I am on jaunty and have the same problem with iwlagn driver - Intel Wireless link 5100 AGN driver. I've tried using iw to set to no avail. At the moment am having to live without channels 12 and 13 until this is resolved.

The work-around for Intrepid is to assign the module parameter ieee80211_regdom as described below:

# /etc/modprobe.d/regdom
options cfg80211 ieee80211_regdom=EU
options lbm_cw_cfg80211 ieee80211_regdom=EU

Jaunty ought to be working correctly with the CRDA udev agent for those drivers that support regulatory_hint().

As per the answer I was given on https://answers.launchpad.net/ubuntu/+question/62114 ,
the only way I currently know to re-enable the channels - on jaunty anyway - is to get this working was to compile iw from source and manually pass the country code. The only version of iw that i could see within the existing repositories (as part of aircrack-ng) is out of date, does not appear to report a version and silently ignores the same request to change regulatory domain.

Shouldn't the appropriate location code be entered from the system country settings at install time (or whenever they are changed) and passed through to the driver?
I'm not technical enough to understand how the new setup is meant to work, but the problem is that these are relatively new cards and this is only going to result in more support requests in the future as these Intel cards hit the mainstream and come into contact with lay users like myself - at least until NetworkManager catches up to having a country selector. The wpa_supplicant method of changing requires v 0.6.7 which is not yet available through Jaunty.

If this should be raised as a separate bug/request - then I defer to your judgment.

 A kernel config option for cfg80211 has changed in one of the recent Jaunty alpha kernel or module releases which disabled the "legacy" options cfg80211 ieee80211_regdom=EU method. Now that the CRDA method is in place there is no way of passing the region to the module without a git version of wpa_supplicant or a recent iw which is not yet packaged for debian/ubuntu (https://bugs.launchpad.net/bugs/321630) as far as I can tell. Compiling iw from http://wireless.kernel.org/download/iw/ works to set the parameter per session, but a way of setting this persistently or via the timezone and with actual ubuntu packages would be nice!

Most of the info regarding the new behaviour is at: http://wireless.kernel.org/en/developers/Regulatory/CRDA and http://wireless.kernel.org/en/users/Documentation/iw has info regarding the iw tool I used to get my channel 13 back!

This may also be triggering the inability to bind to 8.0.2.11n channels as reported in bug #331092.

I am the submitter of bug #331092, this definitely seems related. It works without manually specifying the regulatory domain with CONFIG_WIRELESS_OLD_REGULATORY=y (no CRDA), so even a GUI config tool or guessing based on timezone would be a regression as far as I'm concerned. My laptop is from the US, so it seems unlikely that the EU domain is set in the firmware. I believe that my AP does broadcast it, I have the option to specify the country in the AP administration interface. This apparently isn't picked up with CRDA.

"CONFIG_WIRELESS_OLD_REGULATORY=y (no CRDA)" Thanks Alson, that is exactly the kernel config change I was referring to. It seems that this and therefore the CRDA stuff has been implemented before a method of switching domains has been implemented to support this change!

@All -- we are expecting that the correct band selection should occur with the latest 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. If it does not would you also try testing using the new regulatory override:

    sudo iw reg set <country code>

Where country code is your ISO two letter country code, eg GB for the UK.

Could you please report back here.

After installing Alpha6 and all updates (wireless-crda automatically installed) the laptop can now connect to channel 13 here in switzerland.

Looks good.

I can now access channels beyond 11 with iwlagn driver - Intel Wireless link 5100 AGN - since the March 12th CRDA updates.

It also worked for me(iwl3945) with the lastest update.

Based on feedback from testers marking this FIx Released.

This is still a problem in linux-backports-modules version 2.6.28-11.12. How do I add a task for this?

Opened l-b-m-2.6.28 task.

In brief, the problem (for me, using the ath5k driver, on an Acer Aspire One) is that whilst the standard Jaunty kernel properly detects UK hardware and enables the non-US channels, the linux-backports-modules variant of the wireless modules go into the US regulatory domain by default, and connection to my channel 13 AP fails. (Use of modparam ieee80211_regdom=GB or "iw reg set GB" allows connection.)

Please see dupe bug 349001 for my dmesg snippets, and for the second user confirmation to justify setting this task to Confirmed status.

So after some people reported that alpha6 can now connect channel 13 i tried alpha6 and the beta release...
I found now my IBSS Mesh Network on channel 13 but still can't connect :(

I also tried to set the regulation domain, but it doesn't work ...
Same error as bevore:

[ 86.055623] cfg80211: Calling CRDA for country: AT
[ 86.060727] cfg80211: Regulatory domain changed to country: AT
[ 86.060732] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 86.060738] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 86.060742] (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 86.060747] (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 86.060751] (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[ 102.527980] wlan0: disassociating by local choice (reason=3)
[ 102.559909] wlan0: Selected IBSS BSSID 26:a7:d4:e4:4f:4d based on configured SSID
[ 102.560905] wlan0: IBSS not allowed on frequency 2472 MHz

@infocreator:

This bug relates to lack of automatic selection of the proper regulatory domain. Your problem is the driver refusing to perform IBSS on channel 13 after a correct regulatory domain has been configured, so is completely unrelated. Please file a separate bug. Please remember to identify whether you are using the linux-backports-modules variant of the wireless stack (in which case your bug should be filed against the "linux-backports-modules-2.6.28" package) or not (in which case your bug should be filed against the "linux" package). Ideally, try it both ways (by installing linux-backports-modules-jaunty to switch to backports / completely uninstalling all linux-backports-modules-* packages to switch away from it).

@Max Bowsher

I see infocreator has filed bug 363379, as you requested. However, the bug has had no comments or status changes.

I'm seeing the same problem, so I'm keen to see a resolution, and happy to test any fixes or workarounds.

Meanwhile, I'm adding this comment so that any readers can easily find the bug infocreator filed from this bug.

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug is still marked as confirmed in later versions of Ubuntu.

This still doesn't work. The workaround is ignored.

[ 14.718602] iwl3945 0000:03:00.0: Tunable channels: 11 802.11bg, 13 802.11a channels
[ 14.718608] iwl3945 0000:03:00.0: Detected Intel Wireless WiFi Link 3945ABG
[ 14.718771] iwl3945 0000:03:00.0: irq 46 for MSI/MSI-X
[ 14.736317] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain

I'm using Natty.

At Brazil also happens this unfortunately.
I have Ubuntu 14.04 and my network is at channel 13 and it's impossible
i change the channel,
 a have tried using:
options cfg80211 ieee80211_regdom=EU
With 'EU' 'UK', 'BR' and other methods that i have found on the
internet but nothing have work,
while this I have to continue using Windows.