Beta Asuswrt-Merlin 386.4 beta is now available

[guho]

My AX86U got into a bootloop after dirty upgrade from 386.4beta2 to 386.4beta3. Fortunately I had settings and jffs backups. So after a reset followed by restore it is back to normal again. Thanks RMerlin for this new beta.

 

[kernol]

Your issue seems to be related to Let's Encrypt trying to update the DDNS entry (it needs to push a validation value to Asus's DNS server for validation purposes). Might be possible that this portion of the code isn't working properly at this time.

That might explain why it worked for my test setup - no Let's Encrypt on it (and testing that would be difficult, since to be able to test anything related to IPv6 I have to put the test router in a dual NAT setup behind a Linux router that handles IPv6 PD.).

I'm disabling IPv6 support for now. Hardly worth delaying this release by weeks for a new feature that has very limited usefulness at this time.

Fully agree - I was simply testing the beta2 on IPv6 having seen others having issues.
I personally do not make use of IPv6 on my home router.

The setup AiMesh node problem after reset does need fixing by Asus though - several models affected according to this thread.
It's not an issue if you arrive at beta2 with AiMesh setup previously [dirty upgrade] - but in trouble if you factory reset and try to build AiMesh from scratch. Thnx.

EDIT - addition: I can confirm your solution of disabling IPv6 in DDNS routine has resolved the issue.
IPv6 can now be enabled and DDNS via Asus with its Lets Encrypt enabled and works under IPv4.
IPv6 seems fully functional in all other respects as far as I can tell. All good {ThumbsUp}.

 

[porfavorhelp]

Asuswrt-Merlin 386.4 is now available for all supported models. This release merges with GPL 386_45958, and adds support for the RT-AX86S.

Dec 28th update: Updated to Beta 3. Changes since Beta 2:

9288cd8c05 Updated documentation
8c0194de99 inadyn: rc: disable IPv6 support
0ae53e9cd8 rc: harmonized with upstream
969b828b98 busybox: enable hexdump applet
cf0307f1d2 rc: add missing chain to ip6tables's filter table
797f3e4ba9 httpd: webui: improve parameter sanitization (backport from Asus upstream)
f672e3199a Bumped to beta 3

Dec 22nd update:: Updated to Beta 2. Changes since Beta 1:

shared: improved buffer validation (backport from Asus upstream)
bcbd5e494b shared: Replace the source code of strlcpy() and strlcat() by BSD verison (patch from Asus upstream)
8247d74c37 rc: ensure that do_dns_detect() always has a valid test server even if nvram is empty
77917ed54c rc: also add static lease hostnames without domain appended to host file
0b69989b80 rc: start miniupnpd after getrealip has run, and give it an extra 5 secs in case it's not ready yet
abe3f8f883 httpd: also fix potential NULL ptr access in do_vpnupload_post() (patch from upstream)
c02ac3af36 Updated documentation
49b788dd06 Merge pull request #796 from decoderman/master
da11794861 build: fix et userspace tool copy on SDK 6.37
15ccb9cbfb amtm 3.2.1 release, preparation for IOS Shortcuts
03c9fdcf06 httpd: fix potential use of uninitialized variable in do_vpnupload_post(), introduced in 6ce76323bf
71732c5a66 rc: reapply firewall-start rules after stop_ddns() restores them from filter_rules
1c5a36e089 openvpn: updated to 2.5.5
6ce76323bf httpd: improved buffer validation (backport from Asus upstream)
8d40f2c18a ddns: backport patches from Asus upstream
c09e1fae34 inadyn: revert ddns.c fix
e2243b0df9 openssl: updated to 1.1.1m
d167e13d6b Bumped revision to beta 2

There has been a long gap between these last releases due to licensing issues Asus had to resolve with the generated GPL archives. There are still a few remaining issues that are currently forcing me to delay support for the RT-AC68U_V4 and GT-AXE11000, these will need to be revisited once their respective GPL archives are fixed by Asus and Broadcom.

The highlights of this release;

• Merges with GPL 386_45958.
• Adds support for the RT-AX86S (uses the same firmware as the RT-AX86U).
• HND firmwares now include both the kernel module and userspace tool for Wireguard. There is no built-in support for Wireguard at this time, these are only included for end-user or third party usage. Asus is still working on their own implementation, which isn't available yet.
• OpenVPN server now supports IPv6, both for incoming connections, and for routing access to the LAN clients over IPv6. Note however that redirecting IPv6 Internet traffic through your server is not supported.
• Component updates: curl 7.79.1, vsftpd to 3.0.5, openssl to 1.1.1m, wget to 1.21.1, nettle to 3.7.3, dnsmasq 2.86, openvpn 2.5.5, tor 0.4.5.11, miniupnpd 2.2.3-git 20211017 and inadyn 2.9.1
• jitterentropy-rngd was replaced by haveged. Haveged is more resource-intensive, but it works properly under older 2.6.x kernels.
• dnsmasq was reverted back to using nettle for its DNSSEC crypto handling (since openssl support never got mainlined and was increasingly problematic to support)
• miniupnpd now uses the real public IP address instead of any potentially (double-)NATed address for the WAN.
• Reworked DHCP hostname support to use Asus's own implementation.
• A couple of various bugfixes

Please review the Changelog for complete details.

Notes:

• 386.4 uses the new DHCP hostname implementation from Asus (your entries will automatically be converted to the new format on first boot). This means however that reverting to a previous firmware version will lose all of your defined static lease hostnames.

Things that needs particular testing and feedback:

• OpenVPN server IPv6 support. I was only able to do limited testing using an HE tunnel.

Please keep posts in this thread on this specific release.

Downloads are here.
Changelog is here.

Hi RMerlin I found some bugs
1) Trend Micro: Signature version can not be update. It's says "Signature update failed"
2) GT-AX11000 Firmware 386.3_2 Aicloud not working. When I make a USB to USB sync it does not work or other type of FTP sync too. It stay in "WAITING". Help please

 

[saleanddeki]

AX56U, dirty upgrade from 386.4 beta 2 to 386.4 beta 3, no problems.
Thanks RMerlin

 

[RMerlin]

Trend Micro: Signature version can not be update. It's says "Signature update failed"

Not a bug. The files are missing on Asus's server due to an incomplete update that they published, it will resolve itself once they add the missing files.

GT-AX11000 Firmware 386.3_2 Aicloud not working. When I make a USB to USB sync it does not work or other type of FTP sync too. It stay in "WAITING". Help please

I haven't looked at AiCloud in over 5 years, since it's a) not really secure, b) closed source and out of my control. I'm simply merging the Asus components as they are.

 

[RMerlin]

Asus should not attempt to leap their IPV6 functionality until they learn to crawl it first. There is a lot lacking under the ASUSwrt-hood that needs implemented or enabled in regards to Asuswrt having an effective modern ipv6 implementation, but it would require Asuswrt devs to over-hall a lot of the internals. In this regard it is completely understandable why you have disabled their broken logic.

There is a reason why global IPv6 deployment is taking forever (13 years now and still counting). I always said that IPv6 was over-engineered, often attempting to provide solutions in need of problems to address. Implementing "complete" IPv6 support in a router is a nightmare, between ISPs having all kind of broken (Comcast's broadcast floods), clunky (6rd), or esoteric (V6Plus in Japan) implementations.

In any case, the issue here is with the DDNS support (and probably more specifically the acme.sh plugin used to push validation data to asusddns), not the IPv6 WAN implementation itself, which works.

 

[saleanddeki]

@RMerlin
Now i tried AiCloud, "Cloud Disk" function, working very well on AX56U.

 

[RMerlin]

@RMerlin
Now i tried AiCloud, "Cloud Disk" function, working very well on AX56U.

Thanks. Cloud Disk is a separate feature from AiCloud Sync tho (and each cloud sync method uses a separate closed source client based on the sync protocol).

 

[doodlenoodle]

Updated my AX86U directly from 386.4 Beta 2 to 386.4 Beta 3 and update was seamless. All wired, wireless, and vpn clients connected. Everything seems to be holding steady.

 

[Zastoff]

Updated my AX86U directly from 386.4 Beta 2 to 386.4 Beta 3 and update was seamless. All wired, wireless, and vpn clients connected. Everything seems to be holding steady.

Same here on my ax88U
Thanks RMerlin

 

[FLA_NL]

Did a dirty upgrade from 386.4_beta2 to 386.4_beta3. Don't see any issues.

 

[octopus]

Security-related rules Asuswrt adds. I was keeping these disabled until now, I decided to re-enable them because I don't know which other private rules may also be added by these closed source functions (I'm aware that at least in the past there were a few related to Zen Wifi models).

Thank you for new beta firmware.

Is there any explanation what new rules looking for ? What I can see only one chain get traffic (packet counter) all others are empty right now.

Chain OUTPUT (policy ACCEPT 74815 packets, 60M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2715  170K OUTPUT_DNS  udp  --  any    any     anywhere             anywhere             udp dpt:domain u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0"
    0     0 OUTPUT_DNS  tcp  --  any    any     anywhere             anywhere             tcp dpt:domain u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0"
 769K  580M OUTPUT_IP  all  --  any    any     anywhere             anywhere

 

[RogerSC]

Flashed Beta3 on RT-AX86U on top of the latest Asus firmware, working perfectly so far. Also did a reset and reconfigured manually after that. Happy that the QoS bandwidth limiter is working, helping me to keep Prime Video streamed data traffic under control. Nice. As a result, HW acceleration is disabled, but has no impact on throughput, since we went from gigabit fiber to 300/300 recently. Don't need gigabit internet, and AT&T finally let me downgrade. Saves some money, that doesn't hurt either *smile*.

 

[John Fitzgerald]

That typically indicates an invalid character in a device name, or a corrupted stored setting.

On the alpha's and last two beta's the icons and name (manually assigned) were lost.
These were simple names, iPad & iPhone and the icons were stock icons provided by ASUS.
The names reverted to MAC ID's and the icons reverted to the very first icon in the list (upper left corner one).

This Beta 3, they stayed intact, so far.

AND Thank You.

 

[maxbraketorque]

With 386.4 (and possibly earlier versions), I have lost the ability to apply updates remotely. Applying an update remotely using OVPN or https does not work for an AX68U. Rebooting prior to trying the update does not help. This is a very minimal configuration. No USB HDDs. No Trend Micro. No add-on packages. Only an OVPN server. I have a remote AC86U and AC68U that I have yet to try.

 

[SomeWhereOverTheRainBow]

Fully agree - I was simply testing the beta2 on IPv6 having seen others having issues.
I personally do not make use of IPv6 on my home router.

The setup AiMesh node problem after reset does need fixing by Asus though - several models affected according to this thread.
It's not an issue if you arrive at beta2 with AiMesh setup previously [dirty upgrade] - but in trouble if you factory reset and try to build AiMesh from scratch. Thnx.

EDIT - addition: I can confirm your solution of disabling IPv6 in DDNS routine has resolved the issue.
IPv6 can now be enabled and DDNS via Asus with its Lets Encrypt enabled and works under IPv4.
IPv6 seems fully functional in all other respects as far as I can tell. All good {ThumbsUp}.

Do you know the full level of troubleshooting conducted while trying to readd nodes after factory reset? I am assuming the users factory resetted the nodes as well before attempting to repair them?

 

[JGrana]

With 386.4 (and possibly earlier versions), I have lost the ability to apply updates remotely. Applying an update remotely using OVPN or https does not work for an AX68U. Rebooting prior to trying the update does not help. This is a very minimal configuration. No USB HDDs. No Trend Micro. No add-on packages. Only an OVPN server. I have a remote AC86U and AC68U that I have yet to try.

I had the same experience trying to remotely update an AX86U. Did the same reboot before, unmounted USB drive, etc.
It never reaches the part showing the % graph.
Luckily the remote router comes back online (with older fw).

I know remote updates can be dangerous. I do have one of those LAN power plugs that will power cycle the router if it doesn't get a ping response from 2 different sources.

 

[maxbraketorque]

I had the same experience trying to remotely update an AX86U. Did the same reboot before, unmounted USB drive, etc.
It never reaches the part showing the % graph.
Luckily the remote router comes back online (with older fw).

I know remote updates can be dangerous. I do have one of those LAN power plugs that will power cycle the router if it doesn't get a ping response from 2 different sources.

Good to know that I'm not the only person. I'm curious to hear from @L&LD . I think he does quite a bit of remote updating.

 

[STRUZZIN]

Everything updated to BETA 3 and working great.
Thanks

 

[torstein]

There is no built-in support for Wireguard at this time, these are only included for end-user or third party usage. Asus is still working on their own implementation, which isn't available yet.

What does "end-user or third party usage" mean? Isn't that us, basically? ie I am an end-user and I set it up with say Mullvad VPN (third party usage)? Forgive me if this is obvious to all of you.

Or does 386.4 just lay the groundwork for future Wireguard server and client for regular users such as me?