Your Router Can Do More Than Wi-Fi: My OpenWrt Setup

Image source: How-To Geek image CDN.

Your router can do more than provide Wi-Fi. With compatible hardware and OpenWrt, it can also handle DNS filtering and give you more control over what happens when your connection gets busy.

There is no fibre coverage at my home, so my internet comes through an Arcadyan AW1000 5G router. My unit is modded and flashed with a custom OpenWrt build; OpenWrt is not its factory firmware. The same router that provides the connection can also handle DNS filtering and upload queue management.

I use adblock-fast for DNS filtering and CAKE for upload queue management. Having them configured was only part of the work: I also had to check whether traffic followed the intended path. Hardware acceleration had its own ideas.

Why would you even do this?

OpenWrt is an alternative operating system for supported routers. It lets you install packages and change networking behaviour beyond what the manufacturer's settings page normally offers.

For my setup, that means:

• DNS filtering on the router: Block selected advertising and tracking domains for devices using its DNS.
• Upload queue management: Keep a busy upload from adding so much delay to other traffic.

You don't need OpenWrt just to get working Wi-Fi. The extra control comes with extra maintenance, and support depends on the exact router model and hardware revision. Similar names on the box do not make firmware interchangeable.

This article covers my modded, OpenWrt-flashed AW1000 setup, not the stock firmware or the flashing process.

DNS filtering without another box

I use adblock-fast to block selected domains through DNS. DNS translates a name into an address your device can connect to. If the domain is blocked, the lookup does not return its normal address, so clients using that resolver cannot obtain it through that lookup.

Devices using the router's DNS can benefit without installing a browser extension on each one. This is useful for devices where installing an extension isn't even an option.

There are a few things to keep in mind:

• Ads and ordinary content served from the same domain generally cannot be separated by DNS filtering.
• Devices using another DNS service or resolution path may bypass the filter.
• A working blocklist does not mean every ad will disappear.

In my router-local checks, selected blocked domains returned “domain not found” (NXDOMAIN), while an ordinary test domain and an allowlisted domain still resolved. Those rules worked from the router. I had not verified that every household device was using the filter.

Pi-hole can share an existing server too. The benefit here is avoiding another host when the router can already do the job.

Fast internet can still feel slow

My 5G connection gives me roughly 500 Mbps download and 20 Mbps upload. Those are approximate, variable speeds, not an advertised plan or a guarantee. Plenty of download capacity, considerably less room in the other direction.

That difference matters when an upload fills the available capacity. A game or call can become unpleasant even while a speed test tells you the connection is fast.

One possible cause is bufferbloat: traffic builds up in a queue, and packets spend longer waiting. Your call packets can sit behind a large upload even though the connection is still working.

CAKE controls how quickly traffic leaves the router and manages the queue of packets waiting to leave. It can also share capacity between traffic flows. Setting an upload limit slightly below the available capacity gives the router a chance to manage the queue before traffic builds up farther along the connection.

It does not increase your internet speed. You give up some peak throughput for better control over delay, and the router needs enough processing capacity to handle the work.

Where the 14 Mbps comes from

A wired test using Waveform’s bufferbloat test measured 510 Mbps download and 17 Mbps upload, with 29 ms idle latency and an additional 93 ms under download load and 310 ms under upload load.

I kept a 14 Mbps upload limit, below that measured upload rate. That leaves some headroom for CAKE to manage the queue instead of filling the upload connection completely. It is the setting I retained, not a proven optimum.

That cap applies only to uploads. It does not turn the roughly 500 Mbps download side into a 14 Mbps connection.

The 500/20 Mbps figures describe approximate capacity, not guaranteed speeds. A fixed cap also cannot follow every change in a 5G connection. If available upload capacity falls below 14 Mbps, the bottleneck can move beyond the router again.

This is the setting I kept after testing my connection. Copy the reasoning, not necessarily the number.

Why CAKE wasn't enough on my router

Having CAKE configured did not establish that it controlled the relevant traffic.

My AW1000 has a hardware-accelerated forwarding path: a faster route for moving traffic through the router. On my custom firmware, that route could bypass CAKE. I could configure an upload queue while traffic took a shortcut around it.

The queue existed. Its jurisdiction was the problem.

The fix was to stop that bypass, so traffic could pass through the queue CAKE manages. A startup hook—a script called when the acceleration service starts—was added to reapply the setting.

After the repair, CAKE’s counters showed it was processing upload traffic, and the acceleration checks showed no flows using the inspected bypass path. That supported the fix at the time of inspection; it did not prove every packet would follow the intended path under every condition.

This behaviour is specific to my hardware and custom firmware. It does not mean every OpenWrt router needs the same changes, or that hardware acceleration is always a problem.

Technical details, if you want them

The acceleration components on this setup are called ECM/NSS. The repair used a rule in ECM’s traffic-classification component to prevent acceleration from bypassing CAKE, plus a startup hook to reapply it. Checks reported that rule active (the diagnostic values were 1/1), zero accelerated flows in the inspected NSS counters, and increasing packet counts in the 14 Mbps CAKE queue on the mobile internet interface, wwan0_1.

Those checks describe the inspected state, not a guarantee about all future traffic.

What I kept, and what I removed

The retained setup is:

• adblock-fast for DNS filtering.
• Fixed 14 Mbps upload CAKE.
• The fix preventing acceleration from bypassing CAKE.
• No download cap.

I also tried a temporary 350 Mbps download cap on LAN1 only. It did not shape Wi-Fi or the other LAN ports. Here are the browser test results. These were separate runs, not a controlled experiment:

The trial did not demonstrate a download-latency benefit, and I rolled it back. These runs do not prove the cap caused worse latency or identify where the buffering happened.

Upload-loaded latency was low in those runs, but this was not a controlled before-and-after comparison. Separately, I reported gameplay without jitter after the upload work. That is a subjective observation, not proof that every latency problem was fixed.

What still needs testing

The scripts for reapplying the settings were exercised, and the service was checked to be enabled at startup. I did not test an actual reboot or deliberately disconnect and reconnect the mobile internet connection. I also did not repeat the client latency-under-load test after making the settings persistent.

Download-loaded latency remains unresolved. Good upload observations do not establish that the whole connection is fixed.

When this makes sense

If you already have a supported router and want DNS filtering or more control over busy-connection latency, OpenWrt is worth looking into. Check the exact model and hardware revision first, then consider whether you want to maintain the extra configuration.

For my Arcadyan AW1000, router-hosted DNS filtering and upload CAKE were useful enough to keep. The download experiment was not. I still have a download-latency problem to investigate, but no reason to keep a cap that did not earn its place.

Further reading

• OpenWrt project
• OpenWrt Table of Hardware
• OpenWrt SQM documentation
• adblock-fast project