Description of problem: I noticed in /var/log/messages that CRDA for module cfg80211 is set to country US. I'm pretty sure I selected Belgium as country, when installing this live version. afaik other countries have other regulations eg: the 5GHz range. this would mean some people would not have their wifi working. Steps to Reproduce: 1. install a live version to disk 2. choose a non US country 3. look in /var/log/messages to see CRDA set to US
Priority: Normal => release_blocker
Strange as I have it properly done here: Apr 29 20:52:27 tellure kernel: cfg80211: Calling CRDA for country: FR Can you reproduce that bug ?
CC: (none) => ennael1
In my logs I can see : cfg80211: Calling CRDA for country: FR cfg80211: Regulatory domain changed to country: FR So it seems to be working.
CC: (none) => boklm
ok decreasing priority for now as we cannot reproduce it for now
Priority: release_blocker => High
if i remember correctly, this was produced with a dual arch iso when selecting country BE in summary. perhaps due to missing locales or similar?
can someone try to reproduce with country Belgium?
Maybe relevant https://qa.mandriva.com/show_bug.cgi?id=50115
Source RPM: (none) => crdaKeywords: (none) => NEEDINFO
Have you configured CRDA via draknetcenter -> advanced options?
CC: (none) => eugeni
nope, this is immediately after installation, nothing has been done, even though i did select my country in the installation options. that's the whole point here.
@ AL13N Is this still an issue with the Mageia 1 dual arch?
CC: (none) => marja11
hmm, mageia 1 was released 1st June, my last comment was in July, so yes.
You don't remember using the Mageia 1 dual arch DVD? Even if you did use it, we are waiting for someone to reproduce the bug. If you know any Belgians that are active on Bugzilla, you might want to put them in the cc of this bug
no, i know i retested this using the final dual arch CD (not DVD, there is no dual arch DVD)... finding someone from belgian having a wifi connection... and using mageia and being active on bugzilla... hmmm i'll see what i can find...
Actually this is a bug that has existed for ages. installer sets CRDA according to selected default language, not country.
CC: (none) => tmb
If I read drakx-net correctly, then this is the part screwing up CRDA: sub detect_crda_domain { my $crda = { getVarsFromSh($::prefix . $network_file) }->{CRDA_DOMAIN}; if (!$crda) { my $locale = lang::read($>); my $country = $locale->{country}; if (grep($country, @crda_domains)) { $crda = $country; } else { $crda = "US"; } } $crda; } It does not take into account that the default lang can be different than the real country.
(In reply to comment #14) > If I read drakx-net correctly, then this is the part screwing up CRDA: > > sub detect_crda_domain { > my $crda = { getVarsFromSh($::prefix . $network_file) }->{CRDA_DOMAIN}; > if (!$crda) { > my $locale = lang::read($>); > my $country = $locale->{country}; > if (grep($country, @crda_domains)) { > $crda = $country; > } else { > $crda = "US"; > } > } > $crda; > } > > It does not take into account that the default lang can be different than the > real country. Thanks, Thomas. Assigning to drakx-net maintainer
Source RPM: crda => drakx-netAssignee: bugsquad => mageia
Same issue with Mageia2 alpha2 image - impossible to connect to wireless network because of wrong domain set, have to manually set it using iw The installer queries for the timezone, so the timezone is what should define the region.
CC: (none) => lohmaier+mageiaHardware: i586 => AllKeywords: NEEDINFO => (none)
The code in drakx-net seems fine, it detects crda domain according to country, not lang. Thomas: what do you think is wrong in the code?
Status: NEW => ASSIGNED
a few things I can think of. The above reads locale, wich in my case I set to swedish. then it maps swedish to Sweden, and I get SE as crda domain. But my timezone is Helsinki/Finland. So it could (should?) map according to timezone, not locale. I guess that would cover it to get it correct running livecd (of course if you only set timezone to gmt/utc+X it wont work) When looking on the dvd installer, I guess it misses a few callbacks. when you get to the summary screen, you see in my case it assumes country Sweden according to selected install locale (and crda will be set to SE). So if you alter timezone or country there, it should update crda again according to what is setup there. Does that make sense?
The $locale hash does not only contain the information about the selected locale, $locale->{country} is independent and is guessed according to the selected timezone (at least on live CDs). The behavior in classical install is a bit different, it guesses timezone according to country. Anyway, it should not matter in which order it is done, since the country can always be specified in some way. As you said, the missing point is updating crda after the country is modified. We could do it in lang::write_and_install()
CC: (none) => thierry.vignaud
(In reply to comment #19) > The $locale hash does not only contain the information about the selected > locale, $locale->{country} is independent and is guessed according to the > selected timezone (at least on live CDs). Then this fails "twice". During boot, I set the language to German, the timezone to Europe/Berlin, but the crda domain is set to US. Neither locale, nor timezone is respected. (alpha2, Europe1, GNOME live iso)
(In reply to comment #20) > Then this fails "twice". During boot, I set the language to German, the > timezone to Europe/Berlin, but the crda domain is set to US. > > Neither locale, nor timezone is respected. (alpha2, Europe1, GNOME live iso) Yes, as I said in my previous comment, the CRDA is not updated after the country choice, this should be fixed. Reporters, what is the content of your /etc/sysconfig/i18n file? If you remove the CRDA_DOMAIN= line in your /etc/sysconfig/network file and reconfigure your connection, is the CRDA domain set back correctly?
i'm afraid i can't test easily atm, no wifi
(In reply to comment #21) > > Reporters, what is the content of your /etc/sysconfig/i18n file? [root@acer luzemario]# cat /etc/sysconfig/i18n LC_TELEPHONE=pt_BR.UTF-8 LC_CTYPE=pt_BR.UTF-8 LANGUAGE=pt_BR:pt_PT:pt LC_MONETARY=pt_BR.UTF-8 LC_ADDRESS=pt_BR.UTF-8 LC_COLLATE=pt_BR.UTF-8 LC_PAPER=pt_BR.UTF-8 LC_NAME=pt_BR.UTF-8 LC_NUMERIC=pt_BR.UTF-8 SYSFONT=lat1-16 LC_MEASUREMENT=pt_BR.UTF-8 LC_TIME=pt_BR.UTF-8 LANG=pt_BR.UTF-8 LC_IDENTIFICATION=pt_BR.UTF-8 LC_MESSAGES=pt_BR.UTF-8 Some logs from my wireless setup: Jan 12 23:22:13 localhost kernel: cfg80211: Calling CRDA to update world regulatory domain Jan 12 23:22:13 localhost kernel: cfg80211: World regulatory domain updated: Jan 12 23:22:13 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:13 localhost kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: Calling CRDA for country: BR Jan 12 23:22:13 localhost kernel: cfg80211: Regulatory domain changed to country: BR Jan 12 23:22:13 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:13 localhost kernel: cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:13 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Jan 12 23:22:16 localhost kernel: cfg80211: Calling CRDA for country: US Jan 12 23:22:16 localhost kernel: cfg80211: Regulatory domain changed to country: US Jan 12 23:22:16 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:16 localhost kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Jan 12 23:22:16 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Jan 12 23:22:16 localhost kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:16 localhost kernel: cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:16 localhost kernel: cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:16 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: Calling CRDA to update world regulatory domain Jan 12 23:22:20 localhost kernel: cfg80211: World regulatory domain updated: Jan 12 23:22:20 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:20 localhost kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: Calling CRDA for country: BR Jan 12 23:22:20 localhost kernel: cfg80211: Regulatory domain changed to country: BR Jan 12 23:22:20 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:20 localhost kernel: cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:20 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Jan 12 23:22:20 localhost dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67 Jan 12 23:22:23 localhost kernel: cfg80211: Calling CRDA for country: US Jan 12 23:22:23 localhost kernel: cfg80211: Regulatory domain changed to country: US Jan 12 23:22:23 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:23 localhost kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Jan 12 23:22:23 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Jan 12 23:22:23 localhost kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:23 localhost kernel: cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:23 localhost kernel: cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:23 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: Calling CRDA to update world regulatory domain Jan 12 23:22:26 localhost kernel: cfg80211: World regulatory domain updated: Jan 12 23:22:26 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:26 localhost kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: Calling CRDA for country: BR Jan 12 23:22:26 localhost kernel: cfg80211: Regulatory domain changed to country: BR Jan 12 23:22:26 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:26 localhost kernel: cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:26 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Jan 12 23:22:30 localhost kernel: cfg80211: Calling CRDA for country: US Jan 12 23:22:30 localhost kernel: cfg80211: Regulatory domain changed to country: US Jan 12 23:22:30 localhost kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Jan 12 23:22:30 localhost kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Jan 12 23:22:30 localhost kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Jan 12 23:22:30 localhost kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:30 localhost kernel: cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:30 localhost kernel: cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Jan 12 23:22:30 localhost kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) Jan 12 23:22:32 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 ... and so on. Wireless is always deautenticated from AP by reason "2" between country changes in a endless loop. When I manually have set my AP to BR (it was previously set to US) everything worked. > If you remove the CRDA_DOMAIN= line in your /etc/sysconfig/network file and > reconfigure your connection, is the CRDA domain set back correctly? I could not fully test it. After I changed back my AP to US the country also changed to US and stayed there. CRDA_DOMAIN= line had effect only after disconnecting (i.e. country has changed back to BR). Following attempts to connect changed to US when needed then back to BR when not connected (expected). CRDA_DOMAIN= seems to be working.
CC: (none) => luzemario
CRDA_DOMAIN= makes no difference with CRDA changing bug. It is still changing, despite it is set to US or not. I set my AP to country BR, cfg80211 still keeps changing country from 'BR' to 'BR'.
Blocks: (none) => 5015
Luzemário Dantas: your bug is likely bug 3344
Summary: CRDA set to wrong country => CRDA set to wrong country after installation from live CD
the router/access point changes the CRDA country of associated clients automatically to it's own regulatory country. usually this is not a big problem unless there one owns a router like mine, which allows selecting channel 13 but still reports country US... dmesg looks very similar like in comment 23, in that case an ethernet cable is your friend ;-) usually wifi cards are in "world" regulatory domain, that means only channels available in the FCC world AND the CEPT AND Japan are allowed to be scanned actively (=transmit while not associated to an AP), all other channels are only allowed for passive scanning. that means even you have your card set to US once you scan a beacon of an EU or JP accesspoint, this will "lift" your cards reg dom to the APs one allowing transmit. another quite big problem is that the CRDA country channel lists are not very accurate, for me it makes often more sense using DE instead of CH, even the regulations in both countries are mostly identical, maybe this is also the case with BE?
CC: (none) => smiling.diego
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=3799
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
not gonna be fixed in 2 likely
Keywords: NEEDINFO => (none)
@blino @tmb did this code modification get in there?
It happens in Mageia 4 beta 2 live KDE 64 bits. I selected spanish as country but the code is set to US
CC: (none) => periliocastrol
(In reply to Perilio Castrol from comment #30) > It happens in Mageia 4 beta 2 live KDE 64 bits. I selected spanish as > country but the code is set to US valid for pre-4RC live CDs, too, but the 3rd round KDE Live DVD was OK, even if there in the network center the Wireless regulatory domain seemed to be set to US, too: local networks on channel 13 are seen :-) for the CDs: When I pick Amsterdam as timezone, some local networks on high channel numbers can't be seen. After changing the Wireless regulatory domain in "Network Center" --> "Advanced settings" to NL, it works fine.
Whiteboard: (none) => 4RCCC: eugeni => qa-bugs
@ tmb @ blino would it be possible to set the wireless regulatory domain for the LiveCDs to GB by default, instead of to US ? IINM that would solve this issue (except maybe for some Japanese users).
pre-Mageia-4-RC-LiveDVD-KDE4-x86_64-DVD.iso round 6 is affected, too, btw, I don't know what changed since round 3 With the round 3 DVD, after choosing Amsterdam as timezone while booting into a live session, it would see WAPs on channel 13, even if the wireless regulatory domain showed "US", but now it won't show those access points anymore, until US is changed to NL
Summary: CRDA set to wrong country after installation from live CD => CRDA set to wrong country after installation from live CD and with Live session (liveCD/DVD)
confusingly, with the round 6 LiveKDE CD, after choosing London as time zone, and in spite of the setting showing as "US", those channel 13 WAPs are seen
CC: boklm => (none)
Is this still an issue?
Did you've a CRDA value in /etc/sysconfig/network?
Created attachment 6708 [details] set CRDA_DOMAIN when chaning country Blino, I choosed to set CRDA_DOMAIN in write() instead of write_and_install() so that it works too when one changes country in localedrake.
Keywords: (none) => PATCH
(In reply to Marja van Waes from comment #34) > confusingly, with the round 6 LiveKDE CD, after choosing London as time > zone, and in spite of the setting showing as "US", those channel 13 WAPs are > seen Same with QA Mga5final Live KDE CD of Sat May 23 02:00:00 CEST 2015 in Live mode (after selecting Amsterdam as time zone), channel 12 and 13 WAPs are seen. (In reply to Thierry Vignaud from comment #36) > Did you've a CRDA value in /etc/sysconfig/network? It says: CDRA_DOMAIN=US (I'll check the other lives if I find time)
Mageia-5-LiveDVD-KDE4-x86_64-DVD of Wed May 27 12:30:00 CEST 2015 Live mode, selected: Dutch language Amsterdam timezone Dutch keyboard Channel 12 and 13 WAPs are _not_ visible, /etc/sysconfig/network has CDRA_DOMAIN=US After changing the Wireless regulatory domain in "Network Center" --> "Advanced settings" from US to NL, they become visible /etc/sysconfig/network now has CRDA_DOMAIN=NL
Mageia-5-LiveDVD-GNOME-x86_64-DVD.iso Wed May 27 12:30:00 CEST 2015 Live mode All settings Dutch/Amsterdam Again the high channels are not visible /etc/sysconfig/network has CDRA_DOMAIN=US Changing the Wireless regulatory domain to NL fixes the problem again
Mageia-5-LiveCD-GNOME-en-i586-CD Sat May 23 02:00:00 CEST 2015 Live Mode Timezone Amsterdam /etc/sysconfig/network has CDRA_DOMAIN=US However, the WAPs on channel 12 and 13 are visible, and connecting to an access point on channel 13 is possible without changing the CDRA_DOMAIN
CC: luzemario => (none)
Mageia-5-LiveDVD-GNOME-i586-DVD.iso Wed May 27 00:45:00 CEST 2015 Same as the 64bit LiveDVDs: this bug is valid in both ways (CDRA_DOMAIN=US while everything was set to Dutch/Amsterdam, and the high channel WAPs are invisible)
Mageia-5-LiveDVD-KDE4-i586-DVD.iso Wed May 27 00:45:00 CEST 2015 Same as the other 3 Live DVDs I didn't mention that for the LiveCDs (where selecting Dutch as language was impossible) I selected the English variety at the top of the list (just "English")
(In reply to Marja van Waes from comment #43) > Mageia-5-LiveDVD-KDE4-i586-DVD.iso > Wed May 27 00:45:00 CEST 2015 > > Same as the other 3 Live DVDs > > I didn't mention that for the LiveCDs (where selecting Dutch as language was > impossible) I selected the English variety at the top of the list (just > "English") However, selecting the same English when using the LiveDVD-KDE4-i586-DVD, does not make a difference: the WAPs on high channels remain invisible. I don't have a clue why the CDs ignore the CDRA_DOMAIN=US setting.
live-DVD was no problem, but classical installer DVD doesn't allow to configure CRDA / connect to one of the additional networks during installation (you can configure your Network "blind", and have it working after installation is finished, but getting updates during install of course is not possible
Is this bug report still valid for Mageia 6?
(In reply to Samuel Verschelde from comment #46) > Is this bug report still valid for Mageia 6? My guess is yes, based on bug 18935. What is odd, I get and not configured message once in awhile upon boot. In my case configuration files was not set.
CC: (none) => bittwister2
Hi, This is High priority bug for a good reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please make the status to Assigned when you are working on this. Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it. On October 1st 2020, we will drop priority to normal.
crda is gone from Mageia 8. Closing.
Status: ASSIGNED => RESOLVEDResolution: (none) => OLD
removal of crda/reading the list of valid frequencies for regulatory.db is completely orthogonal to the problem of not being able to *configure* or specify the domain the installer should use to make those frequencies available. I'll see once mga 8 is released whether the problem is fixed, but if it is then not because crda udev-helper is gone.