[SOLVED] Issue with loading regulatory.db at boot

Cbhihe · 2019-04-25 11:00:46

[5.0.9-arch1-1-ARCH]

Examining logged kernel messages right after boot, I see the two consecutive lines:

[    2.505562] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    2.505564] cfg80211: failed to load regulatory.db

I looked up topics and contents of post on this BBS and elsewhere, containing: failed AND load AND regulatory.db.
There is a lot of stuff out there, but I am no closer to finding out why regulatory.db failed and how to fix it.

Last edited by Cbhihe (2019-04-25 15:44:29)

loqs · 2019-04-25 11:07:59

Respecting_the_regulatory_domain. wireless-regdb provides regulatory.db and is a dependency of crda.

Cbhihe · 2019-04-25 12:26:26

I do not have the agent core/crda installed, and:

$ iw reg get
global
country 00: DFS-UNSET
        (2402 - 2472 @ 40), (6, 20), (N/A)
        (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
        (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
        (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
        (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
        (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
        (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
        (57240 - 63720 @ 2160), (N/A, 0), (N/A)

I also checked that for my Atheros interface device:

 $ dmesg | grep ath:
[    3.269711] ath: Country alpha2 being used: 00

Default setting is 00 for global, while I'm in western Europe.
(Could that begin to explain why my WiFi connection *always* tops at 1Mbps, even as I sit next to the access point.)

I installed crda (and dependency wireless-regdb), uncommented the appropriate region in /etc/conf.d/wireless-regdom and will reboot now...

Cbhihe · 2019-04-25 12:35:02

$ iw reg get

gives me the right country (although the question here becomes what if I travel to a different country tomorrow, do I need to change this by hand every time I hop in and out of a plane ?), and the original messages in dmesg are gone.

So that's that, but

 dmesg | grep ath:

seems to be stuck on '00'.

Last edited by Cbhihe (2019-04-25 15:52:24)

seth · 2019-04-25 13:05:13

If you legally bought the NIC in your regulatory domain ("Country") you don't have to do *anything* - just ignore the message, it's irrelevant.

If you want to tamper w/ the regdb, eg. because you're legally required to adapt to the reg domain (and accordingly configured router) in a different country, you'll have to install and enable crda (same goes for all other, not so legal reasons) and load the proper configuration for the reg domain you enter, yes.
Luckily the differences are not that massive, esp. on the 2.4GHz band, https://en.wikipedia.org/wiki/List_of_WLAN_channels (pay attention to TX power limitations, though)

You're oblieged to use legal channels, whether or not this is driven by a correct database entry, let alone w/ the proper 2-letter country code is completely irrelevant.

So, to sum up:
If you stay at home, don't worry, all is fine as it came out of the box (unless the box fell of a chinese truck ;-)
If you travel around, the easiest solution is crda and configure the correct reg domain - obviously using eg. geoip to configure that automgically is not a perfectly legal solution, since you first need an IP to figure your location ;-)

Cbhihe · 2019-04-25 15:43:57

Seth:
;-))) Unfortunately my box did NOT fall off the back of a truck. It would have been significantly cheaper... It was made in China and so was its Qualcom ATH10k wifi device, but yes legally imported and sold to me in Europe.

So maybe that is the reason it was set to '00' by default, probably in an EEPROM directly on device. I'm only guessing here, based on the fact I cannot change the '00' value associated to my Atheros wifi device.)

That is inconvenient because I do travel and I'd like to take advantage of the fact that Tx power limits are higher int the US than in Europe (channels are less a problem, especially in the 2.4GHz range as you rightly pointed out).
You're saying that with a little script using geoIP I could have my machine read its current location country and configure the reg domain on the fly. Did I understand you well ? Doing so would require reboot I think, so again that would not be hot config and on the fly.

Tx. Query SOLVED.

Last edited by Cbhihe (2019-04-26 06:53:44)

seth · 2019-04-25 15:58:22

If the device was legally imported, the default behavior is ok in the destination region (regardless where the chip was etched)

You do not have to reboot, crda allows you to alter the regdomain on the fly (see the link loqs posted). The legally "wonky" part is that if you wanted to use geoip to determine the location, you first would have to use the radio (to get an IP) and in this pot. violating the law. Though to be realistic, exceeding the tx power limits for some minutes will usually go unnoticed anyway and violating radio standards is usually not punished by hang, draw & quarter either.

Cbhihe · 2019-04-26 07:27:15

I re-open this question momentarily. Something cropped up.

Since I'm in Western Europe, I wanted to put in a country code to that effect, e.g. "EU". Although "EU" is already "unofficially" considered by the ISO 3166-1, "EU" is not included/available in /etc/conf.d/wireless-regdom. I added it yesterday and curiously, upon rebooting (that was yesterday), the actual code of the actual EU country in which I am right now popped up as the result of

$ iw reg get

The question that comes to mind is: how does detection occur ?
I am especially interested in that because I generally work behind a proxy (sometimes it's a tor node sometimes a VPN service), with a choice of exit nodes, unrelated to my geographical location. So by what magical process was the name of my actual location country ?

As it turns out:
- Inserting WIRELESS_REGDOM="EU" in /etc/conf.d/wireless-regdom is ignored.
- Upon booting, early this morning: (i) my actual country location was not detected; (ii) it remained '00' or global as it is hard set on EEPROM; (iii) Basically the effect of installing crda is to suppress the dmesg failure notification, as mentioned in post#1, about not loading regulatory.db.

Case closed.

Last edited by Cbhihe (2019-04-26 07:27:45)

Arch Linux

#1 2019-04-25 11:00:46

[SOLVED] Issue with loading regulatory.db at boot

#2 2019-04-25 11:07:59

Re: [SOLVED] Issue with loading regulatory.db at boot

#3 2019-04-25 12:26:26

Re: [SOLVED] Issue with loading regulatory.db at boot

#4 2019-04-25 12:35:02

Re: [SOLVED] Issue with loading regulatory.db at boot

#5 2019-04-25 13:05:13

Re: [SOLVED] Issue with loading regulatory.db at boot

#6 2019-04-25 15:43:57

Re: [SOLVED] Issue with loading regulatory.db at boot

#7 2019-04-25 15:58:22

Re: [SOLVED] Issue with loading regulatory.db at boot

#8 2019-04-26 07:27:15

Re: [SOLVED] Issue with loading regulatory.db at boot

Board footer