Release Asuswrt-Merlin 3004.388.9 is now available

[Mutzli]

Same result here.
To summarize version 388.9_2, I noticed three things :

Otherwise, everything else works perfectly, the version has been stable for a week, and there's nothing unusual in the logs.

IP address not centered: do you have IPv6 enabled? If so, the additional IPv6 addresses may fill the empty space.

 

[ColinTaylor]

Secondly, when you display the list of clients on the home page, the IP addresses are not centered in the case, they're on the left, there's a big space.

This is not a bug, it's intentional. They have never been centered, they've always been left justified. The only difference, as others have said is that the width has increased to accommodate IPv6 addresses.

Revert "webui: allow more space for client name on the table clientlist" · RMerl/asuswrt-merlin.ng@60ba868

Asus had resized these fields because the IP field can now display IPv6 addressess, which require more space. Revert to the field width that they had used to handle those longer addresses, a diffe...

github.com

 

[anotherone]

I've been having connection issues with security cams where they randomly become unconnectable, while everything else on the network works fine. The issue is only fixed by rebooting the router. Started with a couple firmware versions back, before that never had this problem.

- FIXED: Compatibility issues with IoT devices and WPA2/WPA3 networks (Asus)

Hope this fixes my issue for good so I don't have to reboot router so often.

 

[visortgw]

I've been having connection issues with security cams where they randomly become unconnectable, while everything else on the network works fine. The issue is only fixed by rebooting the router. Started with a couple firmware versions back, before that never had this problem.


Hope this fixes my issue for good so I don't have to reboot router so often.

One rather quick way to test prior to updating (if you haven't already) is to change wifi security from WPA2/WPA3 to WPA2 only. If your issues go away, the update will most likely will allow you to revert to WPA2/WPA3.

 

[oldgringo]

The "mysterious route 239.0.0.0" is a common subset for private multicast (similar to 192.168.0.0/16, 172.16.0.0/12 or 10.0.0.0/8 for IPv4 space). I don't see any reason to stay on the stock firmware if Merlin is available. If you're having any issues with Merlin, you probably haven't read all the release notes for previous releases. After changing the firmware (not an update), it is mandatory to reset the router to clear the nvram space, and then set up the router from scratch (do not load a backup, as this will bring all the junk back). That's the cost of changing the firmware. I have two identical devices, one with Merlin and one with the stock Asus firmware (just for comparison), and I see issues with Merlin on the stock device as well. Plus, Merlin often implements functionality from top routers into lower versions (if that makes sense). There is an occasional bug in Merlin, but it is usually reported immediately and fixed in one of the next releases, but that's just life with development. It's still much better than no support. I currently run 10 different Asus WiFi 6/7 routers across my household (and most of them are on Merlin), so I can generalize a bit.

 

[The PyroPath]

Having a very weird issue, where if I bind any device to the main router (AX88U) running Merlin, ALL devices are being bound to the main router. Don't know if it started with 90 or 92,as I don't think I changed any bindings the last months, but now I'm not able to...

 

[aex.perez]

Having a very weird issue, where if I bind any device to the main router (AX88U) running Merlin, ALL devices are being bound to the main router. Don't know if it started with 90 or 92,as I don't think I changed any bindings the last months, but now I'm not able to...

With 388.9 it started and fixed with 388.9_2. Try setting WiFi security to WPA2-Personal then apply 388.9-2 and set back to WPA3/WPA2-Personal

Go back a few posts and you’ll find the havoc that caused and work around…

 

[The PyroPath]

With 388.9 it started and fixed with 388.9_2. Try setting WiFi security to WPA2-Personal then apply 388.9-2 and set back to WPA3/WPA2-Personal

Go back a few posts and you’ll find the havoc that caused and work around…

Do I need to set it to WPA2-personal on 388.7 or should this also work for 388.9? Because it has always been set to WPA2-personal for me. Updated from 9 to 9_2 and set to WPA2/WPA3-personal and this didn't fix the issue.

 

[aex.perez]

Do I need to set it to WPA2-personal on 388.7 or should this also work for 388.9? Because it has always been set to WPA2-personal for me. Updated from 9 to 9_2 and set to WPA2/WPA3-personal and this didn't fix the issue.

No, the issue with WPA2/WPA3-Personal NOT working, necessitating the use of WPA2-Personal was introduced in 388.9 EXCLUSIVELY, with 388.9_2 WPA2/WPA3-Personal was fixed and one could use it again. Doesn't sound like that's the your issue, though your post seems to indicate it was exactly that. You might want to be a bit more verbose, and post some logs if you have them, at worst case share a little bit about your setup.

 

[The PyroPath]

No, the issue with WPA2/WPA3-Personal NOT working, necessitating the use of WPA2-Personal was introduced in 388.9 EXCLUSIVELY, with 388.9_2 WPA2/WPA3-Personal was fixed and one could use it again. Doesn't sound like that's the your issue, though your post seems to indicate it was exactly that. You might want to be a bit more verbose, and post some logs if you have them, at worst case share a little bit about your setup.

No, the issue I'm having is that neither the app or the webpage appear to reflect the binding status correctly. So, I have some devices set up to connect to the main router (AX88U) , as that one is up 24/7. Others might be turned off (4*XT8). I have 1 device that I have to shuffle around every once in a while to keep it connected to or reconnect it to the Home Assistant instance. So I would remove the binding with the AX88U, bind it to a XT8, unbind from Xt8, rebind with AX88U. Don't ask me why, but it worked fine, especially, since the problem would occur every once a blue moon. This time around though, I unbound from the AX88U, bound to XT8, unbound from XT8 and when rebounding to the AX88U, all my devices, online and offline are bound to the AX88U. I can't unbind any device, but have to unbind the specific device I just bound to the AX88U. Then the status of the other devices will be back to normal.

 

[visortgw]

Have you looked at value of sta_binding_list in nvram (nvram show | grep bind)? Possibly this needs to be cleared so that you can reestablish your bindings?

 

[aex.perez]

Have you looked at value of sta_binding_list in nvram (nvram show | grep bind)? Possibly this needs to be cleared so that you can reestablish your bindings?

Let me add that I had to remove and then re-add/re-establish the mesh nodes going from 388.9 to 388.9_2, worst case you may have to do that, but in my case both the Router and nodes were on 388.9. Your XT8's would be on stock firmware. so that may not apply to you. Keep that as a possibility, shouldn't be too bad with the XT8's on ASUSWRT. Didn't ask if wired or wireless backhaul, that would be problematic if you weren't already using WPA2-Personal

 

[The PyroPath]

Have you looked at value of sta_binding_list in nvram (nvram show | grep bind)? Possibly this needs to be cleared so that you can reestablish your bindings?

This is what I get:

nvram show | grep sta_bind
sta_binding_list=
size: 91427 bytes (39645 left)
sta_binding_list=<24:4B:FE:F5:2B:60>1>24:EC:99:0E:75:2F,7|CC:8C:BF:B5:24:43,1|CC:8C:BF:B5:24:D2,7<C8:7F:54:B4:DC:10>1>AC:CF:23:12:13:95,7<3C:7C:3F:53:82:C0>1>A0:B7:65:63:D1:64,15|A0:B7:65:6B:0A:30,3|48:55:19:67:B2:5F,3<24:4B:FE:F4:EE:90>1>40:F8:DF:2F:1D:3C,7|24:62:AB:43:F3:C4,7|48:E1:E9:D5:87:89,15

Anything that stands out to you as being weird or incorrect and how would I go about clearing it?

 

[visortgw]

This is what I get:

nvram show | grep sta_bind
sta_binding_list=
size: 91427 bytes (39645 left)
sta_binding_list=<24:4B:FE:F5:2B:60>1>24:EC:99:0E:75:2F,7|CC:8C:BF:B5:24:43,1|CC:8C:BF:B5:24:D2,7<C8:7F:54:B4:DC:10>1>AC:CF:23:12:13:95,7<3C:7C:3F:53:82:C0>1>A0:B7:65:63:D1:64,15|A0:B7:65:6B:0A:30,3|48:55:19:67:B2:5F,3<24:4B:FE:F4:EE:90>1>40:F8:DF:2F:1D:3C,7|24:62:AB:43:F3:C4,7|48:E1:E9:D5:87:89,15

Anything that stands out to you as being weird or incorrect and how would I go about clearing it?

I would try setting it to "" to remove all entries and start from scratch (nvram set sta_binding_list="").

 

[The PyroPath]

OK, cleared all the bindings, removed all nodes and added them again. Tried adding the bindings back, and seems all OK, no errors and seems fine. But as I'm adding bindings it's suddenly back again. Might have been there for a long time, but it's the first time I've noticed it. Might be some kind of memory bug. Although it doesn't report as full in the binding list or memory, the kernel appears to be throwing messages left and right when it happens. Messages I don't understand, but usually when that has happened in the past it was something memory related.

 

[aex.perez]

OK, cleared all the bindings, removed all nodes and added them again. Tried adding the bindings back, and seems all OK, no errors and seems fine. But as I'm adding bindings it's suddenly back again. Might have been there for a long time, but it's the first time I've noticed it. Might be some kind of memory bug. Although it doesn't report as full in the binding list or memory, the kernel appears to be throwing messages left and right when it happens. Messages I don't understand, but usually when that has happened in the past it was something memory related.

Any Log entries you can share? Also FW version on the Router and on the XT8's. I should know but we talked about a few of them and I've lost track

Did a quick lookup on the XT8 and FW 3.0.0.4.388_24709 (two separate versions HW Ver 1.0 and 2.0)
Release Notes:
1. Fixed the UI issue in Chrome.
2. Fixed client binding issues in Mesh scenarios. (This one may be relevant in your case)
3. Enhanced input parameter handling techniques to improve data processing stability and system security.
4. Enhance system access control mechanisms.

Product Support For ASUS ZenWiFi AX (XT8)

But you might consider a jump to the current 3.0.0.4.388_24710 as it contains another relevant fix (Note: two separate versions HW Ver 1.0 and 2.0)
Release Notes:
Improved compatibility with certain IoT devices.

 

[jfgarciamex]

3004.388.9_2 is now available, fixing a couple of issues:

  - UPDATED: miniupnpd to 2.3.8.
  - FIXED: CVE-2025-2492 in AiCloud (backport from upstream)
  - FIXED: Networkmap system status frame failing to load when
           accessing the router with some particular hostnames.
  - FIXED: Networkmap client list wordwrapping long hostnames.
  - FIXED: webui issue when DDNS set to Custom.
  - FIXED: Compatibility issues with IoT devices and WPA2/WPA3
           networks (Asus)

A few days ago, I reported an issue with a reverse proxy and the "System Status" frame being blank. After updating to 388.9_2 I still see the same issue. This is my original post:

Hi, I have a AX86U and just installed 3004.388.9, and I'm using a reverse proxy locally. The reverse proxy I'm using is based on nginx. I have a rule setup as follow:

• if I type https://router.mydomain it is being redirected to http://router.asus.com:80.

I has been working fine since I set up this configuration, but with this version I noted the System Status panel is blank (If I log in using port 80, everything is fine). I'm including a screen shot of what I see when using my reverse proxy:
View attachment 65268
I updated my reverse proxy to the latest version, but I have the same issue. Any recommendations on how to fix this? Could be something introduced int this version? Thanks!

After digging in the inspect section in edge, I noticed the following error:

Hope this helps to pin-point the issue. Thanks!

 

[Unetwork]

@Mutzli & @ColinTaylor Thanks for your comments.
OK, if the space is normal and is intended to accommodate IPV6 addresses.

What remains to be seen is the AiProtection graphics bug and the mysterious route that didn't appear in previous versions 388.8.
If this route was absent in previous versions (bug), it would be nice to have confirmation that the display now is normal.

 

[RMerlin]

If this route was absent in previous versions (bug),

What makes you think it's a bug? What specific issue are you experiencing related to it?

As others noted, this is a perfectly normal route related to multicast, and it's bound to your LAN so it has zero security impact.

 

[Unetwork]

What makes you think it's a bug? What specific issue are you experiencing related to it?

As others noted, this is a perfectly normal route related to multicast, and it's bound to your LAN so it has zero security impact.

Noted.

I have no problems with version 388.9_2 except for the AiProtect graphics bug.
It's reassuring if route 239.0.0 is normal in this latest version. I was surprised because it didn't exist before, but if it corresponds to the local network and has no impact on security, it's perfect.

Thanks again for your work, your versions are all rock solid.