Release Asuswrt-Merlin 386.2 is now available

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.
Status
Not open for further replies.

RMerlin

Asuswrt-Merlin dev
Update (30-Apr-2021): 386.2_4 is now available, updating OpenVPN and with a few minor changes.
Update (13-Apr-2021): 386.2_2 is now available, addressing a few minor issues.

Asuswrt-Merlin 386.2 is now available for all supported models. This release introduces support for the GT-AX11000 and the RT-AX68U, and also adds a new QoS mode based on the Cake packet scheduler.

The highlights:
  • Merged with GPL 386_42095
  • Added support for the RT-AX68U and GT-AX11000 (VPN Fusion and other ROG-only features not supported).
  • Added Cake to the list of QoS modes. This is only available on HND models (RT-AC86U or newer), and will also disable NAT acceleration, so it can't be used if you have a fast Internet connection (300-350 Mbps is probably the max speed possible on an RT-AX88U). See below for more details.
  • Updated components: OpenVPN (2.5.1), OpenSSL (1.1.1k), iproute2 (5.11.0, HND models only).
  • Added jitterentropy-rngd to HND models all models since 386.2_4, to improve entropy for cryptographic use (SSL key generation, etc...)

Please see the Changelog for the details.


Cake:
Cake is a queue scheduler used by Linux to manage how packets are received/sent over the Internet. More intelligent management can greatly improve the user experience by ensuring that a large data stream (like a large download) will not impact smaller streams that are more timing-sensitive, like VoIP.

See https://www.bufferbloat.net/projects/codel/wiki/Cake/ for more info on Cake.

Cake is only available for kernels 4.1.xx, so that means the RT-AC86U and newer models, who are based on Broadcom's HND platform. It is also not compatible with NAT acceleration, just like Traditionnal QoS, so that means it cannot be used on Internet connections faster than around 300-350 Mbps (that limit may vary based on the router model and the amount of traffic).

The current implementation uses a diffserv3 queuing scheme for uploads (meaning that services like VoIP can get higher priority), and a single besteffort queue for download (as priority mapping of traffic coming from the Internet cannot be relied upon). On startup, Cake QoS will create two files:
  • /etc/cake-qos.conf, which contains the variables with parameters
  • /tmp/qos, which is the script that sets/removes the tc rules, based on the parameters retrieved from cake-qos.conf

cake-qos.conf can be overridden through the use of a /jffs/configs/cake-qos.conf.add file, which will be appended at the end of it. If you define any variable in the .add file, these will replace the values already defined in the router-generated cake-qos.conf.

You can also use the qos-start script that gets run before the /tmp/qos script to completely replace /tmp/qos with your own script, for more advanced customization of your Cake setup.

Make sure you configure the correct overhead when enabling Cake QoS, by selecting a preset from the list (by click on the red arrow). Selecting a preset will automatically configure the appropriate overhead, PMU and mode. If unsure, then select the Conservative option as a general safe value.

For upload/download, I recommend setting these to roughly 95% of your maximum speed. Setting it to "Automatic" will configure Cake for "unlimited bandwidth", which is generally not optimal.

A few additional notes for developers:
  • The rc_support feature list will contain "cake" on models that supports it.
  • The new iproute2 available on these same models now also supports outputting info in json format. Try "tc -s -json qdisc show dev eth0" for example.
  • dual-dsthost/dual-srchost was used instead of the default triple-isolate, as this should in theory provide better traffic management when multiple hosts are using the Internet at once
  • Various tc options were added to iproute2, like "ipset", "ematch" and "skbedit" support, allowing for more advanced tc filter rules to be defined.
  • Cake QoS has a qos_type of 9 (so not to create conflicts if in the future Asus were to implement a new QoS mode and used qos_type 4, the first available number). Make sure to check for it when creating a qos-start script.

Please limit discussions in this thread to this specific release. This thread will be locked after a certain period of time.


Downloads are here.
Changelog is here.
 
Last edited:

RMerlin

Asuswrt-Merlin dev
Reserved.
 

kernol

Very Senior Member
"Brilliant" - has brought the best features and stability to my AX86U's which are simply SUPERB routers from Asus when loaded with Magic Merlinware :D ...
Color splash when formatting USB Swap space ...
4-core-splendour2.JPG


Artiste :cool:
 

predatorz

Occasional Visitor
Successful Dirty upgrade from 386_1.2 to 386_2 on RT-AC88U.
Thanks for firmware.
 

Stoonhea020

New Around Here
Unfortunately the DDNS client seems to be broken. I got a DNS registration with asus.com and the status remain inactive. Syslog reported the following:

Apr 2 06:57:28 inadyn[7915]: In-a-dyn version 2.8.1 -- Dynamic DNS update client.
Apr 2 06:57:28 inadyn[7915]: Update forced for alias xxxxxxxxxxx.asuscomm.com, new IP# xxx.xxx.xxx.xxx
Apr 2 06:57:28 inadyn[7915]: alias address=<xxx.xxx.xxx.xxx>
Apr 2 06:57:44 inadyn[7915]: Fatal error in DDNS server response:
Apr 2 06:57:44 inadyn[7915]: [600 |Add TXT record for ACME challenge failed]
Apr 2 06:57:44 inadyn[7915]: Error response from DDNS server, exiting!
Apr 2 06:57:44 inadyn[7915]: Error code 48: DDNS server response not OK

This was not the case with Beta 3.
 

KentEkl

New Around Here
This is still valid with the 386.2 firmware.

Tor is resetting the configuration after every restart of the router.
I have configured Redirect all user from "Only Specified MACs" but the router drops that configuration and set it to Redirect all user from
to "LAN(br0)" and removes all entries from Specified MAC List every time the router RT-AC86U with 386.2_beta3 is restarted.
 

RMerlin

Asuswrt-Merlin dev
This is still valid with the 386.2 firmware.

Tor is resetting the configuration after every restart of the router.
I have configured Redirect all user from "Only Specified MACs" but the router drops that configuration and set it to Redirect all user from
to "LAN(br0)" and removes all entries from Specified MAC List every time the router RT-AC86U with 386.2_beta3 is restarted.
I re-tested it again, and just like during the beta, it still works for me. My entry was still there following a reboot.
 

Stoonhea020

New Around Here
There were ZERO code changes since beta 3. I changed the version number, updated changelog.txt and the README, and that was it...
Ok thanks, I will do some testing with downgrading/factory resets.

Edit; the solution was to change the DNS name, register the new name with Asus and then revert back to my original DNS name.
 
Last edited:

MvW

Senior Member
Yay, another wonderful release! Dirty upgrade from beta 3 to 386.2 final, with no issues at all. I've let both router and AiMesh Node settle for 10-15 minutes, did a power cycle and started everything back up. Everything works flawlessly, not in a single error in syslog.

Thanks for your continuous efforts, Eric and to the others involved in providing these great updates voluntarily time after time again. Thank you so much, your efforts are much appreciated.
 

KentEkl

New Around Here
I re-tested it again, and just like during the beta, it still works for me. My entry was still there following a reboot.
Strange, and it was the same for me with beta 2 but I'm sorry that I did not report it at that time. Is there anything I can try to do ?
I have formatted JFFS for every upgrade.
 

RMerlin

Asuswrt-Merlin dev
Strange, and it was the same for me with beta 2 but I'm sorry that I did not report it at that time. Is there anything I can try to do ?
I have formatted JFFS for every upgrade.
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.
 

RMerlin

Asuswrt-Merlin dev
does this fix this in the syslog?

not mesh client, can't update it's ip​

There's nothing to fix, it's just debugging info left in there by Asus, and over which I have no control.
 

Slawek P

Senior Member
I am glad I have found this Easter egg today. Yesterday I would have read it as another April Fools' trick :)
Dirty upgrade from 386.2 beta and 386.2. It is a gem - all smooth and working superbly. Many thanks & have a good break
 

pirx73

Senior Member
Dirty upgrade from 386.1_2 went smoothly, only thing missing after upgrade was a swap file which i had to recreate.
 

LimJK

Very Senior Member
Thank You @RMerlin
I have been running smoothly with Merlin 386.2 for about 4 hours

My Configuration:
  • AiMesh Router: AX88U 386.2 + 2 x AiMesh Nodes: AC86U 386.2
  • Backhaul (Priority:"Auto", Type:"Wired"), Asus GX-U1051 5-Port Gigabit Switch from Router to Nodes, ISP: 1 Gbps Fibre
Upgrading Firmware (dirty flash) from 386.2_beta3 to 386.2:
I first upgraded both my AiMesh Nodes, followed by AiMeshRouter and followed by AiMesh Reboot from GUI. I use Merlin default NVRAM settings except with the following changes:
  • Enabled AiProtection: ON
  • USB Application
    • UPnP Media Server: OFF
    • Samba Share: OFF
  • LAN:
    • 40 items in my DHCP manually Assigned IP List
  • Wireless:
    • 2.4 GHz: Fixed Channel Bandwidth 20MHz, Control Channel: Auto, Universal Beamforming: Disable
    • 5.0 GHz: Fixed Channel Bandwidth 80MHz, Control Channel: Auto
  • WAN DDNS:
    • Using Asus DDNS Service with Let’s Encrypt
  • VPN Servers (Connecting one at a time from the following clients) and checked that the Status Page displayed status correctly:
    • OpenVPN works with
      • MacBookPro macOS Catalina - Tunnelblick 3.8.5beta05 (Edit) 3.8.5beta06 (build 5650),
      • iPhoneXsMax iOS - OpenVPN Connect 3.2.3
    • IPSec works with MacBookPro & iPhoneXsMax Native Configurations
      • Cisco IPSec
      • IKEv2
    • Instant Guard works with iPhoneXsMax iOS Instant Guard 1.1.3 (TestFlight Version)
PS: I noticed that one on my RT-AC86U AiMesh Node's Wireless 2.4GHz degraded from 3 streams to 1 stream (as Wireless is closed source it is something for ASUS to fixed)
 
Last edited:

KentEkl

New Around Here
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.
Thank you for the answer.
If I'm the only user :) , I will change my configuration to use the VPN client instead of TOR since it's not a big issue for me.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top