v3.6.4 — Guest Network Pro through an OpenVPN client has Internet, Rule Status reads VPN routing, device pickers on VPN Director and DHCP reservations
Everything in v3.6.3 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.
- Guest Network Pro: a network sent through an OpenVPN client has Internet. Field report (RT-BE86U, v3.6.3): a
Guest Network Pro network bound to an OpenVPN client from the Network page had no Internet, while a VPN Director
rule for the same subnet worked. Routing, firewall and NAT were right; the network's DNS was not. Its dnsmasq asks
the VPN's resolvers from the router itself, and nothing sent those queries into the tunnel (only the WireGuard path
installs that rule), so they left by the WAN, or down another tunnel whose resolver had the same address. Each
resolver is now bound to the client's tunnel in the network's servers file (server=10.9.0.1@tun13), and dnsmasq
keeps the capability that binding needs when it reads a servers file. - Rule Status: a guest network sent through a VPN is a note, not a red G2. Same report: the check went red at the
FORWARD tail for that network although its forwarding was right - its Internet path is the routing table its
ip ruleselects, which the check does not read. The walker (v1.11) now reads each rule's input interface: a bridge
an unconditional rule sends to a table of its own is reported as policy-routed, with the rule, the table and its Kill
Switch partner named, and is not judged against the WAN path. - VPN Director: picking a device fills the Description with its name. Only while the field is empty or still
holds the last name filled in, never over typed text; characters the description refuses are dropped. - LAN > DHCP: a device list when adding a reservation. The MAC field offers this LAN's connected devices that
hold no reservation yet, name and address, sorted by address; picking one fills the address and shows the device's
name as the host-name placeholder. The stock add row had such a list; the Reaper page did not. - Diagnostics v1.3.53: two address-shaped names stay readable. The report's sanitizer masked the speed-test
engine's four-part version and a WDS link's interface name (wds1.1.1.0) as external addresses; the version
prints as "v3.8.0 build 235" and WDS names are kept.
Images & checksums (BQ16)
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 | BQ16_3006_102.8_Reaper_v3.6.4_BETA_nand_squashfs.pkgtb
| 7006c78abdebc10254e005195c47a4b5b46d0650715c7779ed87cc944189587b
|
| Standard | BQ16_3006_102.8_Reaper_v3.6.4_BETA_noMCP_nand_squashfs.pkgtb
| 62aa7b7c65689f90bf39c3f477645a6e70ee4c85181b9ca61b5ccafe9419a01d
|
Verify a download against the attached SHA256SUMS-BQ16-Reaper_v3.6.4.txt.
Corresponding source & reproducibility
The BQ16 image for v3.6.4-beta is built from this repository at tag v3.6.4-beta-BQ16: 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.6.4-beta-BQ16 (patches + docs).