https://n00bunlimited.net/ News Taken from the IPfire blog en Sat, 26 Sep 2026 22:01:53 GMT vBulletin 60 https://n00bunlimited.net/images/misc/rss.png https://n00bunlimited.net/ https://n00bunlimited.net/home/forum/site-news/ipfire/80492-ipfire-walk-through-and-review Mon, 07 Sep 2026 14:54:13 GMT ]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80492-ipfire-walk-through-and-review https://n00bunlimited.net/home/forum/site-news/ipfire/80491-ipfire-2-29-core-update-203-released Mon, 20 Jul 2026 09:00:48 GMT
This is the release announcement for IPFire 2.29 – Core Update 203, which is now available.

This is a substantial update, and its centrepiece is a fundamental change to how IPFire handles DNS: we have replaced Unbound with Knot Resolver, giving us a more flexible foundation and a range of new capabilities, from a DNS Firewall to encrypted upstream forwarding. Alongside it, the WiFi access point gains support for the 6 GHz band, and there are the usual security fixes and package updates throughout. These changes reach into a core part of the system, and we're grateful to everyone who helped test the release candidate over the past weeks and reported back.

DNS: Moving from Unbound to Knot Resolver

With this release, IPFire replaces its DNS Resolver with Knot Resolver.

This is a significant change under the hood, and not one we made lightly. Unbound has served IPFire well for many years and remains an excellent resolver. But DNS has quietly become one of the most important parts of the modern network. It is no longer only about turning names into addresses — it increasingly carries the information other protocols rely on to connect quickly, securely and privately, from encrypted transport to the records clients use to establish encrypted connections. To keep building on top of DNS, we needed a resolver we can extend and integrate deeply with the rest of IPFire. Knot Resolver's modular, scriptable architecture gives us exactly that foundation.

What this brings you today:

• Encrypted upstream forwarding (DNS over TLS) — queries to your chosen upstream resolvers can now be sent over TLS, so they can't be read or tampered with in transit.
• DNS Firewall — block malware, advertising and whole categories of unwanted domains at the DNS layer.
• Encrypted zone data (over TLS) — the DNS Firewall's filtering and policy zones are now pulled over an encrypted connection by zone-sync, a new tool we built in C. Updates are transferred incrementally and can no longer be read or tampered with in transit.
• SafeSearch — enforce safe search across the major search engines and YouTube for your whole network.
• Conditional forwarding — send queries for specific zones to specific servers. (Note the change below.)
• Local overrides — define your own DNS records for local hostnames.
• DHCP integration — a custom module makes hostnames from DHCP leases resolvable in DNS, replacing the old Unbound DHCP Leases Bridge with no loss of function.

Under the hood:

• Persistent Cache — the cache now survives restarts, so resolution stays fast after a reboot and there's less load on upstream servers.
• Shared state across multiple workers — Knot Resolver uses several worker processes that share one cache and state, making efficient use of multiple CPU cores without fragmenting the cache.

Please note: Forwarded zones can no longer be specified as fully-qualified domain names. You now need to replace any entries on the DNS Forwarding page that use FQDNs with IP addresses.

A note on what went into this release: replacing the DNS resolver was far from a drop-in swap. Alongside integrating Knot Resolver itself, we wrote a good deal of new code — including custom modules for DHCP and filtering, and zone-sync, a tool we built in C to keep the DNS Firewall's data current over an encrypted connection.

WiFi: Support for the 6 GHz Band

The IPFire WiFi access point now supports the 6 GHz band, opening up the spectrum introduced with WiFi 6E and WiFi 7.

Why this matters:

• More room, less interference — the 6 GHz band is new and largely empty. Without decades of legacy devices crowding it, wireless clients get cleaner airtime and more stable connections, even in busy neighbourhoods.
• Wider channels, higher throughput — the additional spectrum leaves room for many more wide (80 and 160 MHz) channels, so you can run faster connections without them overlapping and interfering with one another.
• No radar detection, no interruptions — unlike parts of the 5 GHz band, the 6 GHz band does not require radar detection (DFS). The access point starts up immediately and can never be forced off its channel by a radar event, so there are no sudden dropouts.

We have also fixed a bug that prevented the access point from starting when a 40 MHz channel width was combined with a manually selected channel.

Misc.

• AWS: IPFire can now retrieve EC2 instance metadata using IMDSv2, the token-based and more secure version of the metadata service that AWS now recommends and increasingly enforces by default. This means IPFire runs correctly on instances configured to require IMDSv2, while IMDSv1 remains supported for existing deployments.
• The microcode for some Intel processors has been updated to version 20260512 to address a vulnerability filed as INTEL-SA-01420
• A bug with Perl failing to properly encode/decode UTF-8 strings has been fixed so that the web UI will show translations with non-ASCII characters properly again
• OpenVPN: The icon to download the configuration has been replaced by a clearer version; and for Roadwarrior clients with a static IP address allocation, the name of the subnet is now shown next to the connection.
• sysklogd will now listen on localhost again, which is useful for chrooted processes that want to log messages
• Updated packages: BIND 9.20.23, Boost 1.90.0, coreutils 9.11, btrfs-progs 7.0, e2fsprogs 1.47.4, elfutils 0.195, expat 2.8.1, fcron 3.4.1, fontconfig 2.18.1, gdb 17.2, gnupg 2.5.20, GRUB 2.14, grub-btrfs 4.14, iana-etc 20260511, krb5 1.22.2, less 702, libedit 20260512-3.1, libksba 1.8.0, libloc 0.9.19, libunistring 1.4.2, libusb 1.0.30, LuaJIT 2.1.707c12b, LVM2 2.03.41, meson 1.11.1, nettle 4.0, OpenVPN 2.7.4, rrdtool 1.10.3, SQLite 3.53.1, strongswan 6.0.7 (CVE-2026-47895), Suricata 8.0.6, util-linux 2.42, vim 9.2.0526, which 2.25, xfsprogs 7.0.1, zone-sync 0.0.2

Add-Ons

• Updated packages: dnsdist 2.0.6, ntfs-3g 2026.2.25, Postfix 3.11.3, rsync 3.4.3, samba 4.24.2, spice 0.16.0, spice-protocol 0.14.5, tmux 3.6b, tshark 4.6.6
• Zabbix Agent: Fixes for OpenVPN 2.7 status parsing and ping error handling have been applied

Thank You

Core Update 203 reaches into one of the most fundamental parts of the system, and getting there took months of work: rebuilding DNS resolution from the ground up, writing new tooling like zone-sync, and testing all of it against real-world traffic. We're especially grateful to everyone who ran the release candidate, filed bugs, and helped us catch issues before they reached the wider community.

Work like this is slow, detailed and largely invisible, and it is only possible because IPFire is supported by the people who rely on it. If this release is useful to you, please consider making a donation — it is what lets us keep building.

Thank you for using IPFire.


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80491-ipfire-2-29-core-update-203-released https://n00bunlimited.net/home/forum/site-news/ipfire/80489-from-days-to-hours-ipfire-s-risc-v-builds-get-a-real-machine Thu, 16 Jul 2026 09:30:13 GMT Building IPFire 2 can be painful. The build system requires that large parts of the distribution are built from scratch each time we run a build....
Building IPFire 2 can be painful. The build system requires that large parts of the distribution are built from scratch each time we run a build. Usually that takes a couple of hours, but for one architecture, it has been taking days. What we call a Nightly Build has actually been taking more than a whole weekend; we needed to get it back down to something that could finish overnight.

If you have been following the IPFire development team for some time, you know that we are quite keen to make IPFire run on any kind of suitable hardware. We have been early adopters for ARM - back in the day when 32 bit ARM was very painful - and we ported IPFire to RISC-V a couple of years ago, too. However, we didn't have any suitable hardware to build it as it wasn't available at all at the time, so we had to fall back on an emulated build inside our infrastructure. Every command that is being called will have to be interpreted just-in-time from the riscv64 instruction set and converted into runnable x86 code. This is a process that is extremely slow; so slow that day-to-day development is virtually impossible for RISC-V.

Ending The Emulation Bottleneck

This didn't bother us too much at first - RISC-V is still a second-class citizen in IPFire and we are early to the party. But to move it forward, we needed to get rid of the emulation bottleneck.

Some months ago, we pre-ordered a Milk-V Jupiter 2 which has finally arrived.

Previous experiences with early-bird ARM hardware have not been great. Lack of support in the Linux kernel, stability issues and a small community have resulted in lots of products being shelved. With RISC-V and Jupiter 2 it seems to be the exact opposite. We chose from a couple of distributions, used a custom kernel from SpacemiT, and had the whole thing set up very quickly.



The Rough Edges

Some caveats had to be sorted though: There are some outstanding issues with the power management of the device and support for the NVMe SSD that we added is not too stable yet. The biggest issue however is that the device generates a lot of heat - even when it is idle. Idling at 74°C, the board climbed past 85°C within minutes of starting a build, which required us to improve the cooling a little. Hopefully the power management will improve soon so that we can operate the system at a more sustainable temperature soon.

The Result

Despite these smaller issues, our Milk-V Jupiter 2 has now been added to our build system for IPFire 2 and it has started to compile the nightly builds. The build time is down from a whopping 54-56 hours in the emulated setup to only seven hours.

This is a huge step forward for us to actually work on the RISC-V ecosystem and only the start. As more RISC-V hardware is becoming available and as it matures, we intend to put more resources behind it. We want more choice, a real alternative from x86, and we are hoping to see very small, yet very powerful IPFire systems on RISC-V over the next couple of years.

Where We Go From Here

We see vast potential in RISC-V as a target architecture and we believe that now is the time to invest in it. Let's iron out the gaps in hardware support, build out the IPFire to take advantage of the features of the hardware, and get it to a viable, production-ready alternative to ARM and x86.

When will it be ready? We don't know, yet. But the only way to find out is to start now. So join us and contribute. Help us test and send us feedback.


More...]]> Ipfire siosios https://n00bunlimited.net/home/forum/site-news/ipfire/80489-from-days-to-hours-ipfire-s-risc-v-builds-get-a-real-machine