Release Asuswrt-Merlin 3004.388.10 is now available

[Diablo99]

Dirty upgrade on my RT-AX86U from 3004_388.9_2 with no issues so far.
Looks Good.

 

[Diablo99]

Edit : After disabling the “Protected Management Frames” option on the 2.4 GHz band, the HP printer's Wi-Fi connection seems stable.
It's strange, because with the old version 3004.388.9_2, the “Protected Management Frames” option was always enabled on the 2.4 GHz band and the HP printer's Wi-Fi connection worked perfectly well.

There must have been a small change in the latest Merlin firmware.

Ultimately, the printer connection remains stable when this option is disabled.

Have roaming assistant also disabled on 2.4 & 5.0 ghz?

This caused a lot of connection problems.

 

[The PyroPath]

Just as an FYI, I hit the bullet and got my hands on a "cheap" , on sale, last in stock BE92U. For those wondering, the current 3006 Merlin doesn't show the same issues with the app, Home Assistant or general instability, disconnects, internal restarts of processes, etc. What has stayed are several "kernel: CFG80211-ERROR" 's but these are less frequent and they don't appear to hinder the connections, loading of router interface pages etc. I know this isn't a fix for others, but just wanted to let you guys know.

 

[Dex1010]

Olá a todos,
Estou com problemas com o firmware mais recente 3004.388.10 no meu Asus AX88U.
No início, o flash sujo funcionou corretamente, mas depois as coisas deram errado desde que reiniciei meu roteador; Embora meus dois Wi-Fis de 2,4 e 5 GHz tenham sido ativados separadamente, o ícone do Wi-Fi no MerlinWRT ficou meio verde, meio cinza, e os dispositivos de rede não têm Wi-Fi.
Tente reiniciar, ativar/desativar a WLAN e, por fim, redefinir as configurações de fábrica e configurar tudo novamente, sem sucesso; A rede Wi-Fi é indisponível/invisível em meus dispositivos, não pode ser bloqueada.
Alguém mais passou por isso?
Obrigado pela ajuda.

Editar: Ah, a propósito, observei um detalhe adicional: meu Wi-Fi 5 GHz só oferece o Canal 0...

Hey friend, I'm having the exact same problem as you. My RT-AX88U suddenly lost 5GHz, and both USB ports stopped working. Initially, I thought it might be a hardware issue, as I've tried everything imaginable and the 5GHz won't come back, and neither do the USB ports. They even have some power, as they power the connected hard drive, but they can't recognize the device.

I'll demonstrate this with photos in the link below.

< https://limewire.com/d/sbYdg#EWtvViIoSW >

Did you manage to get yours working on 5GHz again?

 

[Dex1010]

English only please.

 

[ColinTaylor]

Hey friend, I'm having the exact same problem as you. My RT-AX88U suddenly lost 5GHz, and both USB ports stopped working. Initially, I thought it might be a hardware issue, as I've tried everything imaginable and the 5GHz won't come back, and neither do the USB ports. They even have some power, as they power the connected hard drive, but they can't recognize the device.

I'll demonstrate this with photos in the link below.

< https://limewire.com/d/sbYdg#EWtvViIoSW >

Did you manage to get yours working on 5GHz again?

Did you have AiCloud enabled?

Go to System Log - General Log and Save the log file. Upload it to limewire.com or www.file.io

 

[Dex1010]

Did you have AiCloud enabled?

Go to System Log - General Log and Save the log file. Upload it to limewire.com or www.file.io

I've never enabled iCloud.

Below is a general log file.

<https://limewire.com/d/Os1DV#AtrplGLDhq>

 

[ColinTaylor]

Below is a general log file.

<https://limewire.com/d/Os1DV#AtrplGLDhq>

Looks like a hardware failure to me. But maybe someone else can spot something I'm not seeing.

 

[Dex1010]

Looks like a hardware failure to me. But maybe someone else can spot something I'm not seeing.

Thank you for your review.

If it's indeed hardware, I think there's a hidden flaw in the RT-AX88U's design, considering this same issue has been reported by some users.

 

[aex.perez]

I wouldn't jump the gun on hardware failure so quickly

That log looks eerily similar to my logs at the when my AX88 router went sideways after a few days on the release before I dropped back to BETA1 to get back to stability. After running that version, about a week. During which I had but one hiccup (30 secs of "<unknown>: hw csum failure" at the router) but it recovered, and life remained stable the rest of the time. The scripts weren't complaning, https and http wasn't restarting, channels weren't constantly changing either, services were no longer failing and restarting and logging stated.

I reapplied to release onto the AX86 nodes, with BETA1 on the AX88 router. After a few days of stability, I applied the release to the AX88 router again (earlier today) and so far so good let's see if it stays stable or goes bonkers again after a few days as it has for others.

For now avoiding even launching the app on the iPhone, even though it was just for visibility. Just logging into the router would trigger services (http/httpd/acs amongst others) to continously restart...

 

[Dex1010]

I wouldn't jump the gun on hardware failure so quickly

That log looks eerily similar to my logs at the when my AX88 router went sideways after a few days on the release before I dropped back to BETA1 to get back to stability. After running that version, about a week. During which I had but one hiccup (30 secs of "<unknown>: hw csum failure" at the router) but it recovered, and life remained stable the rest of the time. The scripts weren't complaning, https and http wasn't restarting, channels weren't constantly changing either, services were no longer failing and restarting and logging stated.

I reapplied to release onto the AX86 nodes, with BETA1 on the AX88 router. After a few days of stability, I applied the release to the AX88 router again (earlier today) and so far so good let's see if it stays stable or goes bonkers again after a few days as it has for others.

For now avoiding even launching the app on the iPhone, even though it was just for visibility. Just logging into the router would trigger services (http/httpd/acs amongst others) to continously restart...

I've reverted to older firmwares, upgraded to native firmwares, and returned to newer firmwares, both Merlin and native, but the problem persists. I'm inclined to accept that I lost a router that was still quite new and for which I paid a high price for the type of product, which angers me, as I paid extra precisely because I believed it was a premium product.

 

[RMerlin]

I'm inclined to accept that I lost a router that was still quite new and for which I paid a high price for the type of product, which angers me, as I paid extra precisely because I believed it was a premium product.

If even a multi-million dollars space shuttle can have hardware failures, then so does a premium router. Technology isn't immune to failures no matter how expensive it is.

Have you tried an electrical reset? Unplug the power (while keeping the router switch turned on. Wait about 5-10 secs, turn it off, plug it back in, then turn it on and try again.

 

[Dex1010]

If even a multi-million dollars space shuttle can have hardware failures, then so does a premium router. Technology isn't immune to failures no matter how expensive it is.

Have you tried an electrical reset? Unplug the power (while keeping the router switch turned on. Wait about 5-10 secs, turn it off, plug it back in, then turn it on and try again.

I've already tried everything. I've been studying the problem for days. So much so that I've seen several users reporting the same problem.

Therefore, it's not a natural electronic equipment defect, as suggested. On the contrary, it's revealing a hidden flaw resulting from a design error, as it's not natural for multiple users to experience the same issue.

Note that in this same thread, just above, a user reports the exact same issue as me. Is this a coincidence?

Just to clarify, I had already performed the electrical reset, but it had no effect on the problem.

 

[ExtremeFiretop]

Therefore, it's not a natural electronic equipment defect, as suggested. On the contrary, it's revealing a hidden flaw resulting from a design error, as it's not natural for multiple users to experience the same issue.

Note that in this same thread, just above, a user reports the exact same issue as me. Is this a coincidence?

Thank you for your review.

I think there's a hidden flaw in the RT-AX88U's design, considering this same issue has been reported by some users.

Just because you noticed a pattern doesn’t mean there’s a design flaw, it’s not automatically true just because multiple failures exist.

You’re mistaking correlation (multiple failures observed) for causation (a proven design flaw). In reality, with mass-produced electronics, some overlap in manufacturing defects is statistically expected, even among high-end products.

Hundreds of identical failures out of millions shipped can occur without implying a design flaw. So, to your question about coincidence. Yes, it’s normal for mass-produced equipment to suffer failures, even for multiple users.

That doesn’t prove a fundamental design flaw; it just shows correlation, not causation. The actual cause could be many things outside of design, such as environmental factors (e.g., a power surge or voltage instability, etc).

 

[ppfoong]

Looks like a hardware failure to me. But maybe someone else can spot something I'm not seeing.

Seems there are some bad sectors in the internal storage:

Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01

 

[ColinTaylor]

Seems there are some bad sectors in the internal storage:

Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01

They are not errors. They're normal boot messages.

 

[Dex1010]

Just because you noticed a pattern doesn’t mean there’s a design flaw, it’s not automatically true just because multiple failures exist.

You’re mistaking correlation (multiple failures observed) for causation (a proven design flaw). In reality, with mass-produced electronics, some overlap in manufacturing defects is statistically expected, even among high-end products.

Hundreds of identical failures out of millions shipped can occur without implying a design flaw. So, to your question about coincidence. Yes, it’s normal for mass-produced equipment to suffer failures, even for multiple users.

That doesn’t prove a fundamental design flaw; it just shows correlation, not causation. The actual cause could be many things outside of design, such as environmental factors (e.g., a power surge or voltage instability, etc).

I still believe that too much coincidence is never a coincidence.

To further fuel my distrust of Asus, they now claim they don't have technical support for routers in their country so I can request a repair, even though they sell such devices in my homeland.

In other words, I'll end up taking legal action, not to get the device, but to try to get it repaired somehow, because Asus is no more for me.

 

[RMerlin]

Seems there are some bad sectors in the internal storage:

Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01

What it tells you is the location of the tables that contains the list of bad sectors, not that a bad sector was detected. Bad sectors are very common in NAND, that's why they have tables where these blocks are noted, and any bad sector is remapped to a spare sector.

 

[aex.perez]

Well, ran solid overnight with a few addon script issues.

Logging seems way off, with BACKUPMON, MerlinAU and a few other, even my own script which runs every 30 minutes are not logging anything under the release but under Beta1 it did.

Example:
Before:
Oct 13 03:30:00 Router channel_check: Checking...
Oct 13 03:30:00 Router channel_check: Done.
Oct 13 04:00:00 Router channel_check: Checking...
Oct 13 04:00:00 Router channel_check: Done.
Oct 13 04:30:00 Router channel_check: Checking...
Oct 13 04:30:00 Router channel_check: Done.
Oct 13 05:00:00 Router channel_check: Checking...
Oct 13 05:00:00 Router channel_check: Done.
Oct 13 05:30:00 Router channel_check: Checking...
Oct 13 05:30:00 Router channel_check: Done.
Oct 13 05:30:13 Router Master: BACKUPMON INFO: Finished backing up JFFS to /tmp/mnt/backups/ax88/286/jffs.tar.gz
Oct 13 05:30:15 Router Master: BACKUPMON INFO: Finished backing up NVRAM to /tmp/mnt/backups/ax88/286/nvram.cfg
Oct 13 05:31:49 Router Master: BACKUPMON INFO: Finished backing up EXT Drive in 94 sec to /tmp/mnt/backups/ax88/286/ssd1.tar.gz
Oct 13 05:32:09 Router Master: BACKUPMON INFO: Finished secondary backup of JFFS to /tmp/mnt/sdb/router/2ndBackup/13/jffs.tar.gz
Oct 13 05:32:12 Router Master: BACKUPMON INFO: Finished secondary backup of NVRAM to /tmp/mnt/sdb/router/2ndBackup/13/nvram.cfg
Oct 13 05:33:46 Router Master: BACKUPMON INFO: Finished secondary backup of EXT Drive in 94 sec to /tmp/mnt/sdb/router/2ndBackup/13/ssd1.tar.gz
Oct 13 06:00:00 Router channel_check: Checking...
Oct 13 06:00:00 Router channel_check: Done.

After: Nothing

My script calls logger, even logger from the command line fails on the router, but does log on the Node. Because I do run the scribe addon, and it gave me issues the last time I ran with the release version of the firmware. I stopped scribe and logger from the command line started working again. Restarted it, and updated to the Develop version and logging again started.

I noted the first time I ran with the Released version of the FW, that a number of scripts were also failing or not running correctly. Scribe was one of those examples, so as I continue monitoring for issues, if the addons begin to act funny (technical term ). I will try this approach to get them working again. I suspect some of the Scribe filters were being applied incorrectly, because in the log I found: "Router-4865FC6-C kernel: klogd:" a few times and that never appears in any preveious log at least not "Router-4865FC6-C" anyway even certain log updates, at least the one that logged, were ending up in the wrong bucket, another clue.

This is what it should look like, and it does now:
Oct 17 11:14:02 kernel: klogd: exiting
Oct 17 11:14:02 syslogd exiting

Now that logging/scribe is working again, lets see if everything remains settled down.
The saga continues...

UPDATE: Most everything is (even roamast ) logging again, and it's starting to look like normal again

 

[Lexcess]

Hi, I just want to echo that I am seeing similar issues with the new update as some others in this thread.

I have a RT-AX88U operating in wireless router mode (I have separate supplier modem), that I updated to the new firmware. It is the primary in an AI Mesh with a Zen Wifi AX (via an Ethernet backbone) on the latest stock firmware.

After applying the update, I started seeing devices dropping out and reconnecting. I have a 2Ghz and 5Ghz network and the issues seemed to be with the 5ghz network only on the RT-AX88U (the Zen didn't seem to have issues). Looking at the logs, they were filled with messages similar to below (apologies I do not have the expertise to diagnose myself):

Oct 15 16:43:49 wlceventd: wlceventd_proc_event(722): eth6: Assoc FC:XX:XX:XX:XX:22, status: Successful (0), rssi:-43
Oct 15 16:43:49 wlceventd: wlceventd_proc_event(685): eth6: Auth 66:XX:XX:XX:XX:5E, status: Successful (0), rssi:0
Oct 15 16:43:49 kernel: br0: received packet on eth6 with own address as source address
Oct 15 16:43:49 wlceventd: wlceventd_proc_event(695): eth6: ReAssoc 66:XX:XX:XX:XX:5E, status: Successful (0), rssi:-64
Oct 15 16:44:03 wlceventd: wlceventd_proc_event(662): eth6: Disassoc 66:XX:XX:XX:XX:5E, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 16:44:03 wlceventd: wlceventd_proc_event(662): eth6: Disassoc 66:XX:XX:XX:XX:5E, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 16:44:22 wlceventd: wlceventd_proc_event(662): eth6: Disassoc FC:XX:XX:XX:XX:22, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 16:44:22 wlceventd: wlceventd_proc_event(662): eth6: Disassoc FC:XX:XX:XX:XX:22, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 16:44:24 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:XX:XX:XX:XX:22, status: Successful (0), rssi:0
Oct 15 16:44:24 wlceventd: wlceventd_proc_event(722): eth6: Assoc FC:XX:XX:XX:XX:22, status: Successful (0), rssi:-43
Oct 15 16:44:28 wlceventd: wlceventd_proc_event(685): eth6: Auth 66:XX:XX:XX:XX:5E, status: Successful (0), rssi:0

Restarting all the nodes seemed to alleviate things, but I was still seeing disconnects (it was most noticeable on mobile and laptop devices) while all devices connected via the Zen node or ethernet were fine.

I note some people were having issues with HA integration. I use the custom ASUS WRT integration (https://github.com/Vaskivskyi/ha-asusrouter) via HTTP and didn't experience any issues with it. Obviously, it was pinging that tracked devices were connecting & disconnecting, but from its point of view that was correct. It could view the meshes state and manage features without issue. Also, I find it interesting that the ASUS app isn't working for people with the older or newer Merlin firmware, because I haven't had that issue.

After reverting the RT-AX88U router to 9_2 everything has gone back to normal, and I no longer see these messages in the logs or experience disconnects.