v3.6.2 — RT-BE86U keeps 5 GHz after a Guest Network Pro save, API keys inside a source address, review fixes
Everything in v3.6.1 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. Two have an effect on one side only: the
Surfshark handlers exist only on 3006.102.10, and the Wi-Fi driver gate is compiled only for the models in ASUS's own
list (RT-BE86U in this fleet).
- RT-BE86U: the 5 GHz radio survives a Guest Network Pro save. Field report (RT-BE86U, v3.6.0): saving a Guest
Network Pro network left the 5 GHz radio down about half the time - LED off,wl1"wl driver adapter not found" -
until a power cycle. On this model a wireless restart re-runsinit_nvram(), and ASUS's closed
reload_wl_check()then reloads both Wi-Fi drivers live whenevered_thresh_reloadis set: on any difference in
the stored energy-detect values, not only on a change of ED mode. The drivers now stay loaded unless the ED mode
(no_dy_ed_thresh_ctrl) changed; either outcome is one log line. - Wallguard and Dreadwatch: an API key inside the source address. For suppliers that take the key in the URL,
type$APIkeywhere it goes (for examplehttps://threatfox-api.abuse.ch/v2/files/exports/$APIkey/hostfile.txt)
and save the key as before. The fetch inserts it %-encoded through the root-only curl config, never on a command
line.$APIkeyis the only$a source address may carry, and never in the host; keys stay write-only. - Wallguard: no abuse.ch templates in "Add a source". ThreatFox and URLhaus are threat feeds and stay in
Dreadwatch's templates; Wallguard's form loses its Template row. - A source with its API key in a header no longer follows redirects. curl sends custom headers on every request
it follows, to any host, so these fetches run withmax-redirs = 0. A redirect fails with curl error 47, named in
the Wallguard and Dreadwatch logs. A key inside the address still follows redirects (it rides the first request). - MAC address check: a separator out of place is refused.
isValidMacAddress()passed 12 hex digits followed by
a separator and anything after it (the stock loop stopped there unread). It now returns false. On 3006.102.10 the
AiMesh admin actions that take a node MAC rely on it alone (signed-in admin only); on 3006.102.8 Reaper's own
check stands there as well. - Surfshark sign-in handlers off (3006.102.10).
surfshark_login.cgiandsurfshark_2fa.cgi, new with GPL
102_40585, sign in to a third-party VPN service, and no shipped page calls them. They are compiled out, as the
Instant Guard handler was.
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.2_BETA_nand_squashfs.pkgtb
| b72160bbb7f3314be1267eddd968d92eadab5162e64f7532a374803630fee193
|
| Standard | BQ16_3006_102.8_Reaper_v3.6.2_BETA_noMCP_nand_squashfs.pkgtb
| dbfb5c9d32a89a7c6c6038cc8af2a7bd5bd6620980475c4201fde1c8aadca698
|
Verify a download against the attached SHA256SUMS-BQ16-Reaper_v3.6.2.txt.
Corresponding source & reproducibility
The BQ16 image for v3.6.2-beta is built from this repository at tag v3.6.2-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.2-beta-BQ16 (patches + docs).