Release Asuswrt-Merlin 3004.388.9 is now available

[Igor]

Igor, I just successfully tested a hack/workaround to the Home Assistant SSH issue with Dropbear 2025.87
. See https://github.com/home-assistant/core/issues/142830#issuecomment-2827806351

Thank you! I've already checked it, everything works correctly.

 

[amplatfus]

Hi,
I had a issue after update today from RT-AX88U_3004_388.8_4 to this 388.9.
I have from years ago a custom /jffs/configs/dnsmasq.conf.add looking like this:

...
(1) interface=br0,br1
(2) dhcp-host=br0,5c:c3:cc:39:aa:cc,ignore ##_#_xyz1 Wifi #
(3) dhcp-host=br1,5c:c3:cc:39:aa:cc,xyz1,10.10.10.203,604800 ##_#_xyz1 Wifi #
...

After update, dnsmasq have this error:
Apr 27 01:29:19 A88X dnsmasq[13461]: DHCP host has multiple names at line 3 of /etc/dnsmasq.conf

At line (3) I have: "(3) dhcp-host=br1,5c:c3:cc:39:aa:cc,xyz1,10.10.10.203,604800 ##_#_xyz1 Wifi #"
I have br0 and br1 and I want to have xyz1 to be ignored on br0. It used to work until 388.9 with dnsmasq to 2.91.
If you have any suggestion, please share.
Thank you very much!

Later edit: after rollback to 388.8_4 the error disappeared without any other changes.

 

[yxo-6o6uka]

Check the system log. Dropbear was upgraded, it`s possible that you key is too weak and gets rejected by the updated Dropbear.

A slightly delayed thank you note for the tip. Generating a new sha256 key pair in leu of the 12yo weak pair (which served well til now) resolved the issue with ssh login.

 

[RMerlin]

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)

 

[rung]

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

Do you know if there is a pending update for this issue on 3006 or are the only issues with 3004? I can't tell with my setup since I have both on my network.

 

[aex.perez]

Applied to Router and Nodes. After settling down and everything got reconnected, switched back to WPA2/WPA3-Personal on the Main and two Guest SSID's - Everything connected back up cleanly and maintained AiMesh, binding clients to specific devices working as well. Networkmap looks great, though I had already shortend/abbreviated some of the names (long overdue i.e. KBR instead of "Kids BedRoom or "Kids Room"), very readable.

 

[visortgw]

Do you know if there is a pending update for this issue on 3006 or are the only issues with 3004? I can't tell with my setup since I have both on my network.

It should be in the next 3006 iteration released by @RMerlin for WiFi 6 devices:

Probably my last post

This will probably be my last post, because I no longer have an ASUS router. I’ve sent my RT-AX86U Pro back, as I was having problems with the Wi-Fi, some of which I also had with the RT-AX88U Pro I had before, namely: My Canon TS 8350a printer going offline nearly every day and sometimes more...

www.snbforums.com

 

[ExtremeFiretop]

Applied to Router and Nodes. After settling down and everything got reconnected, switched back to WPA2/WPA3-Personal on the Main and two Guest SSID's - Everything connected back up cleanly and maintained AiMesh, binding clients to specific devices working as well. Networkmap looks great, though I had already shortend/abbreviated some of the names (long overdue i.e. KBR instead of "Kids BedRoom or "Kids Room"), very readable.



View attachment 65326View attachment 65325

Can confirm this firmware release resolved my original report for WPA2/WPA3 issues for my node. All devices also connected cleanly.
Just wanted to pass my thanks to @RMerlin and the ASUS engineering team for looking into this one. Was going to drive me nuts until we found the workaround.

Not sure if @RMerlin you poked someone on their team, or if they are just monitoring the forums, but the fact the report got somewhere and was fixed quickly is a true testament of how great this community and forums are.

 

[RMerlin]

Do you know if there is a pending update for this issue on 3006 or are the only issues with 3004? I can't tell with my setup since I have both on my network.

That specific issue only exists in 3004.

 

[Unetwork]

Thank you for the new update 3004.388.9_2 and for taking into account the reported problems.
It works perfectly now (AX88U, hard reset + manual reconfiguration).

However, I have a new entry in the routing table with a destination IP : 239.0.0.0.
What is it ?

I didn't have this in previous versions.

 

[ExtremeFiretop]

Thanks for the new update 3004.388.9_2, it works perfectly (AX88U, hard reset + manual reconfiguration)

However, I have a new entry in the routing table with a destination IP : 239.0.0.0.
What is it ?

View attachment 65337

I didn't have this in previous versions.

388.9_alpha1 Firmware for RT-AX58U, GT-AX11000, and GT-AXE11000

Yes you're right, the formatting is terrible to work with from devtools .. Javascripts are minified during firmware build, for space reasons. The original code is properly formatted.

www.snbforums.com

Unfortunately the only difference I've found so far in 388.9 is for that extra multicast route (covering 239.x.x.x) "239.0.0.0/8 dev br0 scope link "

I believe it to be a new multicast route (covering 239.x.x.x)

 

[Unetwork]

388.9_alpha1 Firmware for RT-AX58U, GT-AX11000, and GT-AXE11000

Yes you're right, the formatting is terrible to work with from devtools .. Javascripts are minified during firmware build, for space reasons. The original code is properly formatted.

www.snbforums.com

I believe it to be a new multicast route (covering 239.x.x.x)

Thank you for your prompt reply.

Is this new multicast route normal ? I can't figure out exactly what it's for.
Can it be left in place ? Is there a way to disable it as before, or can it be forgotten ?

 

[ExtremeFiretop]

Thank you for your prompt reply.

Is this new multicast route normal ? I can't figure out exactly what it's for.
Can it be left in place ? Is there a way to disable it as before, or can it be forgotten ?

If your network is working fine and you're not seeing strange issues (like huge traffic spikes or CPU usage), yes, it can be left in place.
Multicast routing entries don't consume a lot of resources unless the traffic volume is very high.

If no programs are using it, it will just sit idle since multicast groups are only active when subscribed members exist.
However that being said; you can disable multicast routing if you truly don't want it enabled.

On the router, you might want to double check these settings: Turn off IGMP Proxying/Multicast Routing in LAN settings.

 

[Unetwork]

If your network is working fine and you're not seeing strange issues (like huge traffic spikes or CPU usage), yes, it can be left in place.
Multicast routing entries don't consume a lot of resources unless the traffic volume is very high.

If no programs are using it, it will just sit idle since multicast groups are only active when subscribed members exist.
However that being said; you can disable multicast routing if you truly don't want it enabled.

On the router, you might want to double check these settings: Turn off IGMP Proxying/Multicast Routing in LAN settings.

View attachment 65338

thank you for your help and all these explanations.

I just looked and this parameter is already deactivated. I don't understand why route 239.x.x keeps appearing in the routing table...

(for your information, the router has already been reset, manually reconfigured and rebooted)

 

[ExtremeFiretop]

thank you for your help and all these explanations.

I just looked and this parameter is already deactivated. I don't understand why route 239.x.x keeps appearing in the routing table...

View attachment 65339

Maybe check under the Pro Wireless settings? I've always had it enabled in these locations so when it appeared on my setup I figured that was a good thing, and not a bad thing.

 

[Unetwork]

Maybe check under the Pro Wireless settings? I've always had it enabled in these locations so when it appeared on my setup I figured that was a good thing, and not a bad thing.

You're right, it's enabled in Pro Wireless settings (2.4 Ghz and 5 Ghz)

This parameter "IGMP Snooping" has always been enabled by default in previous versions of Merlin.
Do I have to deactivate it to no longer have the line in the routing table or has there been a change and now the line in the routing table is linked to this parameter ?

 

[ExtremeFiretop]

You're right, it's enabled in Pro Wireless settings (2.4 Ghz and 5 Ghz)

This parameter "IGMP Snooping" has always been enabled by default in previous versions of Merlin.
Do I have to deactivate it to no longer have the line in the routing table or has there been a change and now the line in the routing table is linked to this parameter ?

View attachment 65341

Your tests would know better than my assumptions let us know what you find. I'm currently working from the office today so that's really as much guidance as I can provide. As I mentioned I always had these settings enabled so it looked like a "fix" to me when I noticed it appear on my node in Alpha. I didn't try to disable anything due to this.

 

[Unetwork]

Your tests would know better than my assumptions let us know what you find. I'm currently working from the office today so that's really as much guidance as I can provide. As I mentioned I always had these settings enabled so it looked like a "fix" to me when I noticed it appear on my node in Alpha. I didn't try to disable anything due to this.

So you think that the multicast route 239.x.x that now appears in the routing table is an enhancement patch and corresponds to the IGPM active in wireless networks ?

I will consider that this new route is linked to the IGMP and that this is normal. If others agree, I remain available to read you.

 

[MDM]

So you think that the multicast route 239.x.x that now appears in the routing table is an enhancement patch and corresponds to the IGPM active in wireless networks ?

I will consider that this new route is linked to the IGMP and that this is normal. If others agree, I remain available to read you.

You are chasing nonexistent ghosts...

 

[Unetwork]

You are chasing nonexistent ghosts...

Very well, if this new route is normal, I'll leave it as it is.
I'd rather ask the question here, because you never know if it could be a bug or something.