v3.7.8 — mDNS across networks; the Guest Portal passcode is back; VPN profiles that reconnect by themselves; VPN server clients reach isolated networks again
Everything in v3.7.7 is included. Both lines carry the same changes: RT-BE96U, RT-BE86U, RT-BE88U and GT-BE98 Pro on
3006.102.10; GT-BE98, GT-BE19000, BQ16 and BQ16 Pro on 3006.102.8.
- mDNS across networks. Devices on the main network and on every network with Access Intranet on can find each
other (casting, printers, AirPlay). A Guest Portal network and a network with Set AP Isolated on never take part,
and the router no longer answers mDNS on an isolated guest network. A switch on the Tweaks page, on by default. - Guest Portal: the passcode is back. A Free Wi-Fi portal can ask for a passcode again (Network page, wizard and
Portal tab); on v3.7.7 the field was gone and a portal that still had one refused every entry. After sign-in a
phone shows one success page instead of two. - VPN profiles bound to a network connect by themselves. A WireGuard client whose server name could not be looked
up when it started stayed down until it was switched off and on by hand. It is now restarted when the name
resolves, and after five minutes without a handshake. Choosing a VPN profile for a network switches the profile
on, and a network's profile is started when the network is applied. - VPN server clients reach isolated guest networks again. The guest isolation of v3.7.7 also shut out clients of
the router's own WireGuard / OpenVPN server. They can open connections into an isolated guest network again (the
server's own Access Intranet setting still decides); devices on that network can answer them, not start
connections to them. Not into a Guest Portal network, and not while the network's Kill Switch is on. - Guest DNS stays in place. The rule that keeps portal guests on their network's own resolver was lost whenever
a portal started or the Internet connection came back; it is put back each time. - Rule Status. Three "Guest network: DNS at its gateway" rows read inconclusive on v3.7.7 with nothing wrong on
the router; the checker now reads the rule they depend on. - Smaller fixes. System Log > IPv6 names devices the way the Devices page does (a device with a static address
showed as unknown); the Wi-Fi quick connect sheet stays open until it is printed.
Images & checksums (RT-BE86U)
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 | RT-BE86U_3006_102.10_Reaper_v3.7.8_BETA_nand_squashfs.pkgtb
| ecf8e7ac7fe532feb957a56495f8e751504ea3abc46d56b3427df6a6c6c163bc
|
| Standard | RT-BE86U_3006_102.10_Reaper_v3.7.8_BETA_noMCP_nand_squashfs.pkgtb
| 35bb8a3bc933b3264690f32ebec27d49f4cac4cb3e92a362cdeebff587f21ec6
|
Verify a download against the attached SHA256SUMS-RT-BE86U-Reaper_v3.7.8.txt.
Corresponding source & reproducibility
The RT-BE86U image for v3.7.8-beta is built from this repository at tag v3.7.8-beta-RT-BE86U: the pinned Asuswrt-Merlin base (3006.102.10, ca72a61f8bc) 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.7.8-beta-RT-BE86U (patches + docs).