Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

  • Open
  • quality assurance status badge
Details
4 participants
  • Brice Waegeneire
  • Katherine Cox-Buday
  • Guillaume Le Vaillant
  • Tom Fitzhenry
Owner
unassigned
Submitted by
Katherine Cox-Buday
Severity
normal
K
K
Katherine Cox-Buday wrote on 17 Jul 2021 23:43
(address . bug-guix@gnu.org)
CA+TvSRiJXBQwBJJK9BKY804ZiBEAxKAXMkrR4pH5+9XH+Xq7Fw@mail.gmail.com
#+BEGIN_EXAMPLE
[ 8.280462] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[ 8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 8.284394] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[ 8.284415] cfg80211: failed to load regulatory.db
#+END_EXAMPLE

and

#+BEGIN_EXAMPLE
$ find -L /run/current-system -name regulatory.db
/run/current-system/profile/lib/firmware/regulatory.db
#+END_EXAMPLE
K
K
Katherine Cox-Buday wrote on 17 Jul 2021 23:49
Re: bug#49611: Acknowledgement (Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`)
(address . 49611@debbugs.gnu.org)
CA+TvSRgY1TfHG+joyR8HFB6xCNx4oKHP-eNgzB5a4+1YAGWR0w@mail.gmail.com
Attempting to do this manually with crda fails as well:

#+BEGIN_EXAMPLE
$ guix environment --ad-hoc crda
[env] $ sudo COUNTRY=US crda
Failed to set regulatory domain: -7
#+END_EXAMPLE

On Sat, Jul 17, 2021 at 4:45 PM GNU bug Tracking System
<help-debbugs@gnu.org> wrote:
Toggle quote (22 lines)
>
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
> bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 49611@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 49611: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49611
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
B
B
Brice Waegeneire wrote on 18 Jul 2021 19:47
Re: bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`
(name . Katherine Cox-Buday)(address . cox.katherine.e@gmail.com)(address . 49611@debbugs.gnu.org)
87r1fvsed1.fsf@waegenei.re
Hello Katherine,

TL;DR: “iw reg set US” correctly set the regulatory region from userland
but Guix can't set it just from the kernel.

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

Toggle quote (9 lines)
> #+BEGIN_EXAMPLE
> [ 8.280462] cfg80211: Loading compiled-in X.509 certificates for
> regulatory database
> [ 8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [ 8.284394] platform regulatory.0: Direct firmware load for
> regulatory.db failed with error -2
> [ 8.284415] cfg80211: failed to load regulatory.db
> #+END_EXAMPLE

There is three way to make the module cfg80211 load a regulatory
database:
1. Baking the DB into the kernel at build time by replacing the kernel's
limited DB with the one from 'wireless-regdb' via the option
CONFIG_CFG80211_INTERNAL_REGDB¹.
2. Loading the DB at boot time as a signed firmware file
(lib/firmware/regulatory.db from 'wirerless-regdb') via the module
'cfg80211'.
3. Doing it in userland with the helper 'crda' trough the utility
'iwd' or its predecesor 'wpa_supplicant'.²

From what I understand and what I tested, only the third method works in
Guix System ATM. It could be usefull to also support the first or
second method to not depend on the userland setting the wireless
regulatory settings.

The error you are experiencing come from the second method failing to
load the signed firmware file. The issue is that Guix's 'wireless-regdb'
is build from source and not just copied as other distribution do, where
the provided binary also has a signature which the kernel accept through
a built in public key. Our build version isn't signed at all, the
commentaries in the definition for the package say Guix don't want to
maintain its own key for signing this package, which is understable and
state that Guix architecture already provide a similar level of
authenticity (I'm not so sure of that part).

So this error message should be harmless expected in some less common
context, such as having the rootfs on an NFS and using a wireless
connection to connect to the NFS server. We could fix that without
maintaining keys by baking the DB into the kernel (first method).

Toggle quote (5 lines)
> #+BEGIN_EXAMPLE
> $ find -L /run/current-system -name regulatory.db
> /run/current-system/profile/lib/firmware/regulatory.db
> #+END_EXAMPLE

We don't need the regulatory.db from 'wirelress-regdb' to be in the
system profile, instead it should be added to the operating-system's
firmware field. And the kernel will find it the directory contained in
“/sys/module/firmware_class/parameters/path”.


Cheers,
- Brice
G
G
Guillaume Le Vaillant wrote on 18 Jul 2021 21:17
(name . Katherine Cox-Buday)(address . cox.katherine.e@gmail.com)
871r7v77pa.fsf@kitej
Brice Waegeneire <brice@waegenei.re> skribis:

Toggle quote (32 lines)
> Hello Katherine,
>
> TL;DR: “iw reg set US” correctly set the regulatory region from userland
> but Guix can't set it just from the kernel.
>
> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>
>> #+BEGIN_EXAMPLE
>> [ 8.280462] cfg80211: Loading compiled-in X.509 certificates for
>> regulatory database
>> [ 8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>> [ 8.284394] platform regulatory.0: Direct firmware load for
>> regulatory.db failed with error -2
>> [ 8.284415] cfg80211: failed to load regulatory.db
>> #+END_EXAMPLE
>
> There is three way to make the module cfg80211 load a regulatory
> database:
> 1. Baking the DB into the kernel at build time by replacing the kernel's
> limited DB with the one from 'wireless-regdb' via the option
> CONFIG_CFG80211_INTERNAL_REGDB¹.
> 2. Loading the DB at boot time as a signed firmware file
> (lib/firmware/regulatory.db from 'wirerless-regdb') via the module
> 'cfg80211'.
> 3. Doing it in userland with the helper 'crda' trough the utility
> 'iwd' or its predecesor 'wpa_supplicant'.²
>
> From what I understand and what I tested, only the third method works in
> Guix System ATM. It could be usefull to also support the first or
> second method to not depend on the userland setting the wireless
> regulatory settings.

Hi,

You could also try adding "cfg80211.ieee80211_regdom=US" to the
'kernel-arguments' field of your 'operating-system' definition.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYPR+QQ8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j+cegD/fOlt0OU/bkOYroystnrpkYU6XA+pUKEk1Iz0
N5yFKP4A/jlwl5J2BU3IZuts21v0UxPwm1Ewoct5t/lG1ihTNzdz
=ckvl
-----END PGP SIGNATURE-----

K
K
Katherine Cox-Buday wrote on 19 Jul 2021 20:21
(name . Guillaume Le Vaillant)(address . glv@posteo.net)
CA+TvSRhLi-Cvffueu8Kh6Ny+MLMVwC0ZZr97sn08jKWt5dcbnw@mail.gmail.com
Thank you both! I was not aware that this belonged in the firmware
field and not the packages field. This has solved the error message
during boot. Further, adding the kernel argument successfully sets my
region as US on boot.

tags 49611 notabug
close 49611

This is not part of the bug per-say, but a question around this space:
despite all of this, I still cannot broadcast on US approved channels.
I think this is because the EEPROM on the card is set as global. What
am I missing? Do you know how Linux intend for people to notify the
stack that this is an OK thing to do? I know projects like OpenWRT
carry patches to the driver, but I keep thinking surely this is not
the only way.
G
G
Guillaume Le Vaillant wrote on 19 Jul 2021 23:17
(name . Katherine Cox-Buday)(address . cox.katherine.e@gmail.com)
87bl6yuhp8.fsf@kitej
Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:

Toggle quote (16 lines)
> Thank you both! I was not aware that this belonged in the firmware
> field and not the packages field. This has solved the error message
> during boot. Further, adding the kernel argument successfully sets my
> region as US on boot.
>
> tags 49611 notabug
> close 49611
>
> This is not part of the bug per-say, but a question around this space:
> despite all of this, I still cannot broadcast on US approved channels.
> I think this is because the EEPROM on the card is set as global. What
> am I missing? Do you know how Linux intend for people to notify the
> stack that this is an OK thing to do? I know projects like OpenWRT
> carry patches to the driver, but I keep thinking surely this is not
> the only way.

Some WiFi devices can have extra EEPROM-based restrictions if they don't
implement some features.
I have a WiFi card that I can't use as access point on the 5 GHz band
because it doesn't implement radar detection, which is apparently
mandatory on this band to avoid causing interference.
Luckily I have another device based on a different chipset where it just
works.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCYPXr4w8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j/vfwD5AYsiQ1rreKdC4RuWfMhABhMzF3Rshr4b1/e4
S2+HcFMA/RZlAXcvAcTN2CG8Bzvo4mvORgFvO5mbQM83VWkxDL1K
=VMHA
-----END PGP SIGNATURE-----

T
T
Tom Fitzhenry wrote on 10 Aug 2021 01:40
(address . bug-guix@gnu.org)
d2a12f0c-a7d7-ef39-53f9-147d1bb6b9f9@tom-fitzhenry.me.uk
On 20/07/2021 04:21, Katherine Cox-Buday wrote:
Toggle quote (6 lines)
> I think this is because the EEPROM on the card is set as global. What
> am I missing? Do you know how Linux intend for people to notify the
> stack that this is an OK thing to do? I know projects like OpenWRT
> carry patches to the driver, but I keep thinking surely this is not
> the only way.

issue for PC Engines, which retails wireless cards whose EEPROM uses a
global region.

My poor understanding is that Linux does not offer a way for end users
to override the EEPROM, per "It should be reasonably impossible for a
user to fail to comply with local regulations either unwittingly or by
accident."[0]

It looks like the two supported ways to set regulatory domain are:
* a card vendor/retailer that performs certification, and flashes the
EEPROM.
* a system integrator (e.g. off-the-shelf wireless routers, mobile
phones, etc.) that performs certification and sets
CONFIG_CFG80211_CERTIFICATION_ONUS.

Linux does offer a way to indicate your current region via CRDA[1], but
this is for the "travelling in another country" usecase, and acts to
restrict the driver to intersection(EEPROM, country).

T
T
Tom Fitzhenry wrote on 10 Aug 2021 01:45
c56cc55d-e044-62b5-ce25-9defe131c6d3@tom-fitzhenry.me.uk
On 20/07/2021 04:21, Katherine Cox-Buday wrote:
Toggle quote (8 lines)
> This is not part of the bug per-say, but a question around this space:
> despite all of this, I still cannot broadcast on US approved channels.
> I think this is because the EEPROM on the card is set as global. What
> am I missing? Do you know how Linux intend for people to notify the
> stack that this is an OK thing to do? I know projects like OpenWRT
> carry patches to the driver, but I keep thinking surely this is not
> the only way.

issue for PC Engines, which retails wireless cards whose EEPROM uses a
global region.

Disclaimer: I don't understand this well.

My understanding is that Linux does not offer a way for end users to
override the EEPROM, per "It should be reasonably impossible for a user
to fail to comply with local regulations either unwittingly or by
accident."[0]

I can see two supported ways to set the regulatory domain:
* a card vendor/retailer performs certification, and flashes the EEPROM
accordingly.
* a system integrator (e.g. off-the-shelf wireless routers, mobile
phones, etc.) performs certification and sets
CONFIG_CFG80211_CERTIFICATION_ONUS.

Linux does offer a way to indicate your current region via CRDA[1], but
this is for the "travelling in another country" usecase, and acts to
restrict the driver to intersection(EEPROM, country).

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 49611@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 49611
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch