v3.1.4 — an OpenVPN server can be created again, DDNS stops restarting itself, and the GT-BE19000 joins the fleet
- OpenVPN server certificates can be generated again. From the OpenSSL 3.5 move in v3.1.0
onward, every server certificate this firmware tried to make came out as a key with no
certificate - first-time setup and the v3.1.1 repair path alike.pkitool --serverput
-extensions serveron the certificate request as well as the signing call, and that section
carries anauthorityKeyIdentifier, which cannot be computed for a request because there is no
issuer yet. OpenSSL 1.x ignored it; 3.x refuses the whole request, which stopped pkitool before it
ever reachedopenssl ca. The extensions now go only on the signing call, where the issuer exists
and they resolve - confirmed on the router: the issued certificate carries its server extensions
including a real authority key identifier. Dropping them from the request costs nothing, since
openssl canever copied request extensions in the first place. The repair path's diagnostics
were rebuilt with it: it used to discard the tools' own output and then blame the signature for
every possible failure, including the one where the certificate had never been created. It now
keeps the log and says which stage failed. - DDNS no longer restarts itself every 30 seconds on a dual-WAN router whose IPv6 lives on the
other WAN. Three stock behaviours lined up: the DDNS start tests its own WAN's interface for an
IPv6 address while the enable check is global, so a box with IPv6 only on the secondary WAN failed
it on every run; failing it cleared the "IPv6 updated" flag; and the watchdog's "already updated,
stop retrying" exit requires that flag whenever IPv6 DDNS is on - which is the default. The retry
machinery is built for an address that has not arrived yet; this configuration made "yet" never
come, so DDNS was stopped and restarted for the life of the boot, four log lines at a time. It now
reports the missing address once, when the state changes, records that this WAN has no IPv6, and
the watchdog stands down - the IPv4 record being correct and the IPv6 one unobtainable. It resumes
on its own the moment any interface gains IPv6. Thecurrent ipv6_service: x | old: xline that
printed on every run now prints only when the service actually changed. - The EDNS Client Subnet option is gone - page, emitter, default and all 25 language packs. A
niche switch, removed at the root so a router that had it enabled is not left sending client
addresses with no way to stop. Nothing else changes. - The GT-BE19000 joins the fleet. Same BCM4916 silicon and NAND layout as the RT-BE96U. Its
onboarding had imported 4 of the 50 per-model directories the tree carries; the other 46 are each
copied by a rule that fails silently, so the first builds died one missing file at a time -lzop,
libptcsrv.so,libbcm.so, then three symlinks a directory-only audit had skipped. All of it
came from the model's own GPL drop. Its radio firmware could not: no GPL drop ships it. Both of
its radio chips' firmware (6717a0and6726b0) come from the vendor's own GT-BE19000 image - the
non-AI SKU this build targets, which carries both where the AI SKU carries only6726b0- and each
matches the host driver's Broadcom version exactly. Because presence is not identity - and because
ASUS's guidance is that the wrong radio firmware does not degrade a radio but locks the router out,
recoverable only with the recovery tool or a manual reflash - the build now proves identity three
times with one script (reaper_dongle_id.sh): Broadcom stamps the model name into everyrtecdc.bin,
and a blob naming any other model - a sibling's, or the other SKU's - stops the local engine and the
clean room BEFORE a make, and failsreaper_verify(dongle-model, every staged blob) after it.
It carries its own u-boot rtl8372 archive (its blob differs from every other model's), a
platform archive for the closed layer the pinned upstream does not have - exactly as GT-BE98
does - and a first identity overlay of twelve files, derived rather than hand-listed, which is
why it includes the first-boot Wi-Fi page every earlier overlay missed. It is on the CI roster
and publishes as a prerelease. - The fleet cut can now delete a language-pack key. Its dictionary guard tolerates keys canon
removed since a sibling last synced, but it measured "last synced" withmerge-base, which for
branches that are ported by file copy and never merged sat frozen at July's v1.5.0d - before any
of this rung's removed keys existed. The reference is now canon's previous version commit, which
is what every sibling actually synced from. A key canon never had still blocks, as it should.
Images & checksums (GT-BE98)
Two flashable images: + AI Advisor (default) and Standard (noMCP, all AI components compiled out entirely). Flash the *_nand_squashfs.pkgtb via Administration > Firmware Upgrade.
This is a beta release. Its filename carries
_BETAand the router reports the same string on the dashboard and the About page, so you can always tell which channel a flashed image came from. Stable releases carry no marker.
| Variant | File | SHA-256 |
|---|---|---|
| + AI Advisor | GT-BE98_3006_102.8_Reaper_v3.1.4_BETA_nand_squashfs.pkgtb
| db0ff2778892783424c883d7143b35069b2dff72e78b9113cb268f0440549ef7
|
| Standard | GT-BE98_3006_102.8_Reaper_v3.1.4_BETA_noMCP_nand_squashfs.pkgtb
| 0d87fa918812cf2f2804337e710dd8e1845d0e2833d4233fd0d9510da1d131ad
|
Verify a download against the attached SHA256SUMS-GT-BE98-Reaper_v3.1.4.txt.
Corresponding source & reproducibility
The GT-BE98 image for v3.1.4-beta is built from this repository at tag v3.1.4-beta-GT-BE98: the pinned Asuswrt-Merlin base (3006.102.8-beta2, a7ebfa133a) plus the complete patch series. The tag freezes the exact source that produced it.
- Patches:
patches/ - Provenance record:
provenance/manifest.json - How to verify:
docs/REPRODUCIBILITY.mdanddocs/SOURCE-AVAILABILITY.md
The auto-attached Source code (zip/tar.gz) asset below is this repository at tag v3.1.4-beta-GT-BE98 (patches + docs).