v2.7.8 — UPnP stops half-working, and the QoS page shows its numbers again
- UPnP is gated by one switch again, not two that could disagree. The daemon read the
per-WAN-unitwan<N>_upnp_enable; the firewall rules that actually forward the traffic read the
genericupnp_enable. Nothing kept the two in sync, so either half could be on while the other
was off — and every status surface still reported UPnP healthy. Confirmed on two boxes in both
directions: one with the daemon up, real console mappings listed, and no rule to DNAT them (the
console reported NAT type Moderate); one with the rule installed and passing traffic but the
daemon never started. Both halves now derive from shared helpers, so they cannot disagree by
construction, and the WAN page's Apply writes both keys in lockstep — the page only ever posted
the unindexed name, so the generic key had had no writer on that path at all. - The QoS page shows live per-class figures again. On the Traffic Manager page the rate and
drop columns stayed blank on every class row, on routers where the engine was demonstrably
working. The page's stats request was missing the anti-CSRF token that the endpoint began
requiring in v2.5.0, so the router refused it before reading a single queue counter and the page
silently rendered nothing. The request now carries the token, the way the QoS Diagnostics page
already did. The diagnostics page was unaffected throughout, which is why the same numbers were
visible there. - The Gatekeeper device list no longer shuts the access-level menu under you. Opening a
device's Full / Internet only / Guest / Blocked menu and taking a moment to choose meant the
five-second status refresh rebuilt the table underneath — the row was replaced, and the open menu
went with it. The refresh now holds the repaint back while a menu is open and paints as soon as
you have chosen or clicked away, so nothing is lost and the list is still current. The same
applies to the default-policy and guest-hours selectors lower down the page. - The dashboard names the processor your router actually has. The System card's heading read
"4-core · BCM4916" on every model, because it was written when every supported model was a
BCM4916 — so on an RT-BE92U, which is a BCM6765, it confidently named the wrong chip. The little
per-core activity bars underneath were four fixed bars for the same reason: a router with fewer
cores left one permanently dark, and one with more simply did not show them. Both now come from
the router itself — the chip and core count from the same place the System Information page reads
them, and one bar per core the system actually reports. The CPU percentage was always correct on
any core count and is unchanged. - Warden shows how full the threat set is, and a dead custom feed can no longer eat the update
window. The threat set has a hard ceiling past whichipsetsilently drops entries, and
nothing on the page reported occupancy — the "prefixes loaded" figure counts the geo set, not
this one. The status page now reads "Threat entries: N / 524,288" beside it, from the same
constant the sets are built with, so the two cannot drift. Separately, custom feeds now get a
shorter retry and timeout than the curated and geo fetches, which are known-good hosts worth
waiting on: eight unreachable custom feeds cost about four minutes of an update window instead
of sixteen. A timeout still keeps the previous set and logs the failure, so a slow feed degrades
to "no refresh", never to "no data". - The About tile no longer strands a strip of empty rail. The tile is sticky with a 14px
offset, but the rail reserved 56px of bottom padding — and a sticky element is held inside its
container's content box, so at the end of a long page the tile settled 42px above where it had
been riding, revealing bare rail underneath. The padding now matches the offset on both chrome
pages. - Build-side: the "Patches applied" figure comes from the tree, and the sibling images stop
shipping half a rewrite. The stamp had been derived by scraping the publishedpatches/
directory, which produced three wrong or empty counts across earlier releases; a new
patch_count.shcounts what the series would actually emit from the tree, and the verify gate
now fails a build whose stamp is empty, non-numeric, stale, or disagrees with the tree. The
port-protection list, which holds certain files back from the per-model sync, had been holding
back two pages that gate at runtime on the model rather than per branch — freezing four sibling
models on a pre-2026-08-17 system-information chart while the other half of the same rewrite
synced. Both are released from the list, so the siblings carry the whole rewrite, and the
RT-BE92U gets its real animated header.
Images & checksums (RT-BE88U)
Two flashable images: + AI Advisor (default) and Standard (noMCP, all AI components compiled out entirely). Flash the *_nand_squashfs.pkgtb via Administration > Firmware Upgrade.
| Variant | File | SHA-256 |
|---|---|---|
| + AI Advisor | RT-BE88U_3006_102.8_Reaper_v2.7.8_nand_squashfs.pkgtb
| 1bd336d6c9ac402bd634638c71413c72f45ac0de858d5d5ed9a0c26f193d90c0
|
| Standard | RT-BE88U_3006_102.8_Reaper_v2.7.8_noMCP_nand_squashfs.pkgtb
| 2e0eef682fc30f5fc37f2768d247115533a02351c5ef6d2d85a011e83faf3276
|
Verify a download against the attached SHA256SUMS-RT-BE88U-Reaper_v2.7.8.txt.
Corresponding source & reproducibility
The RT-BE88U image for v2.7.8 is built from this repository at tag v2.7.8-RT-BE88U: 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/(0001-0550) - Provenance record:
provenance/manifest.json - Source tree hash (
release/src/router):14eabc38c3a4bb3fb35ecc8092b31f4a5e23dfbf-- reproduce bygit am --keep-crof the patches onto the base, thengit rev-parse HEAD:release/src/router. - How to verify:
docs/REPRODUCIBILITY.mdanddocs/SOURCE-AVAILABILITY.md
The auto-attached Source code (zip/tar.gz) asset below is this repository at tag v2.7.8-RT-BE88U (patches + docs).