Beta Asuswrt-Merlin 3006.102.4 Beta is now available

[RMerlin]

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 (19-Apr): 3006.102.4 Beta 2 is now available. Changelogs for all three branches:

Wifi 6:

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:

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:

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:

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_37435.  This GPL
         seems to have some stability issues, so consider support
         for this model to remain Beta, until a fix is provided
         for it.

  - UPDATED: Merged GPL 3006.102_36521 for Wifi 6 models (Wifi 7
             GPL codebase is unchanged from 3006.102.3).
  - UPDATED: OpenVPN to 2.6.14.
  - UPDATED: miniupnpd to 2.3.7 (20250207 snapshot)
  - UPDATED: amtm to 5.2 (decoderman)
  - UPDATED: dnsmasq to 2.91.
  - UPDATED: dropbear to 2025.87.
  - 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 DNSDirector set
           to "Router" would fail to do any name resolution.
  - FIXED: Wrong tab selected when clicking on "Profile" on the VLAN
           page (dave14305)

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.

 

[RMerlin]

Known issues:

• RT-BE92U becomes unresponsive/one CPU core gets stuck at 100% (Fixed in beta 2 with a new GPL)

 

[shabbs]

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.

Solid.

 

[Tulio Lazarini]

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!

 

[bassoonsun]

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.

 

[RMerlin]

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.

 

[RMerlin]

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.

 

[bassoonsun]

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.

 

[RMerlin]

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.

 

[bassoonsun]

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!

 

[Kees17760]

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.

 

[chris.at]

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.

 

[Heino]

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?

 

[pershoot]

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!

 

[bennor]

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.

 

[chris.at]

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.

 

[alan6854321]

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.

 

[MDM]

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).

 

[jksmurf]

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.

 

[Strud]

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.