Release Asuswrt-Merlin 3004.388.9 is now available

[The PyroPath]

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.

Sorry, was a bit busy. Because the issue popped up so suddenly I of course checked the firmware on the XT8's and it's the 24710 on all of them. (stock) I updated the AX88U to the latest Merlin, which is 9_2.

The last time I tried to bind devices, I think it worked longer (was able to bind more devices before it crapped out). Don't think I've any logs, because I thought it might be memory related and cleared the logs. I basically gave up and tried a different approach. Now I've set the devices up to not roam between acces points, and that appears to have the same effect. of the 4 XT8's, 3 are powered down for the night and/or when no one is home. So although the AP XT8 might be closer, I set them up to stay connected to the AX88U because if the device is bounced around it tends to screw with Home Assistant and the connection fails. For now at least, the not roaming approach seems to be effective and I haven't tried againt with binding.

 

[gattaca]

Solved by separating br like this:

(1) interface=br0
(2) dhcp-host=5c:c3:cc:39:aa:cc,ignore ##_#_xyz1 Wifi #

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

Hi, I also had a similar issue with a small typo in the dnsmasq.conf.add file. It had gotten past all prior versions (3004.388.8_2) but with the upgrade (dirty) to 3004.388.9_2 the line was flagged and stopped DNS from starting. Tracked down through the logs. It appears this version is checking more syntax in the dnsmasq.conf.add file. Tighter syntax was also reported in another post a page or two back. Be aware of this nuance! THANKS!

 

[FTC]

Hi, I saw in the logs of my RT-AX88 running Merlin 388.9_2 this morning a 'trap' from yesterday that seemed related to httpd :

May 14 18:36:11 kernel: CPU: 0 PID: 1198 Comm: httpd Tainted: P O 4.1.51 #2
May 14 18:36:11 kernel: Hardware name: Broadcom-v8A (DT)
May 14 18:36:11 kernel: task: ffffffc02ff46080 ti: ffffffc02e144000 task.ti: ffffffc02e144000
May 14 18:36:11 kernel: PC is at 0x51d0c
May 14 18:36:11 kernel: LR is at 0x51cc4
May 14 18:36:11 kernel: pc : [<0000000000051d0c>] lr : [<0000000000051cc4>] pstate: 80030010
May 14 18:36:11 kernel: sp : 00000000ffe25f38
May 14 18:36:11 kernel: x12: 00000000000c82f0
May 14 18:36:11 kernel: x11: 0000000000051ba8 x10: 00000000ffe26014
May 14 18:36:11 kernel: x9 : 00000000000c8000 x8 : 0000000000105a94
May 14 18:36:11 kernel: x7 : 0000000000000001 x6 : 00000000f7207ab8
May 14 18:36:11 kernel: x5 : 000000000069ec38 x4 : 0000000000000000
May 14 18:36:11 kernel: x3 : 00000000000b778a x2 : 0000000076acbf00
May 14 18:36:11 kernel: x1 : 0000000000000be1 x0 : 0000000000000000
May 14 18:36:34 watchdog: start httpd

Fortunately everything seemed like working ok afterwards, except for one thing: the system no longer had swapping activated. Moreover, any attempt to manage the swapper with 'amtm' was exiting immediately to the command line right after typing 'sw' (not sure if this behavior from amtm was already existing).
I ended up recreating the swap file in my flashdisk and reenabled swapping with the 'swapon' command

Any idea to further investigate this trap/swapping deactivation or the amtm behavior with the swapper ?

 

[jfgarciamex]

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:


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

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

@RMerlin sorry to bother you, but had you a chance to look into this? Thanks for the great work!

BTW, I tried using https in the reverse proxy and I see the following error:

 

[FTC]

Hi, I saw in the logs of my RT-AX88 running Merlin 388.9_2 this morning a 'trap' from yesterday that seemed related to httpd :

Fortunately everything seemed like working ok afterwards, except for one thing: the system no longer had swapping activated. Moreover, any attempt to manage the swapper with 'amtm' was exiting immediately to the command line right after typing 'sw' (not sure if this behavior from amtm was already existing).
I ended up recreating the swap file in my flashdisk and reenabled swapping with the 'swapon' command

Any idea to further investigate this trap/swapping deactivation or the amtm behavior with the swapper ?

Some forward information. I found the cause for the swapper behavior described above. amtm had appended in the past a 'swapoff' command in the unmount script which did not check for the proper disk where the swap file resided unmount. So I was playing unmounting with my second disk and this provoked the swapping to be disabled. Fixed by correcting the unmount script.

 

[FernandoF]

I'm trying to understand how access controls for Guest Networks work in 3004.388.9 (or even earlier), to potentially try and replicate that behavior in 3006.102.x.
May I ask anybody who is using Guest Network #2 or #3, with "Access Intranet" set to disabled, to share how their ebtables look like?

ebtables -t broute -L

Thank you in advance.

 

[MacG32]

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)

This fixed my connection problems to my guest networks. Thank you so very much @RMerlin and the ASUS Team!