Release Asuswrt-Merlin 386.12_6 is now available for AC models

[mr8]

This latest 386.12_6 update seems to have bricked my RT-AC68U...

My main RT-AX86U upgraded successfully with the equivalent update, but my RT-AC68U running as a mesh node seems to have been bricked after the 386.12_6 update and stuck with a solid USB 2.0 LED...

Is there any way to recover?

Tried holding the reset button while powering on as well as the WPS button, but the router remains stuck with a single solid LED for USB 2.0.

 

[Dedel66]

Try to use the asus recovery tool:

https://dlcdnets.asus.com/pub/ASUS/wireless/GT-AX6000/Rescue_2103.zip?model=RT-AC68U

Please doublecheck the firmware you`ve choosen for your AC68U.

 

[mr8]

Thanks @Dedel66

I verified the SHA256 for the firmware and it looks good (7a4ba8c403bc2b07235fdc3e7842418b03e357b18d7003f44a53058507547172).

I don't have a windows PC, but I'll try to spin up a VM to run the recovery tool.

I believe the recovery tool still requires the router to go into recovery mode, but mine seems to be stuck with a solid LED on the USB2.0 and I can't get the power LED to flash or light up.

 

[Dedel66]

Did you pay close attention to the name? E.g. there have been people who tried to flash AC86U instead of AC68U...

GOOD LUCK!

 

[mr8]

Just double checked the file that I uploaded and it seems correct:
`RT-AC68U_386.12_6.trx`

 

[heywire]

No, If I go anywhere else with my n66 Media Bridge, it'll be to FreshTomato, which is still under active development. John's Fork is for all intents and purposes abandoned/EoL.

Why do you need a firmware under active development for a Media Bridge? John's fork is both more recently updated and presumably gives better performance than the latest official fw. Tomato is known to have lower wireless performance an no NAT-acceleration (the latter not relevant to your use-case, but just to mention it). Just in case anybody else reads this, anyways.

I do not need AiMesh - I don't have another compatible router, or need for one.

The reason I was asking was to exclude it as a potential source of FW-issues because I suspect Aimesh might have something to do with the instability several users have seen lately, not because I want to sell you something.

I take it your last sentence is why we're still talking. I'd encourage you to learn to put your personal biases aside.

I don't know why you're talking, and not addressing the issue. I'd encourage you to show the receipts as opposed to proving my point through action and inaction.

 

[heywire]

I personally don't want to and can't repeat the entire content I generated for every single forum member. SNB Forums has search feature. You @heywire have 2 issues on your network: (1) an RT-AC86U router in not good state; (2) AiMesh with mixed generation routers and partially wireless. I don't know what your budget is and what your speed requirements are, but I would replace the problematic main router with a cheap RT-AC68U off Marketplace or eBay, find a way to wire currently wireless node, ditch AiMesh and run the extra two routers in AP Mode. This may sound as downgrade to you, but it will stabilize your network instantly, you can still run your favorite Asuswrt-Merlin firmware and you'll get about the same wired and wireless speed to your devices. Everything can be done perhaps under $100 and the hardware you already have is not wasted.

The AC86U is better now after downgrading to 386.10, 5 days going strong. I hope it'll last.

Wiring the wireless nodes on this particular location would be a lot of hassle as there are two buildings close to each other with no cabling-pipe between them, meaning I'd have to mount an outdoors ethernet-cable by air between the buildings. I prefer wiring myself whenever it's possible, but range/speed-wise, wireless works ok here.

I also need the AC86U over the AC68U as a main node because of the required extra range where it is placed, and its CPU speed as I run CakeQOS (that being said, I recently learned to my surprise that the AC68U/AC66_B1 actually can sustain about 200mbps on CakeQOS, at least on the model/revision with the faster CPU, but still, I need the range.)

I also like the overview and flexibility of Aimesh. So if I can find a firmware stable on it, I'll continue to use it.

The next move if that fails going forward would be to buy a mini-PC box running pfsense/opnsense behind the AC86, relegating the AC86 to only managing wifi duties on an older, stable firmware. What I'll NOT do if it fails, is buy a new Asus router, ever.

 

[Tech9]

I hope it'll last

Observe the System Log for clues. If your router crashes - something is totally wrong there. At one point I had 4x AC86U units for tests and although they all had common issue with freezing Trend Micro components - none was crashing on any firmware. With some trial and error and problematic features not in use they worked okay.

I also like the overview and flexibility of Aimesh.

You perhaps will never get the stability you expect with mix and match Asus routers in AiMesh. Many folks around had bad experience and made changes to their networks already. Your routers are not only different generation hardware (AC Wave 1 and AC Wave 2), but also run on different firmware. Only the GUI you see is the same.

 

[Tech9]

but these sorts of messages are not very helpful

Most folks around can't disturb too much their networks and can't really test far beyond "my router came alive" after update. I have available unused Asus routers and can find bugs in every firmware release in under 30min. Every firmware release with no exception and repetitive bugs. I know at least 6 issues with current Asuswrt base for RT-AC68U and they are carried over for a very long time. On every firmware release something is fixed and something else is broken. I give up testing firmware and reporting bugs simply because there is no point. Asus fans community gets angry, Asus won't do much, Eric can't fix closed source. You have to navigate around issues and find your own solution.

 

[heywire]

Observe the System Log for clues.

I even set it to "debug" when I was having connection drops and crashes with .12.x and .11. Not a single trace of mischief, tho. That' what was so weird.

If your router crashes - something is totally wrong there. At one point I had 4x AC86U units for tests and although they all had common issue with freezing Trend Micro components - none was crashing on any firmware. With some trial and error and problematic features not in use they worked okay.

But the thing is, as you can see from this and the previous thread, I'm not the only one having these issues.

What version were you running, and did the TM-crashes affect connection stability?

You perhaps will never get the stability you expect with mix and match Asus routers in AiMesh. Many folks around had bad experience and made changes to their networks already. Your routers are not only different generation hardware (AC Wave 1 and AC Wave 2), but also run on different firmware. Only the GUI you see is the same.

The problem also affected a wired AC66U_B1 node. Hence, it is not related to the wireless connection between the Aimesh nodes themselves. The issues were system wide, indicating that the issues were with the main router, AC86U.

Most folks around can't disturb too much their networks and can't really test far beyond "my router came alive" after update.

Yes they can. Reporting that you've been running it for a while without issues is almost infinitely better than being the 56th guy to report that you made it through an upflash without bricking the router.

I have available unused Asus routers and can find bugs in every firmware release in under 30min. Every firmware release with no exception and repetitive bugs. I know at least 6 issues with current Asuswrt base for RT-AC68U and they are carried over for a very long time. On every firmware release something is fixed and something else is broken. I give up testing firmware and reporting bugs simply because there is no point. Asus fans community gets angry, Asus won't do much, Eric can't fix closed source. You have to navigate around issues and find your own solution.

I'd encourage you to document this in a thread of your own, so that 1.) People can keep track of you discoveries there, and 2) You can refer people to that thread instead of arguing from base in all the other threads where the issues come up. And 3) People can report experiences to the contrary, and maybe some issues could be resolved.

 

[Tech9]

Yes they can.

They can, but they won't test features they don't use. See an example below - the firmware was released in November 2023, I install in February 2024 and find Network Services Filter broken. No one mentioned it for >2 months in this release thread. The workaround was found, waiting for a fix with next firmware release.

Release - ASUS RT-AC68U Firmware version 3.0.0.4.386_51668 (2023/11/30 )

I'm checking something on this firmware and found Firewall, Network Services doesn't save changes. This was a bug in 388 firmware for NHD models for quite some time, but fixed now. This thing here: No one noticed it's not working? The router is RT-AC1900P, runs the same firmware.

www.snbforums.com

instead of arguing from base

No intentions to argue with anyone. As I said to you earlier - I personally can give pointers, take it or leave it. You test what works for you and implement eventual workarounds acceptable for your unique setup and needs. For example - intermittent Wi-Fi issues are common on RT-AC86U and affect both radios. In most cases 2.4GHz radio related. I had a few different model routers with this same issue - RT-AC86U, RT-AC5300 and RT-AX88U. In the name of science all were fixed using the same method - remove the IC chip, clean the PCB pads, reapply leaded solder, resolder the IC. The failure is most likely RoHS and thermal stress related. All routers started working properly after on the same firmware as before. All routers were recycled because RoHS related issues affect the entire PCB. They will fail gain after some time. This happened to one of the "fixed" AC86Us. Now you know and it doesn't help you much, I guess. Separate thread or here - the same result. Same advice as before - don't waste your time, replace.

 

[heywire]

They can, but they won't test features not in use. See an example below - the firmware was released in November 2023, I install in February 2024 and find Network Filter broken. No one mentioned it for >2 months in this release thread. The workaround was found, waiting for a fix with next firmware release.

I think you're arguing my point here, if they did more testing before reporting as to just confirming that the update didn't end up bricking the router, they'd have a higher chance of also catching such bugs.

But that being said, the fact that they don't comprehensively test out every feature in the release doesn't mean that their report is useless. The main thing we want to know before updating is major dealbreakers like basic connection stability issues.

Further than that, people could be encouraged to include exactly what they have been testing.

 

[Tech9]

if they did more testing

I told you - folks around can't do testing on a live system. Most have one router and it's in use by the entire family. Have you seen "can't reboot/upgrade before midnight when my family goes to sleep"? This is the problem and there is nothing to argue about it. Can't interrupt common now work and learn from home process. Not practical.

 

[heywire]

I told you - folks around can't do testing on a live system.

We're obviously operating of different definitions of "testing" here.

I don't know if you are intentionally misinterpreting or what, but clearly, I am talking about "testing" in this context as in "running the new firmware for an extended time in a normal use-case scenario to see if new issues pop".

You seem to be talking about testing as in running a structured test with a battery of tasks/benchmarks. While I encourage that too (in fact, I tried to suggest such a project in a release thread not too long ago, which you staunchly rejected off the bat because it wouldn't be possible to test for every scenario perfectly, by everyone, every time etc. etc.), I was not referring to that.

 

[Tech9]

I don't know if you are intentionally misinterpreting or what

This conversation is over. Unrelated to the specific firmware release anyway. I’ll just read your struggles without saying anything. Good luck.

 

[RMerlin]

and find Network Services Filter broken. No one mentioned it for >2 months in this release thread.

That one's on my bookmarked list of things to track already:

asus ac68u firewall

And I tried removing the original rules after the update. When I reverted to version 11, they reappeared, so they didn't even get deleted. I don't understand why. Thank you so far; I'll appreciate any help. I just don't get it. I've been using Merlin for two years without any issues with updates...

www.snbforums.com

 

[KrypteX]

That one's on my bookmarked list of things to track already:

asus ac68u firewall

And I tried removing the original rules after the update. When I reverted to version 11, they reappeared, so they didn't even get deleted. I don't understand why. Thank you so far; I'll appreciate any help. I just don't get it. I've been using Merlin for two years without any issues with updates...

www.snbforums.com

@RMerlin Is there a newer GPL in sight for the 386 branch, for AC68U more specifically? AFAIK this latest release is still based on GPL 386_51997.

 

[sad-spirit]

I tried upgrading my RT-AC68U from 386.12_2 to 386.12_6 and tor (entware version) stopped working. It got stuck at

Bootstrapped 0% (starting): Starting

in the logs. The process was visible in top with about zero CPU %, but nothing was happening.

After enabling debug logging, it was actually stuck at

Reading entropy from "/dev/urandom"

I tried reading from /dev/urandom and it seemed to properly produce random garbage, it was also world readable so not a permission issue.

Didn't debug further, as tor started working again after downgrade to 386.12_2, while 386.12_4 had the same issue as the latest release. Didn't reset to factory setting in either upgrade or downgrade.

 

[RMerlin]

@RMerlin Is there a newer GPL in sight for the 386 branch

Not at the moment. I'm already using newer GPL than the stock firmware for multiple models, I'm in no hurry to merging a newer one. The 386 platform is a legacy one, and won't get as active development as the 388 branch. The next major release will most likely be the final release for the SDK 7 models (RT-AC88U, RT-AC3100 and RT-AC5300) as these have already been EOL by Asus for a few months now.

 

[RMerlin]

Didn't debug further, as tor started working again after downgrade to 386.12_2, while 386.12_4 had the same issue as the latest release.

Your issue lies elsewhere. There was only one single change between 386..12_2 and 386.12_4, and it was OpenVPN.

merlin@ubuntu-dev:~/amng$ git log --oneline 386.12_2..386.12_4
0ba89a5c78 (tag: 386.12_4) Updated documentation
b08bd8170d Bumped revision to 386.12_4
bd9c4cc050 openvpn: update to 2.6.8

If urandom does not return anything it means the entropy level isn't high enough yet for it to be functional. Make sure you don't try using it before haveged has started and starting populating the entropy pool.