Release Asuswrt-Merlin 3004.388.8_2 is now available

[Kees17760]

Anyone?

Did you use VPN. I had issues with that, couldn't approach router in any way after updating and powercycle. This happened to me twice, but fortunately a WPS reset did the trick for me. Be sure to keep the WPS button pressed (while powering on) for quite some time, at least until the logo flashes white 5 times. Then powercycle again.

I remember seeing some cycling timer in syslog and eventually a time-out trying to bring the VPN connection up. So perhaps waiting and trying helps.

 

[BeachGuy]

Did you use VPN. I had issues with that, couldn't approach router in any way after updating and powercycle. This happened to me twice, but fortunately a WPS reset did the trick for me. Be sure to keep the WPS button pressed (while powering on) for quite some time, at least until the logo flashes white 5 times

I remember seeing some cycling timer in syslog and eventually a time-out trying to bring the VPN connection up. So perhaps waiting and trying helps

Thanks for responding. No VPN.

Good thing I had an RT-AX58U in mesh. Moved that over to main and its running 3004.388.8 just fine (knock on wood!). Almost freaked out though. Was configuring it and lights wouldn't come on on reboot. Thought I bricked that one too but turns out the power strip I had it connected to failed. When it rains it pours.

BTW, is there a limit on flashing firmware? Seems like the GT-AX6000 just gave out. Really surprised as it has a good processor and memory. I am thinking about getting the RT-AX88U PRO to replace it if they reimburse me. Any thoughts on that?

I might just keep the RT-AX58U as only router. It seems to be working fine.

 

[Kees17760]

Thanks for responding. No VPN.

Good thing I had an RT-AX58U in mesh. Moved that over to main and its running 3004.388.8 just fine (knock on wood!). Almost freaked out though. Was configuring it and lights wouldn't come on on reboot. Thought I bricked that one too but turns out the power strip I had it connected to failed. When it rains it pours.

BTW, is there a limit on flashing firmware? Seems like the GT-AX6000 just gave out. Really surprised as it has a good processor and memory. I am thinking about getting the RT-AX88U PRO to replace it if they reimburse me. Any thoughts on that?

No idea, but i wouldn't give up that easy. Perhaps if you leave it powered off for a while including PSU....
But if it's really gone with the dogs, i would favor a RT-AX86U Pro. Had a RT-AX88U before and wasn't happy with it.

Unless you fancy uglyness

 

[BeachGuy]

No idea, but i wouldn't give up that easy. Perhaps if you leave it powered off for a while including PSU....
But if it's really gone with the dogs, i would favor a RT-AX86U Pro. Had an RT-AX88U before and wasn't happy with it.

Unless you fancy uglyness

Ok, that has the same processor and RAM as the 88U. I might just keep the RT-AX58U as only router. It seems to be working fine.

 

[iBest]

I have 2 sites, connected with AX routers both. And with Openvpn.
Site 2 has also some Wireguard server on it.
Site 2 and site 1 are always connected via openvpn and by demand with wireguard from mobile devices. (& to access servers on both sites)
Before the update, wireguard was working inside site 1 to site 2 without any problems
After the update wireguard cant access site 1 it's locked only on where it connects (on site2)

The connection site 1 to site 2 is not using vpn director and it's just injecting lan , without internet redirect.


So read the new changelog and since i don't relay on VPNDirector please advise how to disable the new vpn rules added to this new fw.
Thanks !

PS: Rolling back to 388.7 it just works.

Any idea on this?
Anyone with same "problem" ?

Thank you

 

[RMerlin]

The VPN Director page is one I've never used, so it caught me flat unaware.

The change is actually on the VPN client page itself. The new design which matches what I implemented in 3006 is more straightforward IMHO. Over the years I have encountered a number of users confused by the fact that the Stop/Start toggle was separate from the Start with WAN radio buttons. The new design will also match what is already used for WireGuard.

 

[RMerlin]

What is the appropriate channel for bug reports ? SNB Forum or some dedicate email?

SNBForums. Use this thread if it's specific to the new release, otherwise start a new thread.

Hi! Can you please tell me where exactly you can disable the new kill-switch rule?

Same place as the old one - on the VPN client page itself.

So read the new changelog and since i don't relay on VPNDirector please advise how to disable the new vpn rules added to this new fw.

The killswitch didn't exist before for WireGuard, so it's unrelated to your issue.

Am I correct to say if I enable the killswitch for my Wireguard Client 1 it will only block WAN traffic for subnet 192.168.201.0/24 when booting the router (or when the tunnel goes down)?

Yes.

Note that the WAN rule is unnecessary, since WAN routing is default, and that rule concerns a separate subnet anyway.

 

[RMerlin]

I'm curious if anyone who had issues with TimeMachine is getting better results with this release?

 

[iBest]

SNBForums. Use this thread if it's specific to the new release, otherwise start a new thread.


Same place as the old one - on the VPN client page itself.


The killswitch didn't exist before for WireGuard, so it's unrelated to your issue.



Yes.

Note that the WAN rule is unnecessary, since WAN routing is default, and that rule concerns a separate subnet anyway.

Hi and thanks for your time and ofc for all your work
But ....

here is a v.7 vs v.8 ... i see no switch unfortunately

this is from 7:

and this is from 8:

vpn - client settings

 

[RMerlin]

here is a v.7 vs v.8 ... i see no switch unfortunately

The killswitch option is only available if you enable "Redirect Internet traffic through tunnel" as the setting would make no sense if you don't redirect any Internet traffic through it.

 

[iBest]

The killswitch option is only available if you enable "Redirect Internet traffic through tunnel" as the setting would make no sense if you don't redirect any Internet traffic through it.

But i don't redirect it since i don't want to

Why it blocks my WireGuard from accesing site A?
Since Site A is always connected to site B over an openvpn protocol (clinet-server) & wireguard server is on site B. (for om-demand only).
Both Sites A & B has servers and i need to access without any redirects; that's why the infrastructure done so.

This is exclusively to this latest fw. With version 7 is works like it should (so, i am forced to rollback)

No logs to show this problem...
If you have the time to sort out some workaround or maybe in the next fw i would really appreciate it.

Thanks a lot !

 

[CaptainSTX]

Asuswrt-Merlin 3004.388.8 is now available for supported Wifi 6 models. This release implements a new VPN killswitch method, and fixes a number of issues.

Changes since 3004.388.7:

3004.388.8 (21-July-2024)
  - NOTE: RT-AX56U is exceptionally included in this release.
  - NEW: Rewrote VPN killswitch implementation.  The new method
         uses an always present routing rule to prohibit access to
         the main routing table, so it will be active even if the
         user manually stops a client.  Removing the prohibit rule
         requires disabling the killswitch on the webui.
         The rules are also created before WAN goes up, to reduce
         the risks of leaks between WAN going up and VPN connecting.

         *** Make sure to double check that you don't have any
         unwanted killswitch enabled if you have connectivity issues
         following the upgrade to this firmware.

  - NEW: Added killswitch support for WireGuard clients.
  - NEW: Added mDNS support to the router's local name resolution
         (nss).
  - UPDATED: Chart.js was upgraded from 2.x to 3.9, to share the
             same version used by Asus.  Any third party addon
             that used it will need to upgrade their charts to
             the new version.
  - UPDATED: wget to 1.24.5.
  - CHANGED: Removed stop/start and "Start with WAN" buttons from
             OpenVPN clients.  There is now just a single
             "Enable" option, which will immediately start the
             client when applying changes, and will also start it
             automatically when WAN comes up.  This is to reduce
             confusion, better integrate into SDN, and match how
             WireGuard clients already worked.
  - CHANGED: Allow text selection on the Wireguard Server settings
             page.
  - FIXED: JS error on Wifi 6e/7 models when toggling DDNS.
  - FIXED: Couldn't mount CIFS shares on the router for BCM4912
           devices.
  - FIXED: Wrong band shown when selecting the 5 GHz band on the
           WPS page for the GT-AXE11000.
  - FIXED: WPS page wouldn't properly detect if 6 GHz radio is
           disabled when selecting it for the GT-AXE11000
  - FIXED: Disabling IGDv2/pinhole support wasn't fully disabling
           IPv6 support.
  - FIXED: CVE-2024-3080 issue
  - REMOVED: Wifi Radar was removed (unsupported by Wifi 7 devices,
             and security issues cited by Asus in their own recent
             releases).

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

Downloads are here.
Changelog is here.

As usual no major issues with upgrade on AX86S. I normally unmount the two attached USB drives prior to updating and in the past both drives automatically mount after update completes.

This update the USB drive connected to USB Port 2.0 did not remount, scanning its health from main page didn't resolve, rebooting router didn't force it to mount so I finally had to pull the drive from the router and plug it back in to get the router to see the drive. It is a reasonable quality SanDisk ultra and is only used for my nightly backup using Backupmon.

(Before you someone makes the suggestion to backup to my NAS instead of a USB the NAS is on a different subnet and VLAN than the AX86S.)

 

[jerry6]

Ok, that has the same processor and RAM as the 88U. I might just keep the RT-AX58U as only router. It seems to be working fine.

if the RT-AX58 covers your house and is good for your ISP speeds why not keep it as your router . I'd call Asus and try to get a replacement for the bricked router , always good to have a spare or 2 just in case . Costs nothing to try good luck

 

[jerry6]

"very hard to brick these routers". That's what I thought, but I seem to have found a way to do it. Tried every reset method and no luck. Going to contact ASUS.

there are defects in all brands , it happens . Contact Asus they are good about replacing bricked routers in warranty period . Good luck

 

[BeachGuy]

RMA'd

 

[Kees17760]

RMA'd

Good luck!

 

[Nemesis8]

Known issues:

• No ROG versions of the release (was accidentally left disabled in the build process, should be re-included in the next release)

thanks for your awesome job, but please the next release add rog version i know is only visual but is good for me, thx again master

 

[bennor]

thanks for your awesome job, but please the next release add rog version i know is only visual but is good for me, thx again master

If you haven't seen RMerlin's follow on comment about ROG in post #4 on the first page, here it is. It adds some additional context.

It was accidentally left disabled in my build script when I generated this release, so these images didn't get generated.

I don't really feel like going through the full rebuild + release process just to recreate all release archives with the missing images, so this release won't have ROG versions for the time being. Keep in mind that I initially mentionned that ROG releases were experimental and not fully supported, so they were never guaranteed to be alaways present or fully working. I am in fact dropping their support for the 3006 releases due to the amount of extra work involved in properly maintaining them.

If there is need for a 3004.388.8_2 point release at some point I will re-include them at that time.

 

[leonla]

Bit of a knee jerk post so apologies if covered in the beta thread.
Not sure if this is how it's intended to work but from reading the changelog I'm guessing not.
I have an OpenVPN client setup with killswitch. Post update the killswitch is blocking both LAN and WAN traffic i.e I was unable to access the webui. ping returned host down.
Factory reset and uploaded my config and I could access the webui and everything was fine, allbeit the VPN Director rule list empty, hence being able to access the webui again.
I re-entered the VPN Director rules without the OpenVPN client running and again was unable to access the webui.
Surely the killswitch should only be blocking WAN access if the VPN is down?

Edit - For clarity. Director rules send the (only) machine I have entered in the access restriction list through the VPN

I'm experiencing a similar issue.

I connected to OVPN1 with the kill switch on and encountered no problems until I added 192.168.1.0/24 to the VPN director. This caused me to lose access to the web UI, and I had to reset the router to regain access.

When I set up OVPN1 with the kill switch again and applied the VPN director setting to only 192.168.1.0/24, I lost access to the WebUI once more.

Could you please advise on a solution to fix this VPN director issue? For now, I've reverted back to the older version.

 

[fka]

Dirty update. Everything seemed to work fine, until reboot. After that router was unreachable (both HTTP and SCP).
Found out VPN configuration was the culprit. Had to setup VPN from scratch. Working fine now.

Least it's not only me.
Although I understand killswitch affects all routing tables but I don't understand why it needs to block local traffic. Seems unnecessary?
Is it just the case it blocks all traffic to/from any client routed through the tunnel because it's the safest option. Or because it's the only option?