Release Asuswrt-Merlin 3004.388.4 is now available

[Morris]

1, and the known issues 2, 3 etc.

Thank you, 1 is the answer I was looking for. I believe the May issue has been corrected unless his router has been turned off for months.

 

[MDM]

Thank you, 1 is the answer I was looking for. I believe the May issue has been corrected unless his router has been turned off for months.

Yes, the May one; but as you can see in the log, it just happened to me (only once as of now)
Thus is why I asked...

 

[Morris]

Yes, the May one; but as you can see in the log, it just happened to me (only once as of now)
Thus is why I asked...

Be thankful that they trap it, snap and continue operation. You could report it to Asus except they might not accept your issue with Merlin code.

 

[MDM]

Be thankful that they trap it, snap and continue operation. You could report it to Asus except they might not accept your issue with Merlin code.

They probably would, since they have a separate ASD update for Merlin FW.

 

[sivaprasath]

Hello Everyone,
I have AiMesh configuration with AX88U (Main Router) -> AX58U (Node - Connected via Ethernet Backhaul).
Only, when 160Mhz client is connected to AX88U(Main), I am seeing the DFS State become active in the "System Log" -> "Wireless Log" page. If the 160Mhz client is connected to the AX58U(Node), the DFS state goes to "idle" and until any other client with 160Mhz capable connect to the Main router the DFS state remains in Idle state.

Is it not supposed to 160Mhz be in active, even when the 160Mhz client connected to AiMesh node also? Please advise in this scenario.

 

[L&LD]

I don't see this as an issue. A node, with no clients connected, is really transmitting/communicating at anywhere close to 160MHz bandwidth limits.

Looks normal to me.

 

[sivaprasath]

I don't see this as an issue. A node, with no clients connected, is really transmitting/communicating at anywhere close to 160MHz bandwidth limits.

Looks normal to me.

In my scenario, the AiMesh Node (AX58U) is connected with two 160Mhz capable client (Windows 11). But both these clients are still operating in 80Mhz.
I am expecting these clients connected to AiMesh node should operate in 160Mhz. Is my expectation is wrong?

IF I force these clients to bind to AX88U (Main Router), then both these client are working fine with 160Mhz capability.

 

[Steely74]

One week since a clean upgrade on my AX58Us (1 main, 1 node) and zero issues!

 

[L&LD]

@sivaprasath, sorry, I misunderstood. Sounds like a bug, for sure.

I would use the following link below to capture your current setup.

Is it a good idea to keep up with Firmware updates?

I have had issues in the past when updating firmware and Internet speed, But it may have just been a fluke, Should I keep up with the updates? If so On all routers or the nodes as well? What about ones acting as access points? Thanks

www.snbforums.com

Then, I would flash the latest Asus stock firmware to verify this issue also exists there.

If it does, then use the feedback button in that stock firmware to report it to Asus so they can fix it.

You can then flash the firmware you have running now, and use the backup you've made to quickly get back to where you are now.

 

[sivaprasath]

@sivaprasath, sorry, I misunderstood. Sounds like a bug, for sure.

I would use the following link below to capture your current setup.

Is it a good idea to keep up with Firmware updates?

I have had issues in the past when updating firmware and Internet speed, But it may have just been a fluke, Should I keep up with the updates? If so On all routers or the nodes as well? What about ones acting as access points? Thanks

www.snbforums.com

Then, I would flash the latest Asus stock firmware to verify this issue also exists there.

If it does, then use the feedback button in that stock firmware to report it to Asus so they can fix it.

You can then flash the firmware you have running now, and use the backup you've made to quickly get back to where you are now.

Thanks for providing the detailed steps to report this issue to Asus.

In the meantime, can anyone in this forum can try to reproduce this issue and confirm the same behaviour if possible?

 

[L&LD]

If you've performed a full reset (of both routers), not imported any old backup config files (particularly ones from another router), configured the router minimally and manually (to secure it and connect to your ISP), and they exhibit the same issues, then you're safe in reporting this as a true bug.

 

[sivaprasath]

If you've performed a full reset (of both routers), not imported any old backup config files (particularly ones from another router), configured the router minimally and manually (to secure it and connect to your ISP), and they exhibit the same issues, then you're safe in reporting this as a true bug.

YES, I confirm that both the AX88U(Master) & AX58U(Node) are hard reset using (WPS + WebUI) and with default configurations when I verified this behaviour for 160Mhz.

 

[maxbraketorque]

Hmmm, ASUS messed up some ASD security file update again...? Anyone else??

Sep 7 22:18:34 kernel: potentially unexpected fatal signal 11.
Sep 7 22:18:34 kernel: CPU: 3 PID: 2670 Comm: asd Tainted: P O 4.19.183 #1
Sep 7 22:18:34 kernel: Hardware name: GTAX6000_50991 (DT)
Sep 7 22:18:34 kernel: pstate: 400f0010 (nZcv q A32 LE aif)
Sep 7 22:18:34 kernel: pc : 00000000f70e3400
Sep 7 22:18:34 kernel: lr : 00000000f70e4840
Sep 7 22:18:34 kernel: sp : 00000000ff947ca0
Sep 7 22:18:34 kernel: x12: 00000000f70f8154
Sep 7 22:18:34 kernel: x11: 00000000f70e713c x10: 00000000f70e6a4c
Sep 7 22:18:34 kernel: x9 : 00000000ff947cbc x8 : 0000000000000000
Sep 7 22:18:34 kernel: x7 : 00000000ff947cc0 x6 : 00000000018c77c0
Sep 7 22:18:34 kernel: x5 : 00000000018c3b88 x4 : 00000000018c3a08
Sep 7 22:18:34 kernel: x3 : 00000000f6d00a58 x2 : 0000000000000000
Sep 7 22:18:34 kernel: x1 : 0000000000000400 x0 : 0000000000000000
Sep 7 22:18:38 rc_service: service 16827:notify_rc restart_firewall

I'm seeing frequent ASD crashes in 386.12 on my AC86U running in AP mode, but nothing for my GT-AX6000 main/AP combo running 3004.388.4.

 

[MDM]

I'm seeing frequent ASD crashes in 386.12 on my AC86U running in AP mode, but nothing for my GT-AX6000 main/AP combo running 3004.388.4.

As I understood RMerlin, it has nothing to do with FW versions or models, and it auto-updates with no possibility to prevent it.
ASUS updates it solo, eg. if you are stuck with a bad ASD update and the new one can not fix it, they advise full reset (JFFS in particular) which is a pain!

ie. Since that one occurrence, it hasn't resurfaced agin until now...

 

[HoopsRsa]

I am having a strange issue with my GT-AX6000 on the 3008.344 firmware. It runs perfectly for a day or two and then suddenly all devices cannot access the internet. The router looks normal and WAN is up and showing the ISP IP address normally. PC's show the internet connection as normal and do not show the "world" that normally shows when the internet goes down.

A reboot resolves the issue. I have attached a extract of the log in the time frame where the error happens (see attached) - can someone please have a look and see if they can see the issue.

 

[MDM]

I am having a strange issue with my GT-AX6000 on the 3008.344 firmware. It runs perfectly for a day or two and then suddenly all devices cannot access the internet. The router looks normal and WAN is up and showing the ISP IP address normally. PC's show the internet connection as normal and do not show the "world" that normally shows when the internet goes down.

A reboot resolves the issue. I have attached a extract of the log in the time frame where the error happens (see attached) - can someone please have a look and see if they can see the issue.

Seams clear to me by just a look at it, because it states it clearly: YazDHCP - dnsmasq issue.
So the add-on itself, or your ISP having micro disconections that messes it up. Would go with the first for portability...

 

[HoopsRsa]

Seams clear to me by just a look at it, because it states it clearly: YazDHCP - dnsmasq issue.
So the add-on itself, or your ISP having micro disconections that messes it up. Would go with the first for portability...

Thank you, will uninstall YazDHCP and see if I have any more issues.

 

[Jeffrey Young]

I am having a strange issue with my GT-AX6000 on the 3008.344 firmware. It runs perfectly for a day or two and then suddenly all devices cannot access the internet. The router looks normal and WAN is up and showing the ISP IP address normally. PC's show the internet connection as normal and do not show the "world" that normally shows when the internet goes down.

A reboot resolves the issue. I have attached a extract of the log in the time frame where the error happens (see attached) - can someone please have a look and see if they can see the issue.

As @MDM has pointed out, dnsmasq is crashing after the list of hosts is loaded. Check your hosts file you created in dnsmasq. Check for any duplicate MAC address or incorrectly formatted MAC address. I've had this happen to me. It was a MAC address on a dhcp-host line that I mistyped.

 

[maxbraketorque]

As I understood RMerlin, it has nothing to do with FW versions or models, and it auto-updates with no possibility to prevent it.
ASUS updates it solo, eg. if you are stuck with a bad ASD update and the new one can not fix it, they advise full reset (JFFS in particular) which is a pain!

ie. Since that one occurrence, it hasn't resurfaced agin until now...

I had not heard anything about a full reset being required to stop ASD crashing, but I did read that there was some success with deleting ASD-related files which I have done but didn't make a difference. For now, I will live with it because it seems to be having zero effect on router performance.

 

[HoopsRsa]

As @MDM has pointed out, dnsmasq is crashing after the list of hosts is loaded. Check your hosts file you created in dnsmasq. Check for any duplicate MAC address or incorrectly formatted MAC address. I've had this happen to me. It was a MAC address on a dhcp-host line that I mistyped.

Thank you, I will have a look at the export file and see if I can find any errors.