What's new

Release Asuswrt-Merlin 386.9 is now available for AC models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I think you've made your thoughts on ASUS/Merlin quite clear here already - https://www.snbforums.com/threads/gt-ax6000-vs-rt-ax86u.78498/page-3#post-816584

I do wish people would stop reacting/responding to these posts
If he actually has filed these reports and Asus is not responding, I see no reason for him to stop.

Perhaps @RMerlin could try repeating said case-study described above and get in touch with Asus to work out a solution, or at least see what the holdup is?
 
Forget about it @heywire. I know about this issue for at least 2 years and it was tested on many different Asus routers with the same result. It was also reported from stock Asuswrt feedback form with logs twice - on AC86U and AX58U (both 512MB RAM routers). Surprisingly AC68U has a better chance to complete the transfer with its 256MB RAM only, but it takes a day. This is my experience from previous tests. I was hoping something is improved in this firmware. Since reporting bugs irritates Asus fans community I have no valid reasons to waste my time in testing anymore. The last issue I have reported to Asus was broken QoS with IPv6 enabled and unresponsive GUI in 22068 firmware for AX86U. Hopefully they will fix it in future firmware releases.
 
RT-AC68U dirty upgrade from 386.7_2 via Ethernet and Firefox successful. Device configured as an access point. Running smooth for several hours so far. Thank you!
 
@Tech9 That is indeed discouraging, I'm still hoping the next release will hammer-out a few more dents but I do understand how patience can wear-out. I also agree that when certain features are advertised & discovered to be broken... every attempt should be made to fix or AT-LEAST clarify & verify the issue(s). However if they pertain to security vulnerabliities, making that knowledge public could matters even worse, LOL.
 
Well, being doing this for years across lots of hardware and ran into my first issue with this firmware. Getting this error when copying files to the USB NAS function: Router essentially crashes, it freezes Windows and router needs a reboot to come back to life.

Jan 15 16:19:48 out of memory [3472]
Jan 15 16:19:48 out of memory [3472]
Jan 15 16:19:48 out of memory [3472]

Rolled back to 386.7_2 and it doesn't happen. Maybe it's just My AC86U is finally too old to be useful?
 
Forget about it @heywire. I know about this issue for at least 2 years and it was tested on many different Asus routers with the same result. It was also reported from stock Asuswrt feedback form with logs twice - on AC86U and AX58U (both 512MB RAM routers). Surprisingly AC68U has a better chance to complete the transfer with its 256MB RAM only, but it takes a day. This is my experience from previous tests. I was hoping something is improved in this firmware. Since reporting bugs irritates Asus fans community I have no valid reasons to waste my time in testing anymore. The last issue I have reported to Asus was broken QoS with IPv6 enabled and unresponsive GUI in 22068 firmware for AX86U. Hopefully they will fix it in future firmware releases.
Why "forget about it?". Do you want to get the problem solved or not? And unless you are leaving things out or you have failed to test and eliminate other failure-points rigorously enough, your case should be fairly easy to reproduce, and we've got the ear of @RMerlin who has the ear of Asus.

I do remember you banging on about an AC86U hardware failure as to discourage me from figuring out a firmware issue that has since got solved a bunch of months ago.

Are you interested in figuring things out, or just nihilistically whining about it?
 
Why "forget about it?"

Experience. When a major firewall bug was suspected by another user with IPv6 enabled network I spend the time testing and confirmed it with the help of other users. It was coming from Asuswrt base and exposing your entire network to Internet. I made a warning post in Asuswrt release thread later described as spreading FUD. Even your post contains the same type of attitude. In this case - it is what it is, whoever needs it will figure it out.

My AC86U went for recycling so you guys test further, report your findings and find solutions or workarounds. Good luck.

your case should be fairly easy to reproduce

See @tommyv2 post above. It is easy to reproduce indeed.
 
Last edited:
Rolled back to 386.7_2 and it doesn't happen. Maybe it's just My AC86U is finally too old to be useful?
Sounds more like a firmware error, which is exactly what this post is for. Have you tried reproducing it with official firmware and filed a bug report like I suggested to Tech9 above?
 
Even your post contains the same type of attitude.
My "attitude", or call it qualified skepticism, is based on an exchange we had last year over the AC86U where you seemed more interested in discouraging others from getting to the bottom of the issue by blowing it off as "the dreaded AC86U hardware failure" as opposed to solving it, as I mentioned. By no means am I trying to defend Asus and their shirtty testing practices for which I've already paid too heavy a price, but I am interested in weeding out bugs as I am currently invested in an Asus setup.

What other manufacturer do you prefer, that produces reliable firmware, has Mesh functionality where you can reuse old routers, and custom mods like CakeQOS, by the way?

I must admit I haven't done a lot of research outside of the Asus ecosystem, just gradually expanded from where started with an N66U, currently using said N66U in my setup with the excellent, but sadly seemingly abandoned john9527 LTS firmware.
 
as opposed to solving it (hardware)

I have identified most of the hardware issues down to component level, but have no way solving anything. I know how to fix, eventually. I had 4x working AC86U routers using 10x dead ones as donors as one point. This router never had hardware revision change, as far as I know. When I was talking about what I see there were people claiming no issues whatsoever and even hiding the fact their own unit died and was replaced. From day one there is "resistance" in fan base and tendency to ignore issues, even major ones.

I must admit I haven't done a lot of research outside of the Asus ecosystem

I see that. Check alterative sources of information before you invest in hardware. Most people around here have experience with Asus routers only and will give you Asus router replacement or upgrade advice. What you see available in Asuswrt is scaled down and made user friendly version of already available functionality in higher class equipment. The advantage - no much knowledge required and running on low cost equipment.

as opposed to solving it (software)

In this thread I'm just mentioning an issue I knew about from a long time. I'm not a software guy and I can't fix it. If the developers can make improvements - good. If they can't or don't want to - nothing I can do. I have a NAS and I'm using completely different non-Asus network. The issue doesn't affect me in any way. Just trying to help pointing the attention to something wrong I see happening on an available for testing Asus router.
 
Last edited:
Just got kicked out of the GUI when scrolling through system log. Forgot to increase the time after last test run. Is this thing fixable?
From what I can see, it's just a matter of setting a variable to 0 on pages that should not be subject to the autologoff. I haven't tested the fix yet, but in theory it should be simple to add the Syslog page to it.

I also want to add the Wireless Log page, because that's another one where it would make sense.
 
So, here was some weirdness. Today, I suddenly saw my log flooded with 'dump console' messages and noted that wifi had failed in all bands. The single computer that is hardwired to the router continued to have internet access, but wifi was totally inop. A hard reset put things back right, but this was WEIRD!
Attached are the logs at failure time up to reboot.
The last log entry before this upset was from 1/12/23, so things were pretty quiet till then.
I'm clueless, but pleased that things are working again.
 

Attachments

  • Router Log-Jan 16 15.pdf
    297.3 KB · Views: 42
Experience. When a major firewall bug was suspected by another user with IPv6 enabled network I spend the time testing and confirmed it with the help of other users. It was coming from Asuswrt base and exposing your entire network to Internet. I made a warning post in Asuswrt release thread later described as spreading FUD. Even your post contains the same type of attitude. In this case - it is what it is, whoever needs it will figure it out.

My AC86U went for recycling so you guys test further, report your findings and find solutions or workarounds. Good luck.



See @tommyv2 post above. It is easy to reproduce indeed.
Seen that and reminded me of this. Shame though when issues are known, proven, repeatable, etc. Then should be that much easier to troubleshoot and fix.
experience.jpg
 
I also want to add the Wireless Log page

Log pages are not critical - the logs are still there after login. Kicked out of DHCP Server page when adding DHCP manual reservations and before Apply is the really annoying one - nothing is saved after login and has to be typed again. Most people never noticed this issue perhaps because of default 30min auto logout time. I've seen it reported though in previous release threads.

Then should be that easier to troubleshoot and fix

Not really. Some issues originate from closed source component and there is no easy fix. The two above - Auto Logout perhaps has a workaround already mentioned by @RMerlin, Samba - I don't know. AX86U with 1GB RAM also crashes with the same transfer in the same Media Bridge configuration. AC86U lasted about 10min, AX86U was going for 38min before OOM and destination unavailable on the sending PC. My daughter has an eBook files collection of 8.2GB total in ~22.000 files. This one crashes every Asus router I have ever tested for USB transfer to HDD. I've tried FAT32, NTFS, ext4 - no change.
 
Log pages are not critical - the logs are still there after login.
Your complain was specifically about the system log page tho, which I can expect people to want to keep open for an extended period of time (same with the Wireless Log page) while monitoring something. After all, the autologout disable was already implemented specifically on pages like the traffic monitor pages.

Disabling it on other config pages would completely defeat the purpose of having an automated logout however (as I assume Asus' primary goal was to deal with the fact the router cannot allow a second concurrent login). Having the counter reset itself on certain activities would be the proper way to go, however that would require making tons of changes to every single webui page (as you'd want it to reset whenever interacting with a UI element), which would then make them horribly difficult to update whenever merging a newer GPL. That kind of widespread change is better done upstream.

Considering the minimum allowed timeout is 10 minutes and the default being 30 minutes, it would be a very uncommon edge case for someone to take more than 30 minutes to add entries on a DHCP reservation page.
 
Your complain was

I have no complaints. Proper expected behavior is timer reset by user activity in the GUI. Auto Logout kicking out the user on preset time when in the middle of something is wrong. As I said I've seen this reported before and I've seen it personally on multiple firmware versions all the way back to 384 firmware. It's was one of the things on my target check list. I don't know what's needed to fix, but is a long term firmware bug and still present.

Another bug was locking out the user with IPv6 enabled saying someone is already logged in. Another bug was reporting IPv6 disabled with IPv6 enabled in Passthrough mode. I don't know if they are resolved in this firmware, they were also part of my target testing. I don't have this AC86U anymore and no more testing will be done on my side. Folks still using it will test and report and hopefully not like this (very common):

 
I tried updating two times now, no error messages, but FW still shows 387.7_2. Any suggestions?

I tried rebooting, resetting etc...
 
I tried updating two times now, no error messages, but FW still shows 387.7_2. Any suggestions?

I tried rebooting, resetting etc...
Can you provide any details of your setup?

I found that my RT-AC5300 did not want to update while being a mesh node. I had to remove it from the mesh, upgrade it, then readd it to the mesh.

When trying to upgrade it while in the mesh, it displayed the same as you are reporting.
 
Can you provide any details of your setup?

I found that my RT-AC5300 did not want to update while being a mesh node. I had to remove it from the mesh, upgrade it, then readd it to the mesh.

When trying to upgrade it while in the mesh, it displayed the same as you are reporting.
I do have in a mesh setup.

Was it sufficent to just disconnect all the mesh nodes, or did you have to reset all units and set it all up from scratch?
 
I do have in a mesh setup.

Was it sufficent to just disconnect all the mesh nodes, or did you have to reset all units and set it all up from scratch?
I had to delete it from the mesh at the router, then I could do the upgrade. I believe it was seeing the code on my router as being incompatible with the 386.9 code during the upgrade (my router is an GT-AX11000 on 388.1). It gave some message about the code during the upgrade but I didn't screen capture it. Once upgraded, I didn't have any issues with readding it.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top