Ubuntu does not put 'options mac80211 ieee80211_regdom=64' in /etc/modprobe.d/options

Bug #205095 reported by crackerjackas
22
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Undecided
Unassigned
ubiquity (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I used the Alternate Text Based Ubuntu 32bit 7.10 setup CD ROM.
I applied all the latest updates to 21 March 2008.

I chose English as the language, the first question asked during setup. The second question was:
Ubuntu suggested some English-language dominant countries; I picked Other then selected Germany.

Ubuntu SHOULD have added 'options mac80211 ieee80211_regdom=64' to /etc/modprobe.d/options to enable European ETSI Channel ranges 1-13.

It didn't. I could see with the top-right network icon (nm-applet 0.6.5) all nearby radios, but not connect to, an Open AP on channel 13.

This is a BUG.

Extended Background:
With a built-in MiniPCI radio, a PrismGT Fullmac 54mb/s ISL3880/90 card, the laptop (Sager/Clevo D500P) under Ubuntu could -see- all networks Ch1-13, but could only -connect- to those using channels 1 through 11. In Europe, the channel standards are officially 1,5,9,13; however, since as US so the rest of the world (esp Western Europe), sometimes for bad... 1,6,11 are very commonly used. Sometimes people have bought laptops -in Europe- from major manufacturers (Toshiba) assembled with incorrect radios sku'd for channels 1-11; the Intel 2200BG for example, and -cannot operate- on Channel 12,13 unless the firmware is modded (with linux :).

A open (public-access) AP WLAN operates near the laptop, on channel 13, placing radio signals farther outside of typical interference and traffic zones. In XP, (using the SMC 2802W drivers or others) I could not see the Ch13 AP at all, although many more distant radios (on 1-11) were visible. On Ubuntu 8.04 Hardy Heron, I could see Ch13 AP, however nm-applet (the applet on the top-right for networking) always got stuck attempting to connect (the spin of infinity / death) (21 March 2008).

I joined channel #prism54 on irc.freenode.net. Several pages of conversation took place while users 'linmax' and 'roadi' helped out. While I had 8.04 loaded and problems with the completely broken wireless/wired nm-applet. 'linmax' then tested several of his own fullmac radios on channels 13 and had no difficulties. I erased 8.04 and loaded 7.10. 'linmax' suggested putting 'options mac80211 ieee80211_regdom=64' in /etc/modprobe.d/options. There was an additional common step, i think to update the module cache. I restarted and the radio then connected to Open AP on Ch13.

Revision history for this message
crackerjackas (moc-hooha) wrote :

Prism54 is blacklisted in 8.04. However, prism54 was loaded simultaneously with p54pci and p54common in 7.10 (lsmod output). Prism54 was manually blacklisted in 7.10 as one of the first post-setup 7.10 configuration steps.

Revision history for this message
Andreas Gnau (rondom) wrote :

This problem also occurs when installing from desktop-cd with ubiquity.

Revision history for this message
Colin Watson (cjwatson) wrote :

Marking invalid to get this back down to one bug task, for a reason I'll explain in a moment.

Changed in ubiquity:
status: New → Invalid
Revision history for this message
Colin Watson (cjwatson) wrote :

Actually, reopening. I didn't notice that this is location-sensitive, which means it's hard to do in the kernel. Drat.

Changed in ubiquity:
status: Invalid → New
Revision history for this message
Colin Watson (cjwatson) wrote :

Alexander, could you comment on this bug? I have no idea what this would do to network-manager, and am not qualified to know whether there are corner cases not anticipated by the reporter of this bug.

Is there any chance that we could have this done at the desktop level rather than setting this at install time? I dislike having obscure settings hardcoded in configuration files in /etc when they should be selectable from the desktop in the event that the user does something shocking like moving to a different country. :-)

Revision history for this message
Andreas Gnau (rondom) wrote :

I also thought about that. Indeed network-manager would be the right place for this, because someone who travels back and forth between the US and Europe shouldn't be forced to edit config-files.
Though setting it at install-time is better than working with the wrong setting.

Revision history for this message
Colin Watson (cjwatson) wrote :

Reassigning to network-manager, as discussed; I think presetting this in the installer may well do more harm than good.

Changed in ubiquity:
status: New → Invalid
Revision history for this message
Alexander Sack (asac) wrote :

I haven't looked into the guts of the prism driver. But network-manager doesn't know about all this and afaik doesn't enforce an upper channel bound. So when the drivers do not suffer from this change, we can probably try it. However, I would like to get the kernel teams (subscribed!) input to understand better what the suggested option actually does.

Revision history for this message
Sebastian Bator (eremit7) wrote :

This problem also affects other drivers like at least rt73usb, Intel 3945 or ath5k. A gui in the network-manager to set this commands is highly desirable.

If you are here looking for a solution to your problem note that the mac80211 method no longer works in Intrepid. See the comment on intel 3945 in the release notes instead (https://wiki.ubuntu.com/IntrepidReleaseNotes).

Revision history for this message
Sebastian Bator (eremit7) wrote :

Changes in the wireless stack solved the problem, quite a while ago.

Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.