Release Asuswrt-Merlin 386.12 is now available for AC models

[heywire]

This all comes from Asuswrt base. The reason I switched to testing Asuswrt only... before giving up completely. There no bug-free version. One thing fixed and another broken every single time release after release. All base issues eventually end up in Asuswrt-Merlin. Drivers, all TrendMicro, other proprietary components - all closed source. There was no point for me testing Asuswrt-Merlin first and then finding the same issue in base Asuswrt.

But there are better and worse releases. And some releases affect some setups/routers, while other work better for some.

All we have now is a bunch of people filling this feedback thread with mostly useless comments like "dirty upgraded two minutes ago, all working fine, thank you Merlin *forgets to post setup*", before some days later, people start reporting of issues that occur ocationally under use. And then maybe some others say that they've experienced similar issues, but it seldom reaches any conclusive answer because most issues are intermittent, not predictable and the discussion dies out.

These might or might not be due to individual quirks in their setup, or it could be a systematic issue in the release.

So all I'm hearing in these dismissive responses are you guys indirectly making my point. But you seem fixated on the idea that I think this is some sort of scientifically rigorous lab methodology, which it is not and I don't. What I'm actually suggesting is a simple "statistical" method that can help separate the chaff from the weeds.

And then when we have reached conclusive issues, people can try the newest official firmware and if they also appear there, feedback with logs can be filed through the Asus official firmware web interface so the issues gets fixed downstream. Quite the simple but efficient procedure, really.

 

[igo]

Have you tried other clients?

I used a macbook pro retina 2012 15" with OCLP (unofficial support) running MacOS Monterey at the time I wrote this post, because my main unit, Imac 2017 was out of order.

The MBPR2012-15 has a wifi card that is not officially supported after MacOS Catalina, so the OCLP developers has retrofitted these drivers to run with newer versions of MacOS. So my guess is that the connection drops was related to this. I am not experiencing it on my Imac now, even on 386.12.

I also ran OpenVPN (tunnelblick), and as it holds a constant connection to the host and pings it regularly, it would show a disconnection notice every time there was a drop.

If you have another client, try running openvpn on it, disable sleep/hibernation so the openvpn connection stays online, and pay notice to the time connected. If you check on in on it and the uptime shows a shorter time than when you started it, you probably had a wifi connection drop in-between.

well connection is stable again on .11 still since last post.

 

[Tech9]

But there are better and worse releases.

Correct. For some users the latest is always the greatest, but sometimes it isn't for various reasons.

useless comments like "dirty upgraded two minutes ago, all working fine

Correct. I fought against this practice in release threads. This is the level of testing before release you were asking about - with "installed 2 minutes ago" at least you know your router model will come back alive after update. Because after one of Asuswrt releases some routers had to be RMA'd. From this point on - you are the one testing. Asus won't invest more time in your device and a single developer with 3rd party enhancements has no chance to do it.

 

[MarkyPancake]

it's the other way around for me. was working fine on 386.11. broken on 386.12

Same. I upgraded my AC86U from 386.11 to .12 today and the network map and client list are failing to display changes to device names, devices no longer connected still show in the active device lists, and no matter how many times I delete devices from the offline client list, they come back. Even tried removing them via the Asus Router app as a last resort and they just reappear. Reboots haven't resolved these quirks either.

 

[heywire]

Same. I upgraded my AC86U from 386.11 to .12 today and the network map and client list are failing to display changes to device names, devices no longer connected still show in the active device lists, and no matter how many times I delete devices from the offline client list, they come back. Even tried removing them via the Asus Router app as a last resort and they just reappear. Reboots haven't resolved these quirks either.

To make a long story (all documented in this thread, I have flashed back and forth a few times) short, I flashed back down to .11 before eventually giving it a new go up to .12 again the other day. And suddenly, everything was back to normal, including Network Map, on .12.

Strange, but you could try and see if flashing down and up works for you too.

 

[Natty]

mostly useless comments like "dirty upgraded two minutes ago, all working fine, thank you Merlin

Two minutes does seem a bit hasty, but this raises the question: how long does it have to be working without issue before "seems to work fine" becomes worth reporting?

Does the forum only want to hear about when there are issues, with no reports of "everything seems to work fine"?

Personally, I find it useful to find out if someone with the same model router as me has encountered issues, or upgraded successfully and been running without issue for a few days.

 

[heywire]

Personally, I find it useful to find out if someone with the same model router as me has encountered issues, or upgraded successfully and been running without issue for a few days.

Yes, that is what I am looking for also. Preferably with some more details on what has actually been tested. But it seems like most of the feedback comes in the form of the example I gave, unless people are encountering issues.

Ideally, I would also like people to run certain tests/procedures to stress test their setup on the new firmware and accelerate any known issues that frequently occur from one firmware version to the next, and give some form of standardized feedback so that we can get more data and increase the probability that upgrading is indeed safe for rolling out in semi-critical environments.

Which is why I suggested this a page or two back. But as you can see from the feedback, there seems to be little appetite for this, because it's not perfect(?), even if it is better/would give a broader dataset than any other test I'm aware of in the pipeline. So, I guess we have to settle for guinea pig'ing and explicitly asking each other in every release-post.

 

[a_shot_on_ehlo]

We have an RT-AC86U, I do use cake QoS. Having random wifi dropouts since upgrading to .12. It's happening on both TV's, laptops and all our phones. Zero issues at all on ethernet on my main PC.

 

[Tomo]

No problem here with .12 on my ac86u, no wi-fi problem, none self reboot, ca-ke is ok, tik-tok is ok and network map ip client too.
I did full reset ( unmount usb>reboot>firmware upgrade>factory reset from ui>reboot>mount usb>manually configuration>switch-off 2 min>turn on) with major release .11 and dirty upgrade with last .12, my temperatures are cold becouse i modded my router, i running on it Skynet and AdGuardHome with 3 block-list.
From .12 release i rebooted only one time for a local blackout.
I also have a ac68u as mesh nonde in ethernet link and configured wifi in smart connect ("2.4"ghz -20mhz and manual channel /\ "5"ghz - auto).

 

[heywire]

We have an RT-AC86U, I do use cake QoS. Having random wifi dropouts since upgrading to .12. It's happening on both TV's, laptops and all our phones. Zero issues at all on ethernet on my main PC.

You upgraded from .11 w/cake which had had no problems?

Flashing back down to .11 and up to .12 again seems to have solved my issues (it could be hit and miss, tho. I haven't flashed back and forth even more times in order to pinpoint the issues.). So you could try that. Obviously, you have tried a simple reboot?

Have you checked your log for any messages at the time the wifi dropouts happen?

Do you have an Aimesh setup, and if yes (particularly of you have a wired one) does the instability also happen there?

 

[dlandiss]

Ideally, I would also like people to run certain tests/procedures to stress test their setup

The sticking point would be WHAT tests and WHAT configurations? Eric is already aware of the vast majority of trouble points, and often beats ASUS to a fix that they later adopt. The usefulness of trouble reports (with accurate documentation) here is that they pick up the totally UNexpected and UNknown issues.

 

[heywire]

The sticking point would be WHAT tests and WHAT configurations? Eric is already aware of the vast majority of trouble points, and often beats ASUS to a fix that they later adopt. The usefulness of trouble reports (with accurate documentation) here is that they pick up the totally UNexpected and UNknown issues.

And I'm suggesting to increase the probability that those gets accelerated, by running stress-tests that simulate the regular use that would accumulate over time - time that can be spent on a stable firmware while the issues are being worked on, rather than having the low intensity stress of intermittent bugs popping up any time, which is fairly stressful if you're running a network people have to rely on. By running some standardized tests that stresses various parts of the network/router/connection to the point that those float to the top across similar setups.

If you've followed this thread, you will see that I got some CakeQOS commands to run after a "tiktok-test"/buffering-test. Which means that at least one such test exists. Later, I told someone that OpenVPN connection time can help you see how long a client has stayed connected even if you're not actively using that client, and thereby catch disconnection issues. A monitoring tool I discovered myself, that could be coupled with a test.

These are just some examples. I'm asking for more suggestions. I think the principle is fairly straigh-forward and sound, and so I really don't see the reason behind the criticism beyond some "Not Invented Here" related issues, really.

 

[bennor]

Folks who are discussing firmware testing, a suggestion. Why not start a new discussion on testing the firmware rather than continually dragging this one further off topic. This discussion was supposed to be discussing 386.12 but seems to have devolved into discussing testing methods of firmware in general over the last two pages.

 

[heywire]

Folks who are discussing firmware testing, a suggestion. Why not start a new discussion on testing the firmware rather than continually dragging this one further off topic. This discussion was supposed to be discussing 386.12 but seems to have devolved into discussing testing methods of firmware in general over the last two pages.

Because it they have evolved into parallell discussions - how to tease out and reproduce the issues some people evidently still are having with .12, what stress-test could be used, and whether these could be made general going forward. It devolved into a lot more misunderstandings and misplaced objections than actual suggestions, which I couldn't have foreseen.

Right now, people seem to just pull back to .11 and call it a day instead, increasing the possibility that these issues will persist through the next versions.

 

[The Chief]

dig command causes error in the log:

Spoiler: Log

Sep 27 10:44:01 RT-AC86U kernel: dig[17548]: syscall 425
Sep 27 10:44:01 RT-AC86U kernel: Code: aa0503e4 aa0603e5 aa0703e6 d4000001 (b13ffc1f)
Sep 27 10:44:01 RT-AC86U kernel: CPU: 0 PID: 17548 Comm: dig Tainted: P O 4.1.27 #2
Sep 27 10:44:01 RT-AC86U kernel: Hardware name: Broadcom-v8A (DT)
Sep 27 10:44:01 RT-AC86U kernel: task: ffffffc01702eb40 ti: ffffffc0138ec000 task.ti: ffffffc0138ec000
Sep 27 10:44:01 RT-AC86U kernel: PC is at 0x7f77e50ee4
Sep 27 10:44:01 RT-AC86U kernel: LR is at 0x7f77d683a4
Sep 27 10:44:01 RT-AC86U kernel: pc : [<0000007f77e50ee4>] lr : [<0000007f77d683a4>] pstate: 20000000
Sep 27 10:44:01 RT-AC86U kernel: sp : 0000007ff34ba620
Sep 27 10:44:01 RT-AC86U kernel: x29: 0000007ff34ba620 x28: 0000000000000003
Sep 27 10:44:01 RT-AC86U kernel: x27: 0000000000000000 x26: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x25: 0000000000000000 x24: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x23: 0000000000000100 x22: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x21: 0000007f77d8663c x20: 000000000a24acf0
Sep 27 10:44:01 RT-AC86U kernel: x19: 0000007f77d86000 x18: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x17: 00000000004311d8 x16: 0000007f7821a340
Sep 27 10:44:01 RT-AC86U kernel: x15: 081a171b01000000 x14: 00121edf7c000000
Sep 27 10:44:02 RT-AC86U kernel: x13: 0000000000000000 x12: 000000000000001f
Sep 27 10:44:02 RT-AC86U kernel: x11: 0101010101010101 x10: 0000000000000006
Sep 27 10:44:02 RT-AC86U kernel: x9 : 7f7f7f7f7f7fffff x8 : 00000000000001a9
Sep 27 10:44:02 RT-AC86U kernel: x7 : 000000011b171a08 x6 : 000000011b171a08
Sep 27 10:44:02 RT-AC86U kernel: x5 : 000000011b171a08 x4 : 081a171b01000000
Sep 27 10:44:02 RT-AC86U kernel: x3 : 0000000000000000 x2 : 0000007f77e50ec0
Sep 27 10:44:02 RT-AC86U kernel: x1 : 0000007ff34ba698 x0 : 0000000000000100
Sep 27 10:44:02 RT-AC86U kernel:

 

[ColinTaylor]

dig command causes error in the log:

Spoiler: Log

Sep 27 10:44:01 RT-AC86U kernel: dig[17548]: syscall 425
Sep 27 10:44:01 RT-AC86U kernel: Code: aa0503e4 aa0603e5 aa0703e6 d4000001 (b13ffc1f)
Sep 27 10:44:01 RT-AC86U kernel: CPU: 0 PID: 17548 Comm: dig Tainted: P O 4.1.27 #2
Sep 27 10:44:01 RT-AC86U kernel: Hardware name: Broadcom-v8A (DT)
Sep 27 10:44:01 RT-AC86U kernel: task: ffffffc01702eb40 ti: ffffffc0138ec000 task.ti: ffffffc0138ec000
Sep 27 10:44:01 RT-AC86U kernel: PC is at 0x7f77e50ee4
Sep 27 10:44:01 RT-AC86U kernel: LR is at 0x7f77d683a4
Sep 27 10:44:01 RT-AC86U kernel: pc : [<0000007f77e50ee4>] lr : [<0000007f77d683a4>] pstate: 20000000
Sep 27 10:44:01 RT-AC86U kernel: sp : 0000007ff34ba620
Sep 27 10:44:01 RT-AC86U kernel: x29: 0000007ff34ba620 x28: 0000000000000003
Sep 27 10:44:01 RT-AC86U kernel: x27: 0000000000000000 x26: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x25: 0000000000000000 x24: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x23: 0000000000000100 x22: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x21: 0000007f77d8663c x20: 000000000a24acf0
Sep 27 10:44:01 RT-AC86U kernel: x19: 0000007f77d86000 x18: 0000000000000000
Sep 27 10:44:01 RT-AC86U kernel: x17: 00000000004311d8 x16: 0000007f7821a340
Sep 27 10:44:01 RT-AC86U kernel: x15: 081a171b01000000 x14: 00121edf7c000000
Sep 27 10:44:02 RT-AC86U kernel: x13: 0000000000000000 x12: 000000000000001f
Sep 27 10:44:02 RT-AC86U kernel: x11: 0101010101010101 x10: 0000000000000006
Sep 27 10:44:02 RT-AC86U kernel: x9 : 7f7f7f7f7f7fffff x8 : 00000000000001a9
Sep 27 10:44:02 RT-AC86U kernel: x7 : 000000011b171a08 x6 : 000000011b171a08
Sep 27 10:44:02 RT-AC86U kernel: x5 : 000000011b171a08 x4 : 081a171b01000000
Sep 27 10:44:02 RT-AC86U kernel: x3 : 0000000000000000 x2 : 0000007f77e50ec0
Sep 27 10:44:02 RT-AC86U kernel: x1 : 0000007ff34ba698 x0 : 0000000000000100
Sep 27 10:44:02 RT-AC86U kernel:

Entware - dig can not run in 386.12

i installed bind-dig from Entware, when i run dig in terminal, i got this netmgr/uverr2result.c:101:isc___nm_uverr2result(): unable to convert libuv error code in udp_send_cb (netmgr/udp.c:802) to isc_result: -38: function not implemented what wrong with this?

www.snbforums.com

 

[The Chief]

Entware - dig can not run in 386.12

i installed bind-dig from Entware, when i run dig in terminal, i got this netmgr/uverr2result.c:101:isc___nm_uverr2result(): unable to convert libuv error code in udp_send_cb (netmgr/udp.c:802) to isc_result: -38: function not implemented what wrong with this?

www.snbforums.com

Nah, does not fix error in my case.

 

[dave14305]

Nah, does not fix error in my case.

The republished Entware package was only for routers on Linux 2.6. The AC86U is on 4.1.27.

 

[Sonyrolfy]

Nah, does not fix error in my case.

Try the other-way around.

opkg update
opkg remove libuv  --force-depends
opkg install libuv

Then ->

remove --force-depends bind-dig
opkg install --force-depends bind-dig

reboot

 

[macciavelli]

Hi,

Has anyone had a case where wifi would come up with a default password ("asuswifi0123") after installing 386.12?
I bought a used AC3100 on eBay and installed 368.12 right away and wifi came up with this password. I tried resetting through GUI and WPS, but the password is still there.

First I assumed something wrong with 386.12 for AC3100, because
1. I already have 386.12 on AC86 and AC68 without any default passwords
2. Installing 386.11 on the AC3100 removed the default password and wifi comes up unprotected, as on other Asus routers with Merlin firmware
3. Reinstalling a freshly downloaded 386.12 sets the password back and reverting back to 386.11 again removes the password.

But googling "asuswifi0123" showed cases from 2021 and 2022 mentioning this password in "nvram show" dumps.

https://4pda.to/forum/index.php?showtopic=807011&st=2300

DD-WRT :: View topic - [SOLVED] RT-AC88U Bricked ( Boot-Looping_

And a very recent case with an AC88U, right here on SNB: https://www.snbforums.com/threads/what-is-the-default-ssid-password-for-asus_48_2g.86830/page-2

So, now I don't know why there is a password on 386.12 and no password on 386.11.

Any ideas?


edit: attaching nvram dump