Skip to content

About

Actions to automatically maintain the default-openwrt-config repo

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

41 Commits

Folders and files

Repository files navigation

OpenWrt default config generator

This repo contains documentation and GitHub workflows for https://github.com/BCMM/default-openwrt-config. That repo contains examples of default OpenWrt /etc/config/* files for typical "router" and "client" devices.

Rationale

I wanted to see the default contents of OpenWrt's /etc/config/. At first glance it seems like one can get this from /rom/etc/config/ or by browsing OpenWrt's source code, but such approaches are of limited use because some important files are generated on first boot, not at build time.

I initially wanted this as a way to check my work when I was re-configuring an AP to act as a router. It may also be useful when migrating config between releases, since the commit history shows how the defaults have changed over time.

About the repo

Of course, there is no such thing as default OpenWrt config: parts of the files generated on first boot are hardware-specific. The repo contains config for a couple of simplified devices. Each branch contains the contents of /etc/config/ for its respective device.

"router"

This device represent a generic OpenWrt router. It has one WAN port (wan) and two LAN ports (lan1 lan2).

"client"

This device represents any other type of OpenWrt box. It has two LAN ports only (lan1 lan2).

Many OpenWrt builds for Wi-Fi APs, managed switches and NAS appliances have different defaults from router builds. They have no WAN interface, and on the LAN interface, they act as DHCP clients instead of servers.

Randomly-generated values

You will find the value '[expunged]' in a couple of places. Those values are randomly generated on first boot and have been censored to avoid spurious config changes in every single version.

Example usage

Task Local Online
Prepare git clone https://github.com/BCMM/default-openwrt-config.git
cd default-openwrt-config
N/A
Compare router to client git diff origin/client Link
Compare two releases git diff router/v22.03.0 router/v24.10.8 Link
Compare to your real router git checkout router/vNN.NN.N # Skip if using latest release
scp -O -r root@openwrt:/etc/config/* .
git diff
N/A
As above, but normalised git checkout router/vNN.NN.N # Skip if using latest release
ssh root@openwrt uci export > uci_export
git diff
N/A

Or git diftool -d, if you have a favourite diff GUI.

There will always be some changes between the repo and a real router's config, even if you haven't changed anything yet. However, uninteresting changes are few enough that one can look past them, and I think this works well as a "what am I missing?" check.

Notes on history

The author date of each commit is set to the build date of the release that it is derived from. This is typically about one day before the official release announcement. AFAIK, the author date is not visible on GitHub, but you can view it with git log. (GitHub displays the committer date instead, which reflects the actual date that the action ran.)

There is one tag for each release processed. Since most releases do not cause any config changes, most commits have multiple tags.

How this works

The config is automatically generated by running part of OpenWrt's first-boot sequence inside a container.

config_gather.sh places one of 02_network.* at /etc/board.d/02_network and then generates configuration. generate.yml creates containers, runs config_gather.sh within the containers, and then either commits the resulting files to the repository or, after confirming that they haven't changed, adds a tag to an existing commit. .github/workflows/check.yml checks OpenWrt's rootfs Docker image for new tags and runs generate.yml as needed. initialise.yml sets up a branch and deals with a few earlier releases which need slightly special handling.

Caveats

Comparibility of files modified by uci

Some files (currently firewall, dropbear, attendedsysupgrade and rpcd) do not appear to get modified during the initial boot. If they are ever touched by uci, whitespace and quoting conventions will be changed and comments will be removed, resulting in a noisy diff.

I have decided not to normalise these files, because that would break comparability for people who have made edits by hand.

Instead, I've added the file uci_export. This is simply the output of the uci export command, and should be cleanly comparable with any other output of the same command.

I don't know how swconfig works

Most routers feature a built-in switch. The /etc/config/network generated for the repo does not represent the way switches work on non-DSA targets. It looks more like a device with two or three independent NICs (which is an accurate model for some popular SBCs).

Non-DSA targets include every target before OpenWrt 21.02.0, and a decreasing number of targets thereafter.

Versions covered

This repo is only aware of releases which have official images on Docker Hub. The following releases are missing:

  • Everything < 18.06.9
  • 19.07.0 to 19.07.6
  • 24.10.0

With the exception of 24.10.0, the history of stable releases should be complete from 19.07.7 onward. This project does not attempt to track snapshots or release candidates.

Not strictly chronological

Each branch in the repo is ordered by version number, meaning that it is not strictly chronological. For example, changes to firewall which, in the repo's "history", first appear in 21.02.4 were in reality first seen in OpenWrt 22.03.0. At the time of writing (after the release of 25.12.5), that is the only example of a released change which is shown out of chronological order.

Unstable hashes

As a result of the non-chronological ordering, it may be necessary in the future to rebase in order to insert changes made to an old stable series. This means that hashes for any commits in the current stable series could change. If you wish to link to specific revisions within the repository, I recommend using tags instead of hashes.

For example, use

https://github.com/BCMM/default-openwrt-config/blob/router/v25.12.5/dhcp

instead of

https://github.com/BCMM/default-openwrt-config/blob/f547004e160daae2d2317cc6f828b2dc7dbe65b6/dhcp

Since such changes have, so far, been uncommon, I do not expect that this will happen often. Most OpenWrt releases will not trigger config changes, and will be handled by adding additional tags to existing commits.

Help wanted

Does anybody know how to make something that looks like an swconfig device?

Does anybody know of a way to automatically trigger a workflow when OpenWrt publishes a new image? Github's schedule: events seem to be a bit intermittent.

About

Actions to automatically maintain the default-openwrt-config repo

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages