Check regulatory.bin and regulatory.db Safely

Two similarly named files control which Wi-Fi channels and power levels your kernel lets a card use, and mixing them up wastes an afternoon. This guide identifies which wireless regulatory database your Linux system uses, confirms the installed package supplied its files, and checks the active regulatory domain without editing any binary data. Allow about 10 minutes. You need a shell and, for package repair or updates, an account with sudo access.

1. Identify the two database formats

The installed regulatory.bin(5) page describes both formats because the package can serve old and new systems. It also says regdbdump can turn the legacy binary into human-readable output. That tool is not necessarily installed with the database package, and it is not the right way to inspect a modern regulatory.db.

Checkpoint: do not copy a file called regulatory.bin into /lib/firmware just because a kernel message mentions regulatory data. Establish which path your kernel and distribution use first.

2. Record the package version and file list

Use ordinary, read-only commands to see what your distribution installed. This does not require elevated privileges.

$ dpkg-query -W -f='${Package} ${Version}\n' wireless-regdb
$ dpkg -L wireless-regdb | grep -E 'regulatory\.(bin|db)(\.p7s)?$'

On the Ubuntu Noble host used for this guide, the installed package is wireless-regdb 2026.05.30-0ubuntu1~24.04.1, and the package list contains /lib/firmware/regulatory.db and /lib/firmware/regulatory.db.p7s. Your output may differ by distribution, release and package version: treat that output, not a remembered path, as the local answer.

The package files are data consumed by the wireless stack, not a configuration file where you should change your country or increase transmit power. The country hint is a separate runtime operation, and the kernel and driver can further restrict it regardless.

3. Check the modern firmware pair

For a current kernel, inspect both the database and its signature as one unit. This is read-only and needs no privilege.

$ ls -l /lib/firmware/regulatory.db /lib/firmware/regulatory.db.p7s
$ file /lib/firmware/regulatory.db /lib/firmware/regulatory.db.p7s
$ sha256sum /lib/firmware/regulatory.db /lib/firmware/regulatory.db.p7s

Expected output includes a regular database file and a separate PKCS#7 signature file, with exact sizes and checksums that are release-specific. A missing signature, a file owned by an unexpected package, or a database copied from an unrelated download is a reason to repair the package, not to disable signature checking.

Security boundary: do not replace these files with an unsigned database or a file from a random forum. Regulatory data controls which channels and power limits the kernel may make available. A signature proves provenance only when the kernel trusts the signing key, so keep the distribution's normal verification path intact.

4. Update through the distribution

Use the package manager when a regulatory correction is needed. This changes system files and may affect wireless operation after the kernel reloads the database, so save work and avoid doing it during a production wireless change window.

$ apt-cache policy wireless-regdb
$ sudo apt update
$ sudo apt install --only-upgrade wireless-regdb

The first command shows the installed and candidate versions, and the last one updates only this package if a newer candidate is available. Package installation can replace both the database and signature together. If it reports no upgrade is needed, that is useful evidence in itself: investigate the package repository or release policy before downloading a replacement by hand.

Verify the result after the transaction:

$ dpkg-query -W -f='${Package} ${Version}\n' wireless-regdb
$ dpkg -V wireless-regdb

A quiet dpkg -V is the normal result for unchanged package-owned files. If verification reports a changed file instead, reinstall the package to restore the distribution copy:

$ sudo apt install --reinstall wireless-regdb

5. Inspect the active regulatory domain

If the iw utility is installed, ask the kernel what it is enforcing. This is read-only.

$ command -v iw
$ iw reg get

Look for a country entry and its rules. A country code in the output is not a promise that every adapter can use every listed channel: hardware firmware, driver limits, DFS requirements and other regulatory hints can narrow the result further. If iw is absent, install the package that provides it for your distribution, or inspect kernel logs for database-loading errors. Do not infer success just because the files exist on disk.

Setting a country is a state change and normally requires privilege:

$ sudo iw reg set <CC>
$ iw reg get

Replace <CC> with the two-letter ISO 3166 alpha2 code for the country where the equipment is operating, such as GB. Never use this command to grab channels or power that local rules do not permit. The setting can be superseded by another regulatory hint or disappear on reboot, and that behaviour is separate from updating the database. Undo an experimental runtime setting by selecting the correct local country again, or reboot if your system normally establishes the hint during startup.

6. Handle legacy CRDA systems deliberately

On an older installation that actually uses CRDA, the manpage's diagnostic tool is regdbdump. Give it the path of the legacy file reported by your package manager, rather than assuming one location:

$ command -v regdbdump
$ regdbdump /path/to/regulatory.bin

The command should print human-readable country and rule entries when the file is valid. If the command or file is missing, do not manufacture a replacement from a modern database; check the package that owns the legacy path and the CRDA installation for that older system instead. On Linux 4.15 and later, prefer the kernel firmware database path documented by your distribution.

Done means