# OpenAppFilter (OAF) on OpenWrt: DPI-based parental control for your router

> OAF is a GPL-2.0 parental control plugin for OpenWrt that identifies applications with deep packet inspection instead of DNS blocking. It builds from the OpenWrt source tree, and its licence splits free personal use from paid commercial use.

**destan19/OpenAppFilter** — OAF(OpenAppFilter) is a parental control software based on OpenWrt. It supports popular applications across gaming, video streaming, instant messaging, such as TikTok, YouTube, Facebook. Currently, it supports hundreds of different applications.

- Repository: https://github.com/destan19/OpenAppFilter
- Website: http://www.openappfilter.com
- Stars: 2,896 · Forks: 761
- Language: C
- License: GPL-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/destan19-openappfilter

## What OAF blocks that a DNS filter misses

The README describes OAF as parental control software based on OpenWrt that supports popular applications across gaming, video streaming and instant messaging, naming TikTok, YouTube and Facebook, and states that it currently supports hundreds of different applications. The mechanism it advertises is DPI-based protocol identification: Layer 7 protocol parsing plus HTTPS domain resolution, operating independently of DNS. That independence is the whole point. A DNS-based blocker works by refusing to resolve a domain, so any client that switches to an encrypted resolver or connects to a bare IP address walks straight past it. OAF claims to identify the flow itself instead, which means the decision happens on traffic rather than on a name lookup. The audience is narrow and specific: a household or small network where the router already runs OpenWrt and someone is willing to build firmware, not a consumer who wants an app on a phone.

## Flow-based identification and the three packages behind it

The repository layout shows three top-level directories next to LICENSE and README.md: luci-app-oaf/, oaf/ and open-app-filter/. The compile section of the README maps those to three distinct source packages: the LuCI app, the service daemon and the kernel module. Enabling luci-app-oaf pulls in all three. The README describes the architecture as flow-based identification for high efficiency, with low hardware requirements, which fits the split: the kernel module sees packets, the daemon tracks flows and matches signatures, and the LuCI app is the configuration surface in the router's web interface. The README also states that custom protocol signatures are supported, so the signature set is not fixed at build time. What the README does not give is the signature file format, where signatures live on disk, or how they are updated after installation. That is a real gap for anyone planning to maintain a deployment, because a DPI engine is only as current as its signatures.

## Building luci-app-oaf into an OpenWrt image

OAF is not installed from a package feed in the steps the README gives. It is compiled into the OpenWrt source tree. Step one is a set of OpenWrt sources that has already been compiled into firmware successfully; the README explicitly declines to cover compiling OpenWrt itself. From the root of that tree, clone the repository into package/:

```bash
git clone https://github.com/destan19/OpenAppFilter.git package/OpenAppFilter
```

The README then says to enable the three build options. Selecting luci-app-oaf in make menuconfig is the graphical route. The command-line equivalent the README gives is:

```bash
echo "CONFIG_PACKAGE_luci-app-oaf=y" >>.config
make defconfig
```

According to the README, that single option automatically enables the compilation options for all three modules. If the tree has been built before, individual packages can be rebuilt instead of the whole image:

```bash
make package/luci-app-oaf/compile V=s
make package/open-app-filter/compile V=s
make package/oaf/compile V=s
```

Running make V=s builds the full firmware with the plugin integrated. The README also points at the releases page for prebuilt plugin packages matched to your architecture, which is the shortest path if a matching package exists for your device.

## Where OAF is the wrong tool

The build requirement is the first limitation, and the README states it plainly rather than hiding it: you need an OpenWrt source tree that has already compiled successfully into firmware. That rules out anyone on a vendor firmware, and it makes OAF a poor fit for a router the household depends on, because a failed build means no image at all. The second limitation is the signature set. A DPI classifier decides by matching traffic against known patterns, so an application whose protocol changes, or one that is simply not in the signature set, is not blocked. The README claims hundreds of applications but does not enumerate them, so you cannot confirm coverage for a specific app before building. Third, the licence draws a line the README is explicit about: individuals may use the software free of charge and may develop on and redistribute it, but a company wishing to use it is told to contact the author for authorization. That is unusual for a GPL-2.0 project and it is a decision point, not a footnote. Finally, the README does not document rollback, so recovering from a bad build is an OpenWrt problem you solve yourself.

## How OAF differs from OpenWrt's own app filtering

The related searches around this project keep returning to OpenWrt parental control, and the honest comparison is with what OpenWrt already ships. OpenWrt has firewall rules, MAC-based access control, and DNS-level blocking through packages such as adblock, which work by feeding blocklists to a resolver. Those approaches are transparent and cheap, and they fail in exactly the case OAF targets: a client using DNS-over-HTTPS or connecting directly to an IP. OAF moves the decision from the name to the flow, which is why the README stresses independence from DNS. The cost is the build process and the signature dependency. The two are not exclusive, and a deployment that blocks obvious domains at the resolver and classifies the remainder with OAF is a reasonable arrangement. What OAF is not is a drop-in replacement for a blocklist package you install from the feed.

## Licence terms and what they mean for a company

The repository is GPL-2.0, and the README adds terms on top of that. Individuals can use the software completely free of charge and are permitted to develop upon and redistribute it. Derivative development must adhere to the GPL 2.0 license and retain references to the OAF repository or website. Companies that wish to use the software are asked to contact the author for authorization. Read that as a practical question rather than a legal one: if OAF is going into a product, a managed service, or an internal network at a business, the README's own wording says to make contact first. For a home user the terms are permissive. This is not legal advice, and the exact scope of the commercial clause is something only the author can clarify.

## Release cadence and the cost of staying current

The releases list shows v7.0.1 on 2026-08-29, v6.1.8 on 2026-04-22 and v6.1.7 on 2026-03-04, and the last push to the default branch was on 2026-09-24. That is a project receiving commits, and the version jumps between 6.1.8 and 7.0.1 suggest the signature set or the identification engine changes between releases, not just packaging. For an operator this sets the upgrade cost: a router running OAF is not a set-and-forget device, because a signature refresh means rebuilding and reflashing. The README does not describe an over-the-air signature update, so plan on treating firmware rebuilds as routine maintenance. The README also notes the Telegram discussion group at https://t.me/openappfilter, describing it as recently created, which is where installation and usage questions are directed. There is no documented issue-triage process beyond that.

## Conclusion

OAF suits anyone already running a self-compiled OpenWrt firmware who wants per-app blocking that survives DNS-over-HTTPS, and who is comfortable rebuilding packages when the signature set changes. It does not suit people who want a stock router flashed once and left alone, or companies that have not contacted the author about the commercial licence term. Before adopting it, verify that your OpenWrt source tree is on a branch where luci-app-oaf, oaf and open-app-filter all compile, and check the signature update path, because the README documents neither.

## FAQ

### Can OpenAppFilter be used commercially?

The README says individuals may use it free of charge and may develop on and redistribute it under GPL 2.0, but that a company wishing to use the software should contact the author for authorization.

### Does OpenAppFilter need OpenWrt, or does it run on stock router firmware?

The README describes OAF as based on OpenWrt and gives build instructions that start from an OpenWrt source tree, so the documented path assumes OpenWrt rather than vendor firmware.

### How are OpenAppFilter's protocol signatures updated after installation?

The README states that custom protocol signatures are supported but does not document a signature update mechanism, so the documented path is rebuilding from source when a new release appears.

## Sources

- [destan19/OpenAppFilter on GitHub](https://github.com/destan19/OpenAppFilter)
- [License: GPL-2.0](https://github.com/destan19/OpenAppFilter/blob/master/LICENSE)
- [Project website](http://www.openappfilter.com)
- [README](https://github.com/destan19/OpenAppFilter/blob/master/README.md)
- [Releases](https://github.com/destan19/OpenAppFilter/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/destan19-openappfilter