Beta Asuswrt-Merlin 3006.102.5 Beta is now available

[glenw]

I upgraded RT-BE92U from Beta1 to Beta 2. This has fixed the issue I had with DNS Director. Previously with DNS Director active it broke DNS over TLS. Now they are coexisting happily. Global Redirection set to Router.

 

[HorseCalledHorse]

If you use a switch, then following a retour reboot the client list will not be able to properly report if something is on DHCP until that client actually does a DHCP lease request. Until they do, they are considered as static from the router's point of view (i.e. they are communicating using an IP address but have yet to request a DHCP lease).

This is expected, as the router has no way of knowing if that client was running on a previously obtained lease or on a static IP.

I do use a switch. This morning all of my clients - wired and wireless - are reporting as DHCP, including all of the clients with static IPs. Is that expected behaviour, or because of the AiMesh node?

 

[CaptainSTX]

3006.102.5 Beta 1 is now available for all supported models. The focus of this release is the merge of updated GPLs, and the implementation of a new System Log -> Connection interface. Asus also migrated the RT-BE92U to the same codebranch as other Wifi 7 models.

July 20th: Beta 2 is now available. Changes since beta 1:

d8fdc1840d Updated documentation
a037fbdfab webui: removed unused Email code from OVPN server page; minor cleanups
696eb4b955 webui: fix duplicate label value on OVPN server page
8e55cf4acd webui: Rework the QIS Wizard page shown if a new firmware is available
79e7d0ef48 httpd: check that we have a potential IP before calling ParseIPv4OrIPv6()
1df7906db3 Harmonize target profiles with Asus
d17547441d webui: don't link to the whole networkMap.css on Sysinfo, just include the classes we need
155ad587bf webui: workaround for Wireless settings page not scrolling to the top when applying
c45f6e8d0a webui: fix invalid dwb_mode on some models (patch from Asus)
fec8643b8c Updated documentation
94497b5595 webui: Do not enumerate SDNs that use the default LAN for DNSDirector; table layout fix
bb0b9e6867 rc: filter out any SDN that uses network 0 (LAN) instead of just back/fronthaul networks when setting up DNSDirector iptables
292ecacadc webui: properly fix Makefile recipes; remove unused dns_db.json
22b2406ba4 rc: skip fronthaul/backhaul SDNs when creating DNSDirector iptables rules
0b8cbcc23c rom: update CA bundle
aab06d3dd2 rom: update mk-ca-bundle script from Curl
b1da4aec20 networkmap: webui: update databases
709b5a783e webui: fix install recipe following last GPL merge
bcc40abf75 httpd: optimize performance for conn.active sysinfo queries
a971907427 Bump to beta 2

Changelog:

3006.102.5 (xx-xxx-2025)
  - NOTE: For developers, please note that the new default branch
          is now called "main" - it's what was previously the
          3006.102 branch.
          The "master" branch has been renamed "master-old", and
          is no longer actively used.  Due to how the 3006.102
          branch diverged, it was easier to do it this way than
          to fold back 3006.102 on top of master.

  - UPDATED: Merged GPL 3006.102_37957 for Wifi 6 devices.
  - UPDATED: Merged GPL 3006.102_38757 for WIfi 7 devices.
  - UPDATED: dropbear to 2025.88.
  - CHANGED: Reworked System Log -> Connections page.  You can
             now filter the list, local hostnames are resolved,
             automatically refresh the page, and IPv6 is supported.
  - CHANGED: Replaced netstat-nat by a fork called netstat-nat-ng.
             This fork fixes a number of issues with IPv6 and
             field size.
  - CHANGED: Updated Control-D DoT server entries (dave14305).
  - FIXED: OpenVPN server set to "Internet only" would fail to
           block LAN access (invalid firewall rule from SDN was
           bypassing it).
  - FIXED: DNSDirector "Router" mode would not always work properly
           with IPv6 (now uses REDIRECT instead of DNAT, which was
           backported from iptables 1.4.19).

Please keep discussions on this specific release. Off-topic posts will be either ignored or deleted, depending on my mood at the time.


Downloads are here.
Changelog is here.

While the pull down under WiFi encryption lets you select AES-TKIP when you have selected WPA/WPA2 Personnel it doesn't seem to do anything. When I look at the SSIDs using a WiFi analyzer before and then after selecting and enabling AES-TKIP nothing changes and my Honeywell thermostat refused to connect. The analyzer can see the SSIDs in the neighborhood that have AES-TKIP so it can detect this type of encryption. Realize this is probably an ASUS issue as they control the WiFi blob.

 

[Blkpanthr]

Something going on with the wireless connections on beta2. none of my devices can find the internet evenn though they are fully connected to the network with DCHP asigned ips.

My phone and tablet i can fiddle with and get the internet, but my other devices dont have web interfaces to mess with so they wont connect with their apps.

Rolled back to beta1 and everything is working properly again.

It seems as though something is filtering/blocking access to the wan on wifi. i dont see any settings anywhere that would control that.

no issues with wired connections.

When my phone first connects, it says connected without internet. if i open a chrome page it will force it to detect internet and the 'not connected' goes away.

 

[RMerlin]

I do use a switch. This morning all of my clients - wired and wireless - are reporting as DHCP, including all of the clients with static IPs. Is that expected behaviour, or because of the AiMesh node?

Are they real static IPs, or just reservations? Static means the IP is manually configured on the client, while a reservation is still DHCP, just that you are telling the DHCP server what IP to assign.

 

[RMerlin]

Something going on with the wireless connections on beta2. none of my devices can find the internet evenn though they are fully connected to the network with DCHP asigned ips.

My phone and tablet i can fiddle with and get the internet, but my other devices dont have web interfaces to mess with so they wont connect with their apps.

Rolled back to beta1 and everything is working properly again.

Zero change to wireless in Beta 2, you can see the actual complete list of changes in the first post. It's almost entirely webui-related.

 

[Blkpanthr]

probably less about wireless and more about something in the WAN settings.

Wireless itself in fine, everything connects and i can see the throughput.

the clients wont connect to the wan however.

 

[Blkpanthr]

Behavior fully repeatable.

Moving to beta2 again exibits same behavior with wireless clients not seeing the internet unless forced.

flashing back to beta1 fixes it.

 

[dave14305]

Behavior fully repeatable.

Moving to beta2 again exibits same behavior with wireless clients not seeing the internet unless forced.

flashing back to beta1 fixes it.

Do you have DNS Director setup? It’s the only thing between beta1 and beta2 that could really affect clients connecting.

 

[Blkpanthr]

i will disable it and flash beta2 and see if it fixes it.

 

[5stringdeath]

View attachment 66859

i will disable it and flash beta2 and see if it fixes it.

Are you using those User Defined DNS settings? If not you don't need anything set there, those are not the routers WAN DNS entries

 

[Blkpanthr]

They are more of a reminder to me what im using. I am aware they have no function when using the router settings in the director.

Well, gold star for Dave. It was indeed the director. Disabling it and relying on DNS in the DCHP settings fixed it.

Where is the director getting the router DNS settings from?

 

[HorseCalledHorse]

Are they real static IPs, or just reservations? Static means the IP is manually configured on the client, while a reservation is still DHCP, just that you are telling the DHCP server what IP to assign.

Lightbulb moment for me, Merlin! They are reservations, set on the router, not the client. Thank you.

 

[casao94]

Upgraded to beta2 on RT-BE96U. Rebooted and everything is working fine so far at this time.

 

[MDM]

Lightbulb moment for me, Merlin! They are reservations, set on the router, not the client. Thank you.

So you didn't understand what I wrote first to you, but did RMerlin with the same explanation...
Seems I must be clearer in my writings in the future.

 

[elorimer]

Behavior fully repeatable.

Moving to beta2 again exibits same behavior with wireless clients not seeing the internet unless forced.

flashing back to beta1 fixes it.

I saw something similar with a Chromebook and an Android TV after moving to beta2. Going back to beta1 didn't fix it for me. Rebooting the Chromebook fixed it, and deleting and re-adding apps fixed it on the Android TV. I don't think this is a beta issue but something about renewing the connection.

 

[dave14305]

I disabled “Scheduled check for new firmware availability” a few days ago (or maybe yesterday, can’t be sure), and noticed that the router still checked for an update at 5:29 am this morning.

# nvram get firmware_check_enable
0
# ls -l /tmp/webs_upgrade.log
-rw-rw-rw-    1 rtradmin root            96 Jul 22 05:29 /tmp/webs_upgrade.log
# cat /tmp/webs_upgrade.log
---- update real normal----
---- Have 3006.102.5_-12----
---- Stable available 3006.102.4_0----

Saw that there had been a change to the code this release cycle. I restarted watchdog manually just to see if it helps tomorrow.

rc: update firmware check code with some upstream changes; remove som… · RMerl/asuswrt-merlin.ng@f64916a

…e duplicate code

github.com

It looks like the nvram check is now only run during the bootup_check condition.

 

[MarkusI]

You need to query the verbose output. That output is missing all the interface information.

Sure:

Directly after a fresh boot:

Chain OVPNSF (1 references)
 pkts bytes target     prot opt in     out     source               destination      
    0     0 ACCEPT     all  --  any    tun21  !192.168.1.0/24       anywhere        
    0     0 ACCEPT     all  --  tun21  any     anywhere            !192.168.1.0/24  
    0     0 ACCEPT     all  --  any    tun21   anywhere             anywhere        
    0     0 ACCEPT     all  --  tun21  any     anywhere             anywhere

After

service stop_vpnserver1
iptables -F OVPNSF
service start_vpnserver1

The first two lines remain.

 

[HorseCalledHorse]

So you didn't understand what I wrote first to you, but did RMerlin with the same explanation...
Seems I must be clearer in my writings in the future.

No, sorry! I focussed on the first part of your sentence and didn't quite get the distinction between manual and static, but it's all clear now

 

[kuchkovsky]

Upgraded from 3006.102.4 to beta 2 to test the updated System Info page - it's now much more responsive with over 10k connections. I've been running this beta since Sunday and haven't encountered any issues. Thanks, Merlin!