Fengard 1.3.2.2 · Midgard Pre-Release

Preview build. Routers get it with Settings → Updates → Preview builds on.

Fixes

• VPN clients on GL.iNet routers. Devices sent through a VPN client set up in GL.iNet's settings could lose DNS, so sites just kept loading, while the router itself still looked up names fine. GL.iNet runs a separate DNS for each VPN client. Installers before 1.3.1.2 turned those off along with the main one, and updating from the dashboard never turned them back on. Fengard now turns them back on when it starts, so routers that were installed early get fixed by updating

Thanks to the people on Reddit and in #3 who reported this on a Beryl 7 and a Flint 3.

How it was tested

• Router lab: 13 emulated routers and everything in When things go wrong, including a GL.iNet style router where an older install had turned the VPN client DNS off
• Tests: which ports get put back, leaving the main DNS off

Update

Settings → Updates → Preview builds on → Check now → Update to 1.3.2.2

Fengard 1.3.2.1 · Midgard Pre-Release

Preview build. Routers get it with Settings → Updates → Preview builds on.

Fixes

• GL.iNet's AdGuard Home switch. Turning off GL.iNet's AdGuard Home during install only stopped it. GL.iNet's own switch for it stayed on, which can leave DNS pointing at AdGuard Home after a reboot or when a VPN client comes up, and then nothing resolves. The installer now turns the switch off too, and removing Fengard turns it back on. Routers that already have Fengard get the switch turned off once when Fengard starts
• An HTTP/3 alert could show an IPv6 error on a network without IPv6. Addresses the router can't send to are now skipped straight away, so the alert shows why HTTP/3 over IPv4 failed

Changed

• The memory check before loading blocklists was too careful. It now goes by what loading actually took when measured (about 2.5 times the list's file size instead of 3, keeping 16 MB free instead of 24) and counts memory Fengard already holds but isn't using. The message gives the total for all your lists, not just one
• A list a profile has on that couldn't load now shows a warning at the top of the profile, and Filtering says why next to it instead of only in a tooltip

Thanks again to the Reddit user on a Beryl 7 who tracked down the AdGuard Home one.

How it was tested

• Router lab: 13 emulated routers and everything in When things go wrong, on iptables and nftables, including a GL.iNet install with the AdGuard Home switch left on by an older version
• Tests: the memory check numbers, the held list warning, and HTTP/3 skipping addresses with no route

Update

Settings → Updates → Preview builds on → Check now → Update to 1.3.2.1

Fengard 1.3.2 · Midgard

The full release after 1.3.1. It brings in everything from the 1.3.1.1 to 1.3.1.5 previews, and a few more things from feedback on a Beryl 7.

New

• Add-ons. The VPN, manufacturer names, speed test, device check, who's home and the captive portal can each be installed or removed in Settings → Add-ons. One that isn't installed doesn't run and takes no memory. Updating keeps every add-on you have
• Customise the overview. Drag cards around, resize them, remove them or add them back. The layout is saved on the router per user
• Custom lists per profile. Lists from Filtering show up in each profile and each profile turns them on or off. Each profile also shows how many blocklist domains it blocks, like 156K of 566K
• DNS servers per profile. A profile can use its own resolvers, like Cloudflare for Families for Kids, while everyone else keeps the ones on the DNS page. Blocklists and rules still apply first
• DNS → Ask all at once sends each lookup to every resolver and uses the first good answer
• Settings → Updates → Go back installs an older release, backs up your settings first and keeps automatic updates off the version you left
• An alert when a resolver keeps failing over HTTP/3 and lookups to it go back to HTTP/2
• The installer offers to turn off GL.iNet's AdGuard Home when it runs beside DNS. Removing Fengard turns it back on

Smaller

• Memory: about 19 MB on a GL-MT3000 just after starting, down from about 43 MB in 1.3.1. 535k blocked domains take 6.9 MB instead of 13 MB
• Program: about 13% smaller, 11.7 MB instead of 13.4 MB on ARM64 and 13.7 MB instead of 15.6 MB on MIPS. The block page, captive portal and screen time page stopped using Go's html/template, which kept a lot of unused code in the program
• Big blocklists: new custom lists start off in every profile, and a list no profile uses takes no memory. Before loading, Fengard checks free memory and leaves out a list that won't fit, saying how much it needs. The HaGeZi TIF list (1.57M domains) peaks around 60 MB while loading, which can be too much on a busy router
• If the router runs out of memory and kills Fengard while it loads the lists, the custom lists stay off on the next start instead of crashing it again, and an alert says so

Fixes

• DNS stopped answering for a while after a VPN client on the router came up, like GL.iNet's OpenVPN client. Fengard kept sending lookups over connections that now went nowhere. It opens fresh ones when the network changes, and an HTTP/2 connection that stops answering gets dropped in seconds instead of about 15 minutes
• Sites could load only partly through a VPN client on the router. Fengard now only drops packets marked invalid when they come in from the internet
• Firewall rules could fail to apply when a VPN client came up at the same moment ("Another app is currently holding the xtables lock")
• Saving GL.iNet's DNS page gave port 53 back to dnsmasq and Fengard kept restarting. It now takes the port back within 20 seconds
• Making a profile called IoT failed because the built in Smart home profile already used that id

Thanks to u/xPliZit_xs on Reddit for testing on a Beryl 7, sending logs and most of the ideas above.

How it was tested

• Router lab: 13 emulated routers and everything in When things go wrong, on iptables and nftables, all passing
• HTTP/3 lab: fengard-h3 against quic-go with up to 30% packet loss, duplication and jitter, no failed lookups
• Tests: the VPN fix has a test with a proxy that goes silent on open connections, like a route change does. It fails on 1.3.1.5 and passes now. There are also tests for DNS per profile, the memory check, the hold after a crash, the HTTP/3 alert, and a check that the block page, captive portal and screen time page render exactly as they did with html/template
• Not tested: a real Beryl 7 with its VPN client. The VPN fix comes from his logs, so if DNS still drops when a VPN comes up on your router, please open an issue

Update

Settings → Updates → Check now → Update to 1.3.2

Fengard 1.3.1.5 · Midgard Pre-Release

Preview build. Routers get it with Settings → Updates → Preview builds on. Last of the previews before 1.3.2.

New

• Custom lists per profile. Lists you add in Filtering now show in each profile's Categories tab under Your lists, marked Custom, and each profile turns them on or off. Before this they blocked for every device. Lists you already have stay on in every profile after the update, and a new list starts on everywhere
• How much a profile blocks. Each profile shows how many blocklist domains it blocks out of everything loaded, like 156K of 566K. A domain in several lists counts once. Filtering shows the total, which is what decides how much memory the blocklists take

Fixes

• Sites could load only partly through a VPN client running on the router, like GL.iNet's OpenVPN or WireGuard client. Fengard dropped packets that connection tracking marked invalid on all traffic, and hardware acceleration can make normal packets look like that. It now only drops them when they come in from the internet. OpenWrt doesn't drop them at all by default
• On routers with iptables, the firewall rules could fail to apply when a VPN client came up at the same moment ("Another app is currently holding the xtables lock" in the log). Fengard now waits for the lock

Thanks to the Reddit user who sent the logs from a Beryl 7 for the VPN one.

How it was tested

• Router lab: 13 emulated routers and everything in When things go wrong, on iptables and nftables
• Tests: custom lists per profile, existing lists moving into every profile once, a deleted list dropping out of profiles, the domain counts, and the firewall only dropping invalid packets from the WAN
• The VPN fix comes from the logs. I can't recreate GL.iNet's hardware acceleration in the lab, so if sites still half load over a VPN on your router, please open an issue

Update

Settings → Updates → Preview builds on → Check now → Update to 1.3.1.5

Fengard 1.3.1.4 · Midgard Pre-Release

Preview build. Routers get it with Settings → Updates → Preview builds on. Third of the previews leading to 1.3.2.

New

• Add-ons. The VPN, manufacturer names, speed test, device check, who's home and the captive portal are now add-ons. Install or remove them in Settings → Add-ons, and new installs pick them during setup. One that isn't installed doesn't run and takes no space. The VPN page still shows in the sidebar with a download icon and its size, so you can see what you're missing
• Customise the overview. Press Customize on the dashboard to drag cards around, make them wider or narrower, remove them or add them back. Your layout is saved on the router, so it's the same on your phone and your computer. Reset puts the standard one back

How add-ons work

Each add-on's code is still part of Fengard, it only adds about 180 KB in total. What gets downloaded is the dashboard pages, the overview cards and their data, which is most of an add-on's size. They come from this release (under 1 KB up to 332 KB each) and every file is checked against a list built into Fengard before it's used. A router without internet gets them from the install kit instead.

Updating from an earlier version keeps every add-on, nothing gets removed on its own.

Less memory

• Manufacturer names take 0.65 MB instead of 2.4 MB once the devices list has been opened, and nothing without the add-on
• The download for an update is a bit smaller, 5.3 MB instead of 5.6 MB on a GL-MT3000, since the manufacturer list isn't inside the program anymore

Fixes

• The DNS page didn't load with HTTP/3 on and no https:// resolver

How it was tested

• My router: GL-MT3000 (GL.iNet 4.7, OpenWrt 21.02), updated from 1.3.1.3 with all its settings, then the VPN add-on removed and put back and the overview rearranged
• Router lab: 13 emulated routers and everything in When things go wrong. A new check installs the default add-ons from the kit with no internet
• Tests: add-ons from a folder, the kit and a download, a tampered file refused, an archive that tries to write outside its folder, a failed update keeping the old files, add-on APIs answering only while installed, and saved layouts

Update

Settings → Updates → Preview builds on → Check now → Update to 1.3.1.4

Fengard 1.3.1.3 · Midgard Pre-Release

Preview build. Routers get it with Settings → Updates → Preview builds on. Second of the previews leading to 1.3.2.

New

• DNS → Ask all at once. Each lookup goes to every resolver on the list at the same time and the first good answer is used. Handy if your resolvers are safe but slow or sometimes don't answer. Off by default since it sends more traffic upstream
• The installer offers to turn off GL.iNet's AdGuard Home when it runs beside DNS. GL.iNet's own toggle runs it behind dnsmasq, where Fengard never uses it, so it was only taking up memory. Say no and it's left alone (and you won't be asked again). Removing Fengard turns it back on

Less memory

On a GL-MT3000 just after starting, with about 530k blocked domains:

	1.3.1.1	1.3.1.2	1.3.1.3
Fengard's own memory	42.9 MB	24.3 MB	19.1 MB
Peak	77 MB	52 MB	44.6 MB

• Blocklists are stored back to front so sites share their endings, and each domain only keeps what differs from the one before it. 535k domains take 6.9 MB instead of 10.7 MB
• Lists are parsed straight from the file buffer, which takes the loading peak from 33 MB to 23 MB
• A device flooding DNS can't push memory up anymore. Fengard reads DNS itself now and handles at most 128 lookups at once, the rest wait in the kernel. After a flood of 1.5 million lookups a second it sits at 24 MB, it used to climb to 64 MB and stay there

Fixes

• With HTTP/3 on, resolvers after the first showed no status, so it looked like they were never checked. They now say they're standbys, used if the ones above don't answer
• Uninstalling on a slow router could leave one firewall rule behind if Fengard took more than a second to shut down

How it was tested

• My router: GL-MT3000 (GL.iNet 4.7, OpenWrt 21.02) on a home network, with Ask all at once and HTTP/3 on
• Router lab: 13 emulated routers and everything in When things go wrong, including GL.iNet-style AdGuard Home on port 3053 (left on when you say no, off when you say yes, back on after removing Fengard)
• Tests: a slow, an unreachable and a SERVFAIL-only resolver with Ask all at once, more lookups than the 128 cap, odd packets (garbage, answers, updates) getting nothing or the right error, and near-miss domains against the new blocklist format. They also run as 32-bit in CI now

Update

Settings → Updates → Preview builds on → Check now → Update to 1.3.1.3

Thanks to u/xPliZit_xs for spotting the HTTP/3 status confusion, and to the Reddit user who asked about parallel requests and AdGuard Home.

Fengard 1.3.1.2 · Midgard Pre-Release

This is a preview build. Routers get it when Settings → Updates → Preview builds is on. It's the first of a few previews that make Fengard lighter, and they all come together in 1.3.2.

Less memory

Measured on a GL.iNet GL-MT3000 with about 530k blocked domains:

	1.3.1.1	1.3.1.2
Fengard's own memory	42.9 MB	24.3 MB
Peak while loading blocklists	77 MB	52 MB

• Blocklists load without the spike. Domains now go into fixed blocks that are sorted and merged once, instead of a list that kept being copied as it grew. The load peak is where small routers ran out of memory
• Blocklists take less room. 535k domains now take about 11 MB instead of 13 MB, and lookups are slightly faster than before
• Built-in root certificates only when needed. Fengard carries its own for routers without a certificate bundle, and now only loads them on those routers, which saves 1 MB on the rest
• Memory comes back sooner. Fengard tidies up its memory more often, and the query log's write buffer is smaller

New

• Go back to an older version. Settings → Updates → Go back… lists the older releases this router can switch to, back to 1.3.0, with the version you came from picked by default. It's as careful as an update: the download is checked, the older version is test-run first, and if it doesn't answer DNS after switching you're back on the current one automatically. Your settings are backed up before every switch, in either direction. Afterwards, automatic updates skip the version you left but still install anything newer. Versions before 1.3.1.2 don't know to skip it, so going back to one of those turns automatic updates off and says so first

Fixes

• Changing DNS in GL.iNet's settings broke Fengard. Saving GL.iNet's DNS page rewrites dnsmasq's settings and gives it port 53 back, so Fengard couldn't start, kept restarting, and the router's own DNS and DHCP failed with it. Fengard now notices within 20 seconds, takes port 53 back and logs that it did
• GL.iNet's VPN client DNS is left alone. GL.iNet runs a separate dnsmasq for each VPN client on its own port. The installer used to switch those off along with the main one. Now it only touches the main one, and reinstalling gives back any port an earlier install switched off
• The installer said to create the admin account even after an upgrade that kept it. It now says your settings and account were kept

How it was tested

• Your router: installed on a GL-MT3000 (GL.iNet 4.7, OpenWrt 21.02) and used on a real home network. Went back to 1.3.1 with the new button, then reinstalled 1.3.1.2
• Router lab: 13 emulated routers plus every situation in the When things go wrong table, with a new case that copies what GL.iNet does: a VPN client dnsmasq on its own port, then the main dnsmasq given port 53 back. Fengard takes it back, DNS and DHCP keep working, and uninstalling leaves the VPN one alone
• Blocklists: the new loader is checked against a simple reference with 120,000 domains split across many blocks with lots of repeats, and lookups are benchmarked against 1.3.1.1
• Go back: tests for which versions are offered with previews on and off, versions it refuses, a failed download leaving nothing half done, and the automatic-update hold

Update

Settings → Updates → turn on Preview builds → Check now → Update to 1.3.1.2

Thanks to u/xPliZit_xs on Reddit for measuring Fengard's memory on a Beryl 7 and asking for a low RAM mode (this is the first step), and for tracking down the port 53 problem.

Fengard 1.3.1 · Midgard

New

• Preview builds. Settings → Updates → Preview builds. Turn it on to get pre-releases early, like 1.3.1.1 with faster DNS over HTTP/3. Off, which is the default, means only full releases, and if you're on a preview the next full release replaces it. Previews never install unless this is on, not even with automatic updates

Fixes

• Version numbers with four parts, like previews use, are compared properly. They used to be read as three parts

How it was tested

• Update: 1.3.0 updated to 1.3.1 from the dashboard on OpenWrt 24.10. With Preview builds off it stays on 1.3.1, and with them on it's offered 1.3.1.1 and installs it. Turned back off, nothing newer is offered
• Router lab: 13 emulated routers, with the HTTP/3 check now talking to a DNS-over-HTTP/3 server the lab runs itself, plus every situation in the When things go wrong table on 1.3.0.1, which has the same update code
• Not tested yet: a real router

Update

Settings → Updates → Check now → Update to 1.3.1

Fengard 1.3.1.1 · Midgard Pre-Release

This is a preview build. Routers get it when Settings → Updates → Preview builds is on.

Faster DNS over HTTP/3

fengard-h3 now beats quic-go's HTTP/3 client (default settings) on every measurement, against the same server:

	fengard-h3	quic-go
Lookup on an open connection	415 µs	477 µs
CPU per lookup, 64 at a time	60 µs	124 µs
First lookup on a new connection	2.65 ms	2.86 ms
Memory an open connection holds	104 KB	190 KB
Memory allocated per lookup	1.2 KB	15.5 KB
Lookup after a quiet spell	0.9 ms	5 s, first try fails

• No waiting after a quiet spell. A connection used in the last five minutes gets a tiny ping before the server would drop it, so the next lookup doesn't need a new handshake
• Connects early. Switching HTTP/3 on, or Fengard starting with it on, opens the connection straight away instead of on the first lookup
• Cheaper reconnects. A new connection resumes the last TLS session, which skips the certificate check. The DNS page's status says when it did
• Less work on routers without AES hardware (most MIPS and older ARM), where every packet's header protection no longer allocates memory

Fixes

• A preview's own router-install.sh now installs that preview. It used to fetch the latest full release

How it was tested

• Update: a 1.3.1 router with Preview builds off says it's up to date, and with them on it updates to 1.3.1.1. On a preview with them off, a newer preview isn't offered and the overnight auto install leaves it alone. With them on, it's offered and installs overnight. A router on a preview moves to the next full release from the dashboard
• Router lab: 13 emulated routers and every situation in the When things go wrong table. The HTTP/3 check now talks to a DNS-over-HTTP/3 server the lab runs itself instead of Cloudflare, after the test network started blocking HTTP/3 to public resolvers, so every router including the one with no internet checks HTTP/3
• HTTP/3 lab: everything from 1.3.0 plus the connection staying open across a quiet spell, session resumption and the early connect, under the race detector. The changed packet code was fuzzed again
• Not tested yet: a real router

Update

Settings → Updates → turn on Preview builds → Check now → Update to 1.3.1.1

Fengard 1.3.0 · Midgard

New

• DNS over HTTP/3. DNS → Use HTTP/3. Lookups to https:// resolvers go over HTTP/3 (QUIC) instead of HTTP/2, which copes better with lossy Wi-Fi, mobile data and busy links. Cloudflare, Google, Quad9 and AdGuard all work. The DNS page shows which protocol each resolver is actually using
• fengard-h3. HTTP/3 comes from Fengard's own QUIC client, written for this and nothing else. It only does what DNS needs, so it adds about 0.1 to 0.3 MB to the program instead of the several MB a general purpose QUIC library would. The encryption is Go's own TLS 1.3, nothing home-made there
• Off costs nothing. With the switch off there are no connections and no extra memory. It's off by default
• Falls back by itself. If UDP is blocked somewhere between you and the resolver, Fengard goes back to HTTP/2 for that resolver and tries HTTP/3 again later, so turning it on can't break DNS
• Google DoH and AdGuard DoH presets on the DNS page

How it was tested

• Against real resolvers: Cloudflare, Google, Quad9 and AdGuard, both addresses each, including 20 lookups at once over one connection
• Against another QUIC implementation: quic-go through a proxy that breaks things on purpose. Up to 30% of packets lost each way, packets reordered and duplicated, the server asking for a retry, 60 KB answers, the server restarting or saying goodbye mid-lookup, the router's NAT changing its port, a server that only allows 4 lookups at a time, and 250,000 lookups on one connection while the server changed its keys. No lookup failed. It's in dev/h3lab and runs in under a minute
• Fuzzing: every part that reads data from the network got random input for a minute each with no crashes
• Router lab: 13 emulated routers, every one with internet now also checks lookups over HTTP/3 to Cloudflare, plus every situation in the When things go wrong table
• Update: 1.2.6 updated to 1.3.0 from the dashboard on OpenWrt 24.10, then HTTP/3 switched on and off
• Not tested yet: a real router. If something looks off, switch HTTP/3 off and DNS carries on over HTTP/2

Update

Settings → Updates → Check now → Update to 1.3.0

Then DNS → pick a DoH preset → Use HTTP/3 → Save resolvers.

Thanks to u/xPliZit_xs on Reddit for asking for HTTP/3.