Release Asuswrt-Merlin 386.5 is now available

[Jings]

Dirty upgrade from 386.3.2 on my RT-AC86U, and I'm unable to get a DHCP IP addresses from my ISP on any of the 386.5.x versions. Aka "Your ISP's DHCP does not function properly."
Downgrading to 386.3.2 or 386.4 solves the problem, and everything starts working again. I've looked at the DEBUG logs, and I can't find anything obvious. I see that a few " MTD partitions" have swapped places example "image" & "image-update", but that might be normal for an upgrade?

I've got quite a complex setup, so I guess the next step is to factory reset everything, and if it works, start adding back stuff, until it breaks, If not anyone have any suggestions?

 

[JGrana]

Ah, thanks for your clarification. I had a mixed success with wgm and would like to wait for the wg ASUS UI port to arrive in Merlin.

IMHO, the latest wg_manager is working quite well. I am running both a site-2-site wg tunnel and have a few mobile peers that can connect to wireguard running on my AX88U. The site-2-site is an AX88U <-> AX86U. I also have 2 AI Mesh nodes off the AC88U.
All running stable. It has come a long way since its first thread. Here is the follow on:

Wireguard - Session Manager - Discussion (2nd) thread

This thread http://www.snbforums.com/threads/session-manager.70787/ has now expired. Thanks for the heads-up SNB Forum member @Ubimo

www.snbforums.com

 

[JGrana]

I should also mention that compared to all the knobs and settings needed/available with OpenVPN, wireguard is far simpler. I have run both. I can tell you, wireguard is very easy to get running (with wg_manager and it’s iptables settings) and is quite a bit faster than OpenVPN.
If you like to tweak/tune/experiment - stay with OpenVPN. If you want faster, as much if not more secure and easy - try wireguard.

From the benevolent leader of Linux:

Date: Thu, 2 Aug 2018 10:15:40 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Miller <davem@...emloft.net>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Network Development <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT] Networking

On Wed, Aug 1, 2018 at 9:37 PM David Miller <davem@...emloft.net> wrote:
>
> Fixes keep trickling in:

Pulled.

Btw, on an unrelated issue: I see that Jason actually made the pull
request to have wireguard included in the kernel.

Can I just once again state my love for it and hope it gets merged
soon? Maybe the code isn't perfect, but I've skimmed it, and compared
to the horrors that are OpenVPN and IPSec, it's a work of art.

Linus

 

[Jings]

Dirty upgrade from 386.3.2 on my RT-AC86U, and I'm unable to get a DHCP IP addresses from my ISP on any of the 386.5.x versions. Aka "Your ISP's DHCP does not function properly."
Downgrading to 386.3.2 or 386.4 solves the problem, and everything starts working again. I've looked at the DEBUG logs, and I can't find anything obvious. I see that a few " MTD partitions" have swapped places example "image" & "image-update", but that might be normal for an upgrade?

I've got quite a complex setup, so I guess the next step is to factory reset everything, and if it works, start adding back stuff, until it breaks, If not anyone have any suggestions?

A factory reset gave me a DHCP IP from my ISP on FW version 386.5.2! Restored the nvram setting with backup script, and the problem was back.
Factory reset again, and restored block by block, with reboots in-between, until it failed at "IPTV Settings". Factory reset again, and did line-by-line until it failed on "nvram set switch_wan0tagid="102".
This is a setting from an old ISP, from a very long time ago. IPTV settings is currently turned off, and the tagid is not exposed in the GUI. Previous FW versions just ignores it, if IPTV is off, but 386.5.x uses it. Setting switch_wan0tagid to "0" fixed my problem.

I guess I've learned to always follow "best practice" and do a factory reset when upgrading...
...or be prepared to spend a couple of hours to diagnose the problem..

 

[Morris]

A factory reset gave me a DHCP IP from my ISP on FW version 386.5.2! Restored the nvram setting with backup script, and the problem was back.
Factory reset again, and restored block by block, with reboots in-between, until it failed at "IPTV Settings". Factory reset again, and did line-by-line until it failed on "nvram set switch_wan0tagid="102".
This is a setting from an old ISP, from a very long time ago. IPTV settings is currently turned off, and the tagid is not exposed in the GUI. Previous FW versions just ignores it, if IPTV is off, but 386.5.x uses it. Setting switch_wan0tagid to "0" fixed my problem.

I guess I've learned to always follow "best practice" and do a factory reset when upgrading...
...or be prepared to spend a couple of hours to diagnose the problem..

I'm glad you found the problem. I don't feel a factory reset for every upgrade is needed or even wise yet when having odd problems, doing as you did is the way to get to the bottom of things.

 

[sporadically]

RT-AC3100: Dirty upgrade from 386.5 to 386.5_2, all is well! Thank you!

 

[drinkingbird]

A factory reset gave me a DHCP IP from my ISP on FW version 386.5.2! Restored the nvram setting with backup script, and the problem was back.
Factory reset again, and restored block by block, with reboots in-between, until it failed at "IPTV Settings". Factory reset again, and did line-by-line until it failed on "nvram set switch_wan0tagid="102".
This is a setting from an old ISP, from a very long time ago. IPTV settings is currently turned off, and the tagid is not exposed in the GUI. Previous FW versions just ignores it, if IPTV is off, but 386.5.x uses it. Setting switch_wan0tagid to "0" fixed my problem.

I guess I've learned to always follow "best practice" and do a factory reset when upgrading...
...or be prepared to spend a couple of hours to diagnose the problem..

Yeah generally speaking, never restore from backup unless you are using the same firmware (even then, if something was messed up enough to make you restore, you wouldn't want to re-apply it).

 

[Kendo]

Great news, thank you.

 

[ottofreud]

Not that this has anything to do with the new firmware, but about 6 hours after upgrade, I started getting these

kernel: jffs2: Error garbage collecting node at 00aaaf54!
kernel: jffs2: Error garbage collecting node at 00aaaf54!
kernel: jffs2: read_cache_page() returned error: -5

Rebooting seems to have cleared the situation. I was just wondering what causes this. Never seen this before

Thanks and sorry if this is the wrong forum

 

[ColinTaylor]

Not that this has anything to do with the new firmware, ...

Then why post in this thread?

Please keep discussions in this thread on this specific release. General support requests should be posted in a separate thread.

This thread will be locked once the post-release feedback has quieted down.

 

[Igor-KC]

Smooth update here, everything working perfectly. Thank You RMerlin!
3 days 1 hour(s) 42 minute(s) 56 seconds

 

[DarkKnight75]

3+days smooth sailing on my AC86U...

 

[Natty]

Manual dirty update from 386.5 to 386.5_2 (keeping same settings) working nicely on RT-AC66U-B1. Thanks RMerlin.

 

[Gar]

Working great on AX58 with simple config...thanks again.

 

[Underskore]

Anyone else having port forwarding randomly drop out for a bit and then go back to working?

 

[maxbraketorque]

Anyone else having port forwarding randomly drop out for a bit and then go back to working?

I've got several ports open, and nope.

 

[Gary_Dexter]

Getting a lot of these errors several times a day now since upgrading from 386.5 to 386.5_2

Mar 29 18:24:18 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x1
Mar 29 18:24:18 kernel: bcm63xx_nand ff801800.nand: intfc status f80000e0
Mar 29 19:34:07 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x4
Mar 29 19:34:07 kernel: bcm63xx_nand ff801800.nand: intfc status c80000e0

Also the router has rebooted itself on several occasions as well and there's no heavy load on the router or any add-ons installed/running.

GT-AC2900.

 

[Ayitaka]

AX86U - Dirty upgrades 386.4 -> 386.5 -> 386.5_2 up and running for 2+ days, no problems.

Thanks again for all the work you put into this project!

 

[ColinTaylor]

386.5_2 working as before since the day it was released.

Only one problem which was also present in 386.4 and 386.5 and that's that acsd doesn't work. Worked fine in stock firmware back in July 2021.

Beta - Asuswrt-Merlin 386.5 Beta is now available

acsd2 doesn't appear to be working. Same problem was present in 386.4. I was hoping the change to model specific versions might have changed this but it hasn't. (I've only tested this on 2.4GHz) In the past there were obvious messages (APCS_CSTIMER) in the syslog every 15 minutes when acsd2 was...

www.snbforums.com

 

[Underskore]

I've got several ports open, and nope.

Welp, I guess it might be factory reset time on my side. the other devices has the mac filter giving it a static ip, I've also given it a static ip and it still fails randomly. (It seems like the rest of my port forwarding isn't dying)