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 3006.102.4 Beta is now available

Status
Not open for further replies.

RMerlin

Asuswrt-Merlin dev
Staff member
Asuswrt-Merlin 3006.102.4 Beta is now available. There are a number of significant things to note with this release:

1) BCM4912 models are now migrated to this 3006 code base. This includes the following device list:
  • GT-AX6000
  • zenWifi Pro XT12
  • GT-AX11000 Pro
  • GT-AXE16000
  • RT-AX86U Pro
  • RT-AX88U Pro

2) New addition - the RT-BE92U is now supported. Note that the GPL used for this initial support suffers from some CPU-related issues, so support for this model at this time should be considered EXPERIMENTAL. If you lose the ability to access the router, then power cycle it, that usually solves it. Beta 2 updated that device's GPL to 102_37526, which should be stable.

3) Beside the addition of new models, the focus of this release is the merge of GPL code (I currently need to manage three separate GPL versions for this release.....), updated components, and a number of fixes.

Update (3-May): 3006.102 Beta 3 is now available. Changes since Beta 2:
Wifi 7:
Code:
40adf8f5d5 Bump revision to 3006.102.4 beta 3
b4d835a202 Updated documentation
9b75a69006 webui: Add Control-D servers to DoT json database
10a2737649 webui: fix DDNS notification bell on main index page
c37ffe2268 webui: update policy handling for Boostkey support; remove GT-AC2900 boostkey handling
29a6b7677a webui: re-add option to hide DHCP/RA queries, lost in the 102_36216 GPL merge
8ea42a46d7 webui: minor chart tweaks to Sysinfo
879c3d2f13 webui: move option to enable custom scripts to the Basic table; remove dead JFFS2-related code
ab1d87aaf4 Move "Redirect webui access to www.asusrouter.com" setting to the new Tweaks page
bae1c058a9 webui: rework Tools menu
ce67ba47a7 httpd: fix get_header_info returning truncated hostnames in certain scenarios
b63d4eaab6 webui: Ignore ASUS remote DoT json database on Multiservice WAN page
513a8a715d Updated documentation
f1f82d8e56 lighttpd: backport fixes from 102_37526
8d7f3bb437 rc: implement DOT blocking for SDN with DNS Director enabled
32df2f61de rc: make Global DNSDirector rule use REDIRECT target instead of DNAT

Wifi 6 additional changes:
Code:
1b846fdb30 webui: Escape single and double quotes in key/SSID on Wireless page and networkmap Wireless frame
1585de5f04 libmnl: fix invalid symlinks for installed library


Update (19-Apr): 3006.102.4 Beta 2 is now available. Changelogs for all three branches:

Wifi 6:
Code:
fe104c9774 (3006.102) webui: updated DNS Director notes
dcef132c02 Update RT-BE96U and GT-BE98_PRO wireless dongle driver to 102_37812 builds
1cc4127a8d miniupnpd: fix building (missing header file)
85c9d353af miniupnpd: update to 2.3.8
198e89a5e8 rc: move service-event-end back within again: loop
170d2e48b5 rc: Have DNS Director "Router" mode use REDIRECT target instead of DNAT to LAN IP in iptables.
8d40fbd7f2 Bumped revision to beta 2
879ad023d4 webui: fix missing button to remove Offline Client List entries
c77742afb1 webui: cleanup sysdep Wireless pages that are no longer existant

Wifi 7:
Code:
fe104c9774 (3006.102) webui: updated DNS Director notes
dcef132c02 Update RT-BE96U and GT-BE98_PRO wireless dongle driver to 102_37812 builds
1cc4127a8d miniupnpd: fix building (missing header file)
85c9d353af miniupnpd: update to 2.3.8
170d2e48b5 rc: Have DNS Director "Router" mode use REDIRECT target instead of DNAT to LAN IP in iptables.
8d40fbd7f2 Bumped revision to beta 2
879ad023d4 webui: fix missing button to remove Offline Client List entries
c77742afb1 webui: cleanup sysdep Wireless pages that are no longer existant


RT-BE92U:
Code:
fe104c9774 (3006.102) webui: updated DNS Director notes
dcef132c02 Update RT-BE96U and GT-BE98_PRO wireless dongle driver to 102_37812 builds
1cc4127a8d miniupnpd: fix building (missing header file)
85c9d353af miniupnpd: update to 2.3.8
170d2e48b5 rc: Have DNS Director "Router" mode use REDIRECT target instead of DNAT to LAN IP in iptables.
8d40fbd7f2 Bumped revision to beta 2
9fe89ff9b6 httpd: fix CPU temperature report on BCM4916
cb50c47eff Merge RT-BE92U binary blobs from 37526
789a111d63 Merge with GPL 102_37526 (RT-BE92U)
879ad023d4 webui: fix missing button to remove Offline Client List entries
c77742afb1 webui: cleanup sysdep Wireless pages that are no longer existant


Changelog:
Code:
3006.102.x (xx-xxx-xxxx)
  - NOTE: If migrating from a 3004 firmware, only the first Guest
          Network will be migrated - any additionnal GN must be
          manually reconfigured.
  - NOTE: If migrating from a 3004 firmware, the Wireless Scheduler
          will need to be manually reconfigured if you were using
          it.
  - NOTE: As a reminder, the ROG variant of the webui is not
          supported in the 3006 firmware series, as maintaining
          two separate interfaces is too much extra work.

  - NEW: Moved RT-AX86U_PRO, RT-AX88U_PRO, ZenWifi Pro XT12,
         GT-AX6000, GT-AXE16000 and GT-AX11000_PRO to the
         3006 firmware series.
  - NEW: Added RT-BE92U support, based on GPL 102_37526.
  - UPDATED: Merged GPL 3006.102_36521 for Wifi 6 models (Wifi 7
             devices other than the RT-BE92U are still on
             102_37346).
  - UPDATED: RT-BE96U and GT-BE98_PRO wifi driver to the build
             from 102_37812.
  - UPDATED: OpenVPN to 2.6.14.
  - UPDATED: miniupnpd to 2.3.8.
  - UPDATED: amtm to 5.2 (decoderman)
  - UPDATED: dnsmasq to 2.91.
  - UPDATED: dropbear to 2025.87.
  - CHANGED: Setting DNS Director to "Router" will now always
             redirect to the router's own IP.  Previously it
             would redirect to the first DNS server configured
             on the DHCP page (which defaults to the router
             itself).
             If you need DNS Director to redirect to an IP
             configured in your DHCP settings, use a Custom DNS
             entry in DNS Director.  This makes it more consistant
             with what the name implies, and was also necessary
             for improved Guest Network support.
  - CHANGED: Added Control-D servers to DNS-over-TLS
             presets (dave14305)
  - CHANGED: Tools category renamed System Info.
  - CHANGED: Tools -> Other Settings were moved to new tabs
             (Administration -> Tweaks, and
             Traffic Analyzer -> Settings).
  - CHANGED: Moved "Redirect to asusrouter.com " to the new
             Tweaks tab, and moved "Enable JFFS Custom Scripts"
             to the Basic Config section on the System page.
  - FIXED: Missing hostname on Wireless Log for MLO-capable Wifi 7
           clients.
  - FIXED: CVE-2024-9143 in OpenSSL (Debian backport by RSDNTWK)
  - FIXED: CVE-2024-13176 in OpenSSL (Ubuntu backport by RSDNTWK)
  - FIXED: Guest Networks on an isolated VLAN with DNS Director set
           to "Router" would fail to do any name resolution (both
           for whole network and for specific clients).
  - FIXED: Wrong tab selected when clicking on "Profile" on the
           VLAN page (dave14305)
  - FIXED: Missing button to remove entries in the Offline Client
           List (dave14305)
  - FIXED: CVE-2025-2492 in AiCloud (backport from upstream)
  - FIXED: DoT access wasn't properly blocked when appropriate
           for Guest Networks.
  - FIXED: DNS-over-TLS presets overwritten by Asus' own (dave14305)
  - FIXED: Networkmap system status frame failing to load when
           accessing the router with some particular hostnames.
  - FIXED: Missing option to disable logging of DHCP/RA queries.

Make sure you do read the changelog, especially if migrating from 3004 to 3006. I documented the known recommendations from Asus' own changelog, but there might be further compatibility issues arising when upgrading from 3004. In particular, I would recommend disconnecting and reconnecting any AiMesh node. Also, double check Wireless settings.

For this beta release I need test feedback for:
  • The models that were migrated from 3004
  • General RT-BE92U performance
  • The Wireless Log page should be more accurate on Wifi 7 devices, the root problem of missing/incorrect hostnames having been resolved

Please keep discussions on this specific beta release.


Downloads are here.
Changelog is here.
 
Last edited:
Known issues:
  • RT-BE92U Networkmap page fails to load in beta 3 (git merge issue. Directly access Advanced_FirmwareUpgrade_Content.asp and upload the version found in the beta3b archive from the download site)
 
Last edited:
Let's GO!

EDIT: Dirty upgrade from the Alpha 2 here on my GT-AX6000 router. No issues to report off the hop. All devices re-connected and happy - Nest HD Cams, IOT Devices, TP-Link devices, IPTV etc... DDNS good, DNS Director good, VPN Director good.

Speed tests pulling expected results.

1744248872975.png


Solid.
 
Last edited:
Greatly appreciated @RMerlin, I'm a happy XT12 owner and really looking forward to testing the 3006 release. The experience with 3004.388-4 was rather complicated with AIMesh (appreciate the AIMesh is non-GPL therefore nothing much you can do), and hopefully the new branch will be rock solid in that regard, as the stock fw. Thanks so much for all your hard work, cheers!
 
Appreciate the release. This is kind of a wishlist but is it at all possible to provide an option for the previous killswitch implementation that was active even if the user manually stopped a client. The old 3006.102.1 release I find the killswitch was perfect for preventing leaks and actually serving the purpose of a killswitch.
 
The CPU issue for the RT-BE92U has been resolved on Asus' side, I'm awaiting for a GPL drop with the fix. No ETA.
 
Appreciate the release. This is kind of a wishlist but is it at all possible to provide an option for the previous killswitch implementation that was active even if the user manually stopped a client. The old 3006.102.1 release I find the killswitch was perfect for preventing leaks and actually serving the purpose of a killswitch.
Having two different behaviours would make the implementation needlessly more complicated, and also be confusing to users. The current implementation is the one that makes the most sense for a majority of users.
 
Having two different behaviours would make the implementation needlessly more complicated, and also be confusing to users. The current implementation is the one that makes the most sense for a majority of users.
I understand I'll try to find a work around, the current implementation with 388/3006 built-in Merlin killswitch only functions when the VPN is enabled, so if you disable the VPN to switch to another VPN the killswitch is not active during that time and you connect directly through the WAN. Also when having connection issues with the VPN upon device scheduled restart, the VPN has disabled itself and therefore disabled the built-in killswitch. I remember reading all the confusion and posts during the initial release when people couldn't seem to understand they had to turn off the killswitch so I understand the necessity to oversimplify it. Appreciate all your work thanks for taking the time to respond.
 
I understand I'll try to find a work around, the current implementation with 388/3006 built-in Merlin killswitch only functions when the VPN is enabled, so if you disable the VPN to switch to another VPN the killswitch is not active during that time and you connect directly through the WAN
VPN rules are applied in a specific order. You can have both VPN clients enabled at the same time, the second VPN will only be reached if the first one is disabled, provided the rules overlap. That way, as long you always have one VPN enabled, your clients will never get exposed.
 
VPN rules are applied in a specific order. You can have both VPN clients enabled at the same time, the second VPN will only be reached if the first one is disabled, provided the rules overlap. That way, as long you always have one VPN enabled, your clients will never get exposed.
So just to clarify your response as I was unaware of this, assuming you have both VPN clients enabled / connected at the same time, with both set to automatic start at boot with overlapping rules.

It will start with OVPN 1 and if it is disabled it will immediately attempt to go to OVPN 2 correct? Does this also occur if the connection fails / disconnects will it attempt to load the next OVPN Client? During the loading of the next OVPN Client I'm assuming the killswitch prevents any leaks during that process? Thanks again this is very insightful!
 
Last edited:
Dirty upgrade from the Alpha 2 on my GT-AX6000 router.
Wireless log does not show any devices connected, though they are.

Edit: Clearing browser cache did the trick, they're back.
 
Last edited:
Regarding guest network: I'm using network #2 at the moment with 3004 because I don't want the guests on a separate subnet (which is the case with guest #1). Is this still the same with 3006, that guest network #1 would use another ip subnet and therefore #2 should be used in my case? Would be nice if someone could tell me before upgrading to 3006. Thank you in advance.
 
Just a curious question:
Unfortunately, the connection quality of the connected clients isn't displayed in -dBm in the web interface, only in the app.

Would it be possible to display this in the web interface as well?
 
Built from source (RT-AX86U_PRO_3006_102.4_beta1) and flashed over stock (3.0.0.6.102_34349), no reset, for RT-AX86U-Pro. Wired and wireless seem ok. Will observe / monitor and report back if any issues. Thx!
 
Regarding guest network: I'm using network #2 at the moment with 3004 because I don't want the guests on a separate subnet (which is the case with guest #1). Is this still the same with 3006, that guest network #1 would use another ip subnet and therefore #2 should be used in my case? Would be nice if someone could tell me before upgrading to 3006. Thank you in advance.
Note the change log in the first post if you are using Guest Network #2 and or #3 since you are possibly migrating from 3004 firmware:
- NOTE: If migrating from a 3004 firmware, only the first Guest
Network will be migrated - any additionnal GN must be
manually reconfigured.
In the 3006's firmware's Guest Network Pro (or Network) presets, if the option Use same subnet as main network is available, you can enable it and the Guest Network Pro clients for that preset will use the same IP subnet as the main LAN/WiFi. Otherwise if Use same subnet as main network is disabled, Asus typically starts the Guest Network Pro's preset IP address range at 192.168.52.1, or 192.168.53.1 and so on for each Guest Network Pro SDN/VLAN. Users should have the ability, when Use same subnet as main network is set to disabled, to change the Guest Network Pro's LAN IP address from the default range the firmware selects to a different IP address subnet.

PS: One word of note when you enable Use same subnet as main network. Enabling that feature may restrict configuring DHCP server, LAN IP, subnet mask, VLAN ID, and DNS server for that Guest Network Pro (or Network) preset. Something to be aware of.
 
Thank you Bennor for your detailed answer! :)
I've read in the opening post that I have to reconfigure them and therefore wondered if I should use the 2nd again, but as it seems I can go with the 1st now.
 
So, I have a RT-AX88U Pro running 3004.388.8_4
And an Aimesh RT-AC86U running 3004.386.14_2

So, If I update the AX88U Pro to 3006, with AiMesh still work?
I don't use any guest networks.
 
Dirty upgrade from the Alpha 2.

I can confirm that now the DNS Director set to "Router" for GN, DNS resolution now works.
But also noticed that in LAN - DHCP Server - Offline Client List, still missing the X for old clients; without running the code from the alpha thread in the Console (F12).
 
Last edited:
Thank you for the new update, always appreciated. Dirty upgrade from Alpha2, seems OK so far, will watch it.

Unfortunately one issue remains from the Alpha, I was hoping the beta would fix my issue (and it might be only me as no one else has reported it, but not sure who tried...) of only accepting 21 of 32 Manual Reservations in my IoT Guest VLAN as documented here, with the trials I carried out.

Device itself is online and working fine, dynamically assigned a DHCP Address in the IoT VLAN, just can't get the manual assignment to stick.

Happy to help troubleshoot if you point me to what you need.
 
So, I have a RT-AX88U Pro running 3004.388.8_4
And an Aimesh RT-AC86U running 3004.386.14_2

So, If I update the AX88U Pro to 3006, with AiMesh still work?
I don't use any guest networks.
I have main RT-BE88U on Merlin 3006.102.3, with RT-AX86U on Merlin 3004.388.8_4 and RT-AC68U on Merlin 3004.386.14_2 as nodes (both cable connected via a switch), aimesh works just fine, including guest network.
 
Status
Not open for further replies.

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