Keeping the Netgate 3100 Alive, One Upstream Patch at a Time

Here at Netgate®, "End of Life" (EOL) rarely means "End of Software Updates." Hardware that customers depend on tends to outlive its formal product lifecycle by many years, and we think that is how it should be. The Netgate 3100 (formerly SG-3100) is a good example: an ARMv7-based appliance that reached end of sale in 2021 and EOL in 2023, yet with thousands of units still in operation in 2026, it remains widely deployed in the field. We have continued to ship pfSense® software updates for the 3100 long past its formal retirement, and the upcoming pfSense Plus 26.07 release will continue to support it. That ongoing commitment keeps us honest about a corner of the ecosystem that the rest of the industry has largely moved on from: 32-bit ARM.

Supporting 32-bit platforms in 2026 is not glamorous work. The wider open-source world increasingly assumes 64-bit targets, and that assumption quietly creeps into upstream code until a build breaks.

A recent example landed in our build of iprange, a small but heavily used utility from the FireHOL project for managing IP address sets. The tool reads IP addresses, CIDRs, ranges, and hostnames in any combination, normalizes them into optimal non-overlapping sets, performs very fast set operations (union, intersection, difference, complement), and easily scales to millions of input addresses. In pfSense software, iprange backs pfBlockerNG, which leans on exactly those capabilities to efficiently aggregate large lists of addresses.

The Problem

The iprange project gained IPv6 support in its 2.0.0 release. IPv6 addresses are 128 bits wide, and the cleanest way to do arithmetic on them in C is the compiler builtin __uint128_t. On 64-bit targets, this builtin is available and generates efficient code, but on 32-bit targets like i386 and ARMv7 it simply does not exist. This is the classic shape of a portability regression.

The Fix

Rather than patch this downstream and carry it along indefinitely, we sent the fix upstream. The fix keeps the fast path fast and isolates all the portability concerns in one place.

We added a single new header, src/uint128.h, that presents one uint128 type to the rest of the codebase and switches implementations based on what the compiler supports:

• On 64-bit builds, it simply typedefs uint128 straight to a __uint128_t and inlines the bare arithmetic, shift, and comparison operators. This compiles down to exactly the same machine code as before, with no abstraction penalty and no change in codegen on the platforms that already worked.
• On 32-bit builds, where the __uint128_t builtin is absent, it falls back to a portable {hi, lo} structure of two 64-bit halves, with the arithmetic, shift, and comparison logic written out explicitly, including manual carry handling.

Because every operation goes through the same small interface, the rest of iprange does not need to know or care which implementation is in play. The 32-bit fallback is the only code that had to be written by hand, and it lives behind a clean boundary that is easy to audit and test.

Before merging our fix, maintainer Costa Tsaousis (ktsaou) followed up with portability notes in the docs, a test that exercises the portable uint128 build path, and a tweak to make the binary metadata fixtures endian-neutral so the suite is meaningful across architectures, not just little-endian ones.

Why We Do This

We could have kept this as a local patch, but we did not for the same reason we contribute fixes back across the other projects we depend on. A patch that only lives in our tree is a textbook example of technical debt: something we have to reapply, retest, and rejustify on every version bump, forever. A fix that lives upstream is one that the maintainer, the next packager, or the next person trying to build on older hardware all benefit from and one we never have to think about again.

Upstreaming is also the right thing to do. We benefit enormously from open-source infrastructure, and the 32-bit corner of that infrastructure remains healthy only if the people who still care about 32-bit hardware keep it alive and useful. We intend to be one of those people for as long as there are 3100s in the field doing useful work for our customers.