Wifi driver will fail to load if regulatory domain set in module options

[TJ]

In Jaunty, up to and including 2.6.28-7, if the Wireless network regulatory domain needed setting manually for non USA regions such as the European Union (EU) or Japan, an option was added for the cfg80211 module in /etc/modprobe.d/options.conf:

 options cfg80211 ieee80211_regdom=EU

The kernel build config used:

 CONFIG_WIRELESS_OLD_REGULATORY=y

In Ubuntu-2.6.28-8.21 the wireless-crda package was introduced to work with udev to set the regulatory domain automatically. Therefore the manual override was no longer used and the kernel build config changed to:

 # CONFIG_WIRELESS_OLD_REGULATORY is not set

However, if the manually added module option was left in place it causes cfg80211 to fail to load, which in turn causes the wireless drivers to fail to load too:

kernel: [ 379.889060] cfg80211: Unknown parameter `ieee80211_regdom'

sudo modprobe iwl3945
WARNING: Error inserting led_class (/lib/modules/2.6.28-9-generic/kernel/drivers/leds/led-class.ko): Unknown symbol in module, or unknown parameter (see dmesg)
WARNING: Error inserting mac80211 (/lib/modules/2.6.28-9-generic/kernel/net/mac80211/mac80211.ko): Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting iwl3945 (/lib/modules/2.6.28-9-generic/kernel/drivers/net/wireless/iwlwifi/iwl3945.ko): Unknown symbol in module, or unknown parameter (see dmesg)

The solution is to remove the module option, e.g:

sudo sed -i '/options cfg80211/ s/^.*$//' /etc/modprobe.d/options.conf

[Andy Whitcroft (apw)]

As Jaunty users are all volunteers it might be reasonable to expect them to cope and remove it. However this has also affected Intrepid so those upgrading from there might need something to help them remove those options.

[Andy Whitcroft (apw)]

We should release note the fact that we are now using CRDA and that anyone using the module option to set their registry domain as below:
 options cfg80211 ieee80211_regdom=EU

[Andy Whitcroft (apw)]

... needs to remove that to allow the module to load. They should probabally be pointed to the command replacement:

    iw reg <country>

[Andy Whitcroft (apw)]

Something like this:

The Jaunty release now enables the CRDA wireless regulatory framework.
This controls which wireless channels are usable and visible in a
particular location. If you previously had to use the module option
similar to that below in /etc/modprobe.d/options to allow access to
certain channels in your locality then you may find that wireless will
not function at all:

    options cfg80211 ieee80211_regdom=EU

If this option is present it should be removed prior to the upgrade.

[Andy Whitcroft (apw)]

Following discussions we believe that people who added this option should be aware it is there. Therefore it is most likely sufficient to release note the issue including the symtoms. Therefore closing this Won't Fix.

[TJ (tj)]

Actually I think there's a wider issue here - modprobe failing due to unsupported module options provided by configuration, kernel or modprobe command-lines.

I can envisage other scenarios where a change in the kernel build configuration removes the availability of a module parameter and causes other modules to fail to load.

It's trivial for modprobe to check the options against what the module supports and instead of failing, simply warn about the unsupported option but continue to load the module without the unsupported option.

Attaching a debdiff for module-init-tools to achieve this.

[Scott James Remnant (Canonical) (canonical-scott)]

It isn't trivial, it's extraordinarily expensive - we run modprobe several hundred times during a normal boot, having to check the module options against the module would add a significant penalty!

[Scott James Remnant (Canonical) (canonical-scott)]

It isn't trivial, it's extraordinarily expensive - we run modprobe several hundred times during a normal boot, having to check the module options against the module would add a significant penalty!

A better approach would be to check the options at depmod time

[Andy Whitcroft (apw)]

We might consider a hybrid approach. Attempt to insert the module without any checks. If the insertion fails, then sift the module options, if that then changes the options, retry the insertion. That would limit the cost to only those modules which fail to install perhaps?

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-03-21 at 11:06 +0000, Andy Whitcroft wrote:

> We might consider a hybrid approach. Attempt to insert the module
> without any checks. If the insertion fails, then sift the module
> options, if that then changes the options, retry the insertion. That
> would limit the cost to only those modules which fail to install
> perhaps?
>
I'd say that if the options were wrong, you want to fail the module load
and have somebody sort out the options - since if the module is loaded
with the wrong options, it's not going to function as expected.

Scott
--
Scott James Remnant
<email address hidden>

[TJ (tj)]

On Sat, 2009-03-21 at 10:48 +0000, Scott James Remnant wrote:
> It isn't trivial, it's extraordinarily expensive - we run modprobe
> several hundred times during a normal boot, having to check the module
> options against the module would add a significant penalty!

I've not been able to detect even a millisecond of difference using the
patched modprobe.

The code only performs if options are being passed. If they are, the
already memory-mapped module image's .modinfo section is located and for
each "param=" the name is checked against the final list of options. If
the parameter occurs in the options it is kept. Any options not matched
are dropped.

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-03-21 at 11:49 +0000, TJ wrote:

> On Sat, 2009-03-21 at 10:48 +0000, Scott James Remnant wrote:
> > It isn't trivial, it's extraordinarily expensive - we run modprobe
> > several hundred times during a normal boot, having to check the module
> > options against the module would add a significant penalty!
>
> I've not been able to detect even a millisecond of difference using the
> patched modprobe.
>
> The code only performs if options are being passed. If they are, the
> already memory-mapped module image's .modinfo section is located and for
> each "param=" the name is checked against the final list of options. If
> the parameter occurs in the options it is kept. Any options not matched
> are dropped.
>
I think this is dangerous - for example what if the option was to
correct a security issue? Dropping the option would expose the hole
again, you want the module load to fail and somebody to resolve the
issue.

Scott
--
Scott James Remnant
<email address hidden>

[TJ (tj)]

On Sat, 2009-03-21 at 12:55 +0000, Scott James Remnant wrote:

> I think this is dangerous - for example what if the option was to
> correct a security issue? Dropping the option would expose the hole
> again, you want the module load to fail and somebody to resolve the
> issue.

I see the point but I think it can be argued both ways. Take for example
the original reason for my report - the network driver failing to load.

It caught me out initially because to begin with I thought it was 'just
another NetworkManager issue' and sighed resignedly. If I were a typical
non-technical end user I'd have been stuck.

A non-technical user would have been left with no network access and no
way to do any kind of basic search on-line that might have helped them
discover the solution.

As it was I switched to a console and did "lsmod | grep iwl" and was
further confused that the module hadn't loaded. That led to me trying to
manually load it (which implies knowing how to use modprobe and which
module file-name) and getting the cryptic:

Unknown symbol in module, or unknown parameter (see dmesg)

If I were an non-technical end-user I would likely have no idea what
'dmesg' was or how to 'see' it. Also, I support countless end users that
don't even appreciate that /var/log/* exists or what all the files there
contain and would have no idea of how to look for that innocuous
looking:

cfg80211: Unknown parameter `ieee80211_regdom'

The message doesn't suggest a major issue as, for example, a PANIC would
and is easily missed in the noise of other messages.

As Andy points out there could be issues with Hardy/Intrepid > Jaunty
dist-upgrades once Jaunty is released, but my concern is that users will
be left unexpectedly high-and-dry and likely extremely frustrated.

Maybe we could modify my approach in some way and make use of the new
notify-osd for desktop users at least? Maybe capture output from
modprobe into a boot-time log-file and, if it contains any issues, bring
them to the attention of the user? With that you continue failing the
module load but use my patch mechanism to capture the reason why?

[Michael Mauch (michael-mauch)]

As TJ pointed out, this is primarily a problem with upgrading to Jaunty for non-technical users, perhaps leaving them without net.

Couldn't the upgrade process just comment this parameter like it's done with the mouse and keyboard lines in xorg.conf?

[Steve Langasek (vorlon)]

Added to the release notes at <https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes#Setting%20wireless%20regulatory%20domain%20via%20module%20option%20no%20longer%20supported>:

Ubuntu 9.04 enables the CRDA wireless regulatory framework for controlling which wireless channels are usable and visible in a particular location. If you previously had to use the module option similar to that below in /etc/modprobe.d/options to allow access to certain channels in your locality then you may find that wireless will not function at all:

    * options cfg80211 ieee80211_regdom=EU

You should remove this kernel module option on upgrade to Ubuntu 9.04 and use the iw reg command instead.

[Scott James Remnant (Canonical) (canonical-scott)]

Marking as Won't Fix; modprobe should fail if unknown options or option values are given.

[Alex Cockell (alcockell)]

Umm- what about us preinstall users?

I bought my Thinkpad R61i preinstalled from Linux Emporium - and would not feel comfortable if on a critical update, it broke.

Which is what an end-user like me will think.

PLEASE don't cause someone like me to have to send my primary machine across the country to my vendor to be fixed if you suddenly kill networking from under me...

Or - at least present a menu or something on setup...