Release Asuswrt-Merlin 386.2 is now available

[ShagBark]

RT-AX88U dirty update. Only non-issue is I lost some of my custom device icons. I didn't like some of the icons anyway
Appreciate it Merlin... its time for CAKE!

 

[cowst]

Hi, I am having problems to update from 386.1_2.
Every time I go to the Firmware Upgrade tab, it automatically starts the Firmware Downloading... and gets stuck there.
It is the first time that I see it possible to do automatic updates (I was waiting for that feature).
I tried on Brave and Chrome and they behave the same.
I even checked if the package download takes long for some server issue, but I get it in less than 10 seconds, so speed is not the issue.
Any ideas?

After rebooting twice, it stopped taking initiatives and I could update it manually as usual.
Meh

 

[Volfi]

Seems to me less stable on AC86U than previous 386.1_2 release. 2.4GHz Wifi is slower and after 1 week stopped accepting new connections. Reboot solved that, but as I need to rely on router running for 1 month without any problems, 386.2 is not usable right now

 

[gspannu]

Ah, I was afraid to be alone with this problem!

It seems that you can ping the devices from the LAN to the GNs but you can't ping the LAN from the devices in the GNs.
It also seems that the devices in the GNs can't ping each other (as if the AP was isolated).
Usually to get this result you have to install YazFI.

What is the problem?

As long as the devices in GN cannot ping or see anything on the LAN; then this is the expected behaviour.

As I was able to ping GN devices from LAN; I was concerned that the GN devices are not really isolated.

Working as expected and (as you have stated) without the need for YazFi. Great work @Merlin

 

[Matthew Patrick]

Seems to me less stable on AC86U than previous 386.1_2 release. 2.4GHz Wifi is slower and after 1 week stopped accepting new connections. Reboot solved that, but as I need to rely on router running for 1 month without any problems, 386.2 is not usable right now

For me it's the exact opposite. On 386 beta and 386.1 stable. My 2.4ghz drops like crazy every few hours. It's not even funny... Full WPS reset, software reset, jffs reset. Doesn't fix a thing... 386.2 beta fixes it with the new GPL. and now it's been 9 days and it's basically been the best firmware since 384.18 (384.19 has this nasty memory leak where it would slowly take ram and swap so much that it lags the whole router and reboots it)

 

[Jack Yaz]

As long as the devices in GN cannot ping or see anything on the LAN; then this is the expected behaviour.

As I was able to ping GN devices from LAN; I was concerned that the GN devices are not really isolated.

Working as expected and (as you have stated) without the need for YazFi. Great work @Merlin

i wonder if Asus have been dipping into my code ;-)
they're welcome to after all, it is GPL'd

 

[Howard_inGA]

This release is the bomb!!
7 days 18 hour(s) 51 minute(s) Uptime without a hitch...
Thanks to Eric for running the problems to ground!

 

[MarcoPolo]

As long as the devices in GN cannot ping or see anything on the LAN; then this is the expected behaviour.

As I was able to ping GN devices from LAN; I was concerned that the GN devices are not really isolated.

Working as expected and (as you have stated) without the need for YazFi. Great work @Merlin

ok, why not.
But now, ping your devices from LAN to GN (it's supposed to work) and go change a parameter in the Wireless section (for example: control channel), apply the parameters and wait for the devices to reconnect to Wifi. Then look at your ping: the devices are not reachable anymore...

Not exactly like YazFI...

 

[Ubimo]

I have an AC86U.

I'm using Cloudflare WARP via wireguard and when downloading large files (138GB), I see this in syslog:

Spoiler: syslog

Apr 10 21:24:38 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_blog_process,789: blog allocation failure^[[0m
Apr 10 21:24:38 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_blog_process,789: blog allocation failure^[[0m
Apr 10 21:24:55 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_blog_process,789: blog allocation failure^[[0m
Apr 10 21:24:55 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_blog_process,789: blog allocation failure^[[0m
Apr 10 21:25:15 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_blog_process,789: blog allocation failure^[[0m
Apr 10 21:25:15 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_blog_process,789: blog allocation failure^[[0m
Apr 10 21:40:16 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x1
Apr 10 21:40:16 kernel: bcm63xx_nand ff801800.nand: intfc status f80000e0
Apr 10 21:40:32 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x4
Apr 10 21:40:32 kernel: bcm63xx_nand ff801800.nand: intfc status c80000e0
Apr 10 21:45:41 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x1
Apr 10 21:45:41 kernel: bcm63xx_nand ff801800.nand: intfc status f80000e0
Apr 10 21:46:27 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x4
Apr 10 21:46:27 kernel: bcm63xx_nand ff801800.nand: intfc status c80000e0

What does this mean?

Edit:
And when downloading at high speeds (30MB/s), the GUI becomes unresponsive. I cannot access the GUI anymore.
This becomes the adress line in Chrome:

http://192.168.1.1/error_page.htm?flag=9

 

[djbrad]

Happy to report no more CPU stuck / rc_service: check_watchdog 329:notify_rc restart_watchdog loop after a week on my RT-AC66U-B1.

I formated the jffs at next boot as recommended and is stable since.

Thank you Merlin and everyone.

 

[Ubimo]

On github I see @RMerlin bumped revision to 386.2_1 four days ago, but I cannot find any download.

 

[Deleted member 22229]

On github I see @RMerlin bumped revision to 386.2_1 four days ago, but I cannot find any download.

He has not released it.

 

[SheikhSheikha]

Dirty upgrade -> smooth!

 

[RMerlin]

As long as I don't access Adaptor QoS page, the router is working fine.

Any suggestion to avoid this?

Can't reproduce. I recommend doing a factory default reset and reconfiguring your router.

 

[panhead20]

Reconfigured printer to correct error

 

[Jerrah]

RT-86U. I was previously using 381.xx and I’ve been running Merlin for years. I upgraded using manual upgrade from the sourceforge download and now I’m unable to log into my router.

The router boots up, I get internet access and wifi. If I try to access the WebGUI I can enter my login details and it appears to authenticate then I get a blank webpage which never seems to complete loading. SSH is disabled.

Is the only option to try to factory rest/flash the router? Has anyone else had issues logging in after an upgrade? I don’t really want to lose my extensive config (which I haven’t backed up) if I can help it...

 

[banger]

RT-86U. I was previously using 381.xx and I’ve been running Merlin for years. I upgraded using manual upgrade from the sourceforge download and now I’m unable to log into my router.

The router boots up, I get internet access and wifi. If I try to access the WebGUI I can enter my login details and it appears to authenticate then I get a blank webpage which never seems to complete loading. SSH is disabled.

Is the only option to try to factory rest/flash the router? Has anyone else had issues logging in after an upgrade? I don’t really want to lose my extensive config (which I haven’t backed up) if I can help it...

Give it an hour then try again, or use the IP address.

 

[Centrifuge]

RT-86U. I was previously using 381.xx

That's some dated firmware.

Merlin posts a changelog for his firmware, really interesting reading:

- NOTE: Some users upgrading might have to go through some
database maintenance on first boot, which means the
router might be slower or have a non-responsive webui
for a while.
This can take anywhere from 5 minutes up to an hour,
depending on your model, just give it time to complete
the process.

 

[Wisiwyg]

Is the only option to try to factory rest/flash the router? Has anyone else had issues logging in after an upgrade? I don’t really want to lose my extensive config (which I haven’t backed up) if I can help it...

In addition to all of the other recommendations above, if you didn't perform a reset, then yes, you should perform a backup (really nice AMTM script to do this from SSH & command line), perform factory reset, then restore. If at all possible, restore everything by hand instead. If things go south you may have to do this anyway. This assumes that you've waited a day or so and have been able to get to the GUI indicating things have settled down and that you've been able to enable SSH. Good Luck!

 

[StR]

The issue seem to be specific to HND models. It's probably caused by the closed source nvram validation that is part of HND models, and since Asus's closed source portion is compiled without Tor support, then this variable gets lost on reboots (as the nvram version is out of sync with the jffs version).

Not sure how I can resolve this without resorting to a dirty hack. You're the first person to report this in all the years since I introduced support for the first HND model, which shows how little used Tor is.

I am using Tor on RT-AC86U, but not constantly, just for periods of time, enabling it every so often, but not daily. I didn't have a chance to update to 386.2 yet, but it was very recently (in late March) that I updated from 384.19 to 386.1_2.

With 384.19, I was using Tor - for just one Mac address, and when I was switching from "enable" to "disable", the specific Mac address was preserved (as well as through reboots). Upon updating to 386.1_2, I've found that this Mac address was lost in the settings. I haven't used the Tor since the that, so, I didn't have a chance to check how it works.

So, I am guessing the difference was introduced somewhere in 386, right?