FanchmWrt: an OpenWrt based router firmware with a parental control

An OpenWrt derivative for router hardware

FanchmWrt is described as an open source enterprise grade router system based on OpenWrt that incorporates some firewall features. Several popular device firmwares have been released and are available for download from the project site, and you can also compile firmwares for other models yourself.

The relationship to OpenWrt is structural rather than merely thematic. The repository is the OpenWrt source tree with the additions applied, down to the top level Makefile carrying the OpenWrt organisation's copyright from 2007 and the same SPDX identifier, and the same layout of directories for the target system, the packages, the tools and the toolchain.

That is worth understanding before you start, because it determines both what the project is and what adopting it means. If you have built OpenWrt before, you know how to build this. If you have not, the README sends you to the OpenWrt build system setup documentation, which is the correct reference, and states that the package names vary between distributions and that a complete distribution specific list is found there.

So the honest framing is that FanchmWrt is a maintained configuration and feature set on top of a well known open source router platform, with prebuilt images for some models and a build tree for the rest. The enterprise grade claim in the description is the project's own, and the README itself is short enough that most of the detail lives in the upstream project it derives from.

The parental control restriction, stated plainly

The Important Notes section of the README carries one restriction that is unlike anything else in the file, and it deserves to be quoted rather than summarised.

The source code for the parental control feature in this project is intended for personal use only. It may not be used on behalf of a company, nor may it be integrated into any commercial router products for sale. While you are permitted to sell it in a personal capacity, the FanchmWrt copyright information must be retained.

So the parental control component is not under the same terms as the rest of the tree. The project as a whole is stated to be licensed under GPL-2.0, and the top level Makefile carries the GPL-2.0-only SPDX identifier, but this one feature is carved out with a use restriction on top of the copyleft terms.

That is a licensing hybrid rather than a contradiction, and it is the kind of arrangement that is entirely normal in router firmware, where an upstream component with additional restrictions is imported into an otherwise open tree. The consequences are specific and testable.

For an individual running the firmware on their own router, the restriction is not a barrier. For a company deploying it internally across a fleet, the restriction on use on behalf of a company applies directly. For a vendor shipping a product with the parental control included, the restriction forbids the integration outright, whatever the rest of the tree's licence permits.

So the question to ask before compiling is not whether the project is open source, but whether the part you want is one of the restricted parts.

The build requirements and the quickstart

The README recommends Ubuntu 22 for compiling, and lists the tools you need, which are the OpenWrt ones.

binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev
make4.1+ perl python3.7+ rsync subversion unzip which

The version floors are the interesting part of that list, since they are what an old build host will fail on: a compiler of version 6 or later, make 4.1 or later, and Python 3.7 or later.

The quickstart is four steps, and the README is explicit that compiling FanchmWrt is the same as compiling OpenWrt, pointing at the OpenWrt compilation tutorial.

The first step updates the feeds, which obtains all the latest package definitions defined in the feeds configuration files. The second installs them, which creates the symbolic links for all the obtained packages into the package feeds directory. The third runs the configuration menu, where you select the toolchain, the target system and the firmware packages. The fourth is the build itself, and the README describes what it does: it downloads all sources, builds the cross-compile toolchain, and then cross-compiles the kernel and all the chosen applications for your target system.

So the first build is a long one, and it is the same long one OpenWrt is. The value FanchmWrt adds is the configuration, the features and the device targets, not a faster or easier build.

The repository is a complete OpenWrt tree

The top level listing shows a full router platform source tree rather than a patch set, and the entries are the ones an OpenWrt developer would recognise.

There is the target directory for the supported device platforms, the package directory for the packages that go into the image, the tools and toolchain directories for the build helpers and the cross compiler, the config directory with the target and kernel configuration, the scripts directory with the feed and build scripts, and the include directory with the build system headers.

Alongside them are the parts specific to this fork. There is a feeds patches directory, which holds the patches applied to the feeds, and a LICENSES directory alongside the COPYING file, which is where a project with mixed licensing keeps its per-component licence texts.

There is a BSDmakefile and a rules file and a configuration file at the root, the standard OpenWrt build system entry points, plus a version file and a version date file, which is how a fork marks its own release identity independently of the upstream numbering. The default branch is named after that version, which tells you the project keeps a stable branch per release rather than moving a single branch.

The Makefile shows the build system in detail, and the details are OpenWrt's: the locale and time zone are pinned so builds are reproducible, the top level path is checked and rejected if it contains spaces, the host tools directory is prepended to the path, and the classic stamp based dependency chain runs from tools through the toolchain to the target and then the packages. There is a check target that runs the same chain in check mode, and a printdb target that is deliberately a no-op in this tree, which tells you the database printing was removed.

The presence of a dev container directory and a VS Code configuration is a modern touch on an old build system, and it is the kind of thing that makes the build reproducible for more people.

Releases, branches and what to check first

The repository has no GitHub releases, which fits a project whose artefacts are firmware images published elsewhere, on the project site, and which asks in the development section that you include the repository address when re-releasing a firmware.

That request is the interesting detail. It is a request to downstream builders to keep the provenance of the images visible, which is a small piece of supply chain hygiene for firmware, where a rebuilt image is indistinguishable from a downloaded one unless somebody says otherwise.

The default branch is named for a version, which is the pattern of a project that maintains a stable line per release: you check out the branch matching the version you want to build rather than tracking a moving main branch.

On the licence, there is a small inconsistency worth noting. The README states GPL-2.0, and the Makefile carries the GPL-2.0-only SPDX identifier, and the tree has the COPYING file and a LICENSES directory. The licence field in the repository listing is not one GitHub can classify, so the files in the tree are the authority.

Three checks before you build or deploy it. Which device models have published firmwares, so that you are not compiling for a target nobody has tested. Whether your build host meets the toolchain requirements, since an old distribution is the usual reason a first build fails. And whether the parental control component is one you are permitted to use in the way you intend, because that restriction is separate from the licence of the rest of the tree and it is stated in plain language rather than left in a licence file.

Editorial conclusion

FanchmWrt suits someone who wants an OpenWrt firmware with the project's firewall and parental control features rather than stock OpenWrt, and who is comfortable with the OpenWrt build system, since the repository is a complete source tree and the quickstart is the upstream one. It is the wrong choice if you want a supported distribution package, since the firmware is built and released by the project rather than packaged by a distribution, and it is the wrong choice for a company shipping router hardware, because the parental control code is explicitly restricted to personal use. Verify first which device models have published firmwares, that your build host meets the toolchain requirements, and that the licence terms of the parental control component match your intended use before you compile it.

Frequently asked questions

Official sources

1. fanchmwrt/fanchmwrt on GitHub
2. Issues
3. Project website
4. README