What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Beta Asuswrt-Merlin 3004.388.9 Beta is now available

RMerlin

Asuswrt-Merlin dev
Staff member
Asuswrt-Merlin 3004.388.9 Beta 1 is now available. Note that the BCM4912 devices are being migrated to 3006.102, therefore they will not be included in this or in future 3004.388 release.

The focus of this release is the merge of an updated GPL, updated components, and a few enhancements to VPN clients.

List of models that are not included in thise release, as they will be included in the next 3006.102 release:

Code:
 * GT-AX6000
 * ZenWifi Pro XT12
 * GT-AX11000 Pro
 * GT-AXE16000
 * RT-AX86U Pro
 * RT-AX88U Pro

Changelog:
Code:
3004.388.9 (xx-xxx-2025)
  - NOTE: BCM4912 models such as the GT-AX6000 have now been
         migrated to the 3006 firmware series.

  - NEW: (re-added) VPN interface selector on the Speedtest page,
         to test a VPN tunnel's throughput.
  - UPDATED: Merged GPL 388_25373.
  - UPDATED: dropbear to 2025.87.
  - UPDATED: OpenVPN to 2.6.13.
  - UPDATED: dnsmasq to 2.91.
  - UPDATED: miniupnpd to 2.3.7 (20250207 snapshot)
  - UPDATED: amtm to 5.2 (decoderman)
  - CHANGED: VPN public IP retrieval now uses HTTP instead of STUN,
             which should be more reliable through a VPN tunnel.
  - CHANGED: Model name will be inserted in the filename of JFFS
             backups.
  - CHANGED: Improved refresh behaviour of the VPN Status page.
  - CHANGED: Set rp_filter mode to "loose" on Wireguard client
             interfaces.
             Fixes gettunnelip.sh and onboard speedtest.
  - CHANGED: Display public IP address for Wireguard clients.
  - CHANGED: Make PCP requests also honor the Secure Mode setting
             (Self-Hosting-Group)
  - CHANGED: Settings/JFFS backup uploads file picker  will filter by
             file extension.
  - CHANGED: Added dhd userspace tool to RT-AX88U and GT-AX11000.
  - CHANGED: WAN IPv6 provided as second argument to the ddns-start
             script.
  - FIXED: CVE-2024-9143 in OpenSSL (Debian backport by RSDNTWK)
  - FIXED: Missing icon for the GT-AX11000 on AiMesh page.

Please keep discussions on this specific release. The thread will be locked once feedback dies down.

Downloads are here.
Changelog is here.
 
Known issues:
  • Cannot edit a client entry on the Networkmap (part of a previous fix lost in GPL merge, fixed)
 
Last edited:
Any chance that you'd consider maintaining the "transitioning" devices (e.g., RT-AX88U Pro) for a version or two on 3004, until the 3006 kinks are all worked out, and for those who have 3004-based mesh nodes?

Asking for a friend...
 
Last edited:
Any chance that you'd consider maintaining the "transitioning" devices (e.g., RT-AX88U Pro) for a version or two on 3004, until the 3006 kinks are all worked out, and for those who have 3004-based mesh nodes?

Asking for a friend...
None. I'm not going to ask Asus to generate two different GPLs for each model when getting a single GPL is already taking months of wait.

The previous 3004.388 release isn`t going to stop working tomorrow, so just keep using that if 3006.102 does not fit you.
 
Filthy upgrade from the Alpha 2 on my APs tonight. No issues to report so far. All devices re-connected no problem.
 
dirty update from 3004_388.8_4 - all OK!
 
Dirty upgrade from 388.8_4. No issues noted. Thank you for all of the work that you put into this project.
 
Dirty upgrade from 388.8_4. No issues noted. Thank you for all of the work that you put into this project.
Which router model???
 
Played it safe after my experience with Alpha2 (starting here "My Fun with Alpha 2") , so I started started with with the lowest risk node, the one with the fewest devices.

Same issues as before almost nothing bound to the node would connect, unbind the device then it would connect to the other node or router. Even devices on the router and other node were impacted and showed as if the were bound to the updated node even as they were connected to the Router or other node, and I couldn't unbind them (though they should not have been bound because they weren't on 388.8-4/before). Others showed as unconnected until unbound, and other showed as connected to the other node or router, even the unbound ones showing up as bound to the 388.9 beta node even though they weren't.

Fortunately in trying to unbind device by device I happened upon one that then caused the others to unbind, unfortunately I didn't document in my haste.

Now as those bound devices that would not connect to 388.9 beta node, now unbound, do connect to the router and other node, but will not connect to the 388.9 beta node even though they may be inches (in two cases) from the node. As soon as I try to rebind them to the node, they disconnect, and fail to reconnect, unbind then device and immediately to device connects to the other node or router.

Even after multiple reboots of all three, which the first boot cleared up the bound clients that had never been bound or even bound to the 388.9 beta node allowiing them to unbind (updating the GUI). Multiple reboots still prevent any other WiFi devices (2.4Ghz or 5GHz) once any one connects to the upgraded node. To get connectivity the other WiFi devices have no choice but to use the router or other node. Then they connect fine.

Though not optimal as I had it under 388.8_4, I'm keeping the one node on the Beta in case anyone asks for any data to better capture what might be going on.

So currently,
1743606998352.png


To recover all three from Alpha 2 I had to factory reset, and redo the AiMesh nodes, re-adding them to the router and recover from a backup the day prior. If I have to do that again, the impact is minimal now so I can keep it in this state and recover later if I even have too. But for now, holding off upgrading the Router and other node. The nodes are Ethernet connected, so restablishing the mesh was quick and painless. Wired devices on the Router or either of the nodes aren't impacted.

Fun times

The one device that connects to the node over WiFi. I unbound it and hit optimize to reconnect, it stayed the same. Another device, as the one was unbound, tried to bind it to the node, no luck. even as its inches from the node I unbound it, and it connected to the Router (farthest away respectively). Unbound and connected the one WiFi device connected to the Beta node, it connected to the other node. So I tried to connect a device that would'nt connect by binding it, no such luck, it disconnects and won't reconnect until it's unbound and conects to the other node.

Leaving it all alone until tomorrow to see if anything changes 🤷‍♂️
 
Not sure if anyone else is getting this on RT-AX86U for those that have added the DIVERSION ad blocking add-on, but on three of these in separate locations on different WAN networks, the upgrade goes fine, but the DIVERSION tab when clicked does not show the usual settings page and only shows a small part like the heading on Microsoft Edge Chromium on Windows 11. Even tried a new install (fresh) of Chrome browser on a VM and the same results.

This is the latest general release of the add-on for Diversion. Cleared the browser cache, tried InPrivate mode too. Could administer the add-on by AMTM though using SSH access.
 
I spoke too soon. Diversion GUI does not render correctly, FF Nightly (x64), Linux
Screenshot_2025-04-02_14-35-06.jpg
 
Hopefully this is helpful. I am not familiar with Developer Tools.
 

Attachments

  • Screen 1.png
    Screen 1.png
    244.4 KB · Views: 42
  • Screen 2.png
    Screen 2.png
    228.8 KB · Views: 40

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top