What's new

[Beta] Asuswrt-Merlin 384.19 beta is now available

Status
Not open for further replies.

RMerlin

Asuswrt-Merlin dev
Asuswrt-Merlin 384.19 beta is now available (except for the RT-AX56U which won't be available for this release, due to outdated GPL code).

Aug 9th: Beta 2 released. Changes since beta 1:

Code:
b2fb39a2ed (tag: 384.19-beta2-mainline, origin/mainline, mainline) Merge branch 'master' into mainline
2da320fae8 (HEAD -> master, tag: 384.19-beta2, origin/master, origin/HEAD) Updated documentation
d1bfe6ac98 Bumped revision to beta 2
8efbfeca8a getdns: listeners reply returned wireformat
136ff92387 Merge pull request #577 from Xentrk/master
1b6ab31f36 Merge pull request #576 from decoderman/master
83ce90d7b6 libovpn: fix policy client validation for CIDR-validated sources
19720598c6 Update vpnrouting.sh
37accd5251 Update vpnrouting.sh
14c2d36c1b Update vpnrouting.sh
a89e19699a Increased curl timeouts amtm FW
9a84171004 shared: rstats: removed a few unused nvram to regain some space
a803849beb webui: display appropriate warning message if jffs partition fails to mount instead of a low space warning
The main changes of this release are the merge of GPL updates, and a nearly complete rewrite of the OpenVPN implementation (functionality should remain mostly unchanged, aside from a few minor things documented in the changelog, and a few bug fixes.)

Note that due to Asus making changes to the RT-AC86U flash layout, this may cause the JFFS content to be corrupted or even lost following the upgrade. I recommend doing a JFFS backup before upgrading, so you can restore if after the upgrade.

Also note that the RT-AC86U now encrypts its passwords, so reverting to a previous release will require a factory default reset afterward.

Please review the changelog for the details.

Downloads are here.
Changelog is here.
 
Last edited:

RMerlin

Asuswrt-Merlin dev
Known issues:

  • Low JFFS space warning shown when partition fails to mount (fixed, will now display a different warning message)
  • VPN policy rules containing a CIDR as source are rejected as invalid (fixed)
 
Last edited:

RMerlin

Asuswrt-Merlin dev
Third party devs: note that there are a few things changed with the new OpenVPN implementation. Mainly, the updown-*.sh up/down event scripts have been replaced with binary calls from the new libovpn. If you were replacing these events in the past by overwriting updown-*.sh, you will now need to either use a postconf script to modify the event handler call, or rely on an openvpn-event script to do whatever you were doing in your own handler.

If you do replace the existing handler, be aware that you become responsible for anything the built-in handlers were previously doing.
 

Toink

Occasional Visitor
I just flashed my AX88U from Alpha4 to β. OpenVPN clients working as expected.
 

hervon

Regular Contributor
Maybe the issue is on my side. I'm running a openvpn server on this new beta.
I had to change proto tcp-client to proto tcp in order to connect with the openvnp client on IOS.
 

nzwayne

Regular Contributor
Dirty flash from 19-alpha1 to 19-beta on my three units...RT-AX88U with two backhauled RT86U's in AiMesh mode. All up and operational to 28 clients. Awesome!! Thks.

Edit: The morning after....
1). On inspection of features/functions. Unbound had stopped operation after the dirty upgrade at 10pm (see attached graph). USB drive unmount, then Powered off/on the RT-AX88U got that operational again (10am). AMTM had showing all scripts were installed and status shown of release level.
- In a quirk with this physical RT-AX88U, the 5GHz doesn't come up, after the power off/on with the USB drive installed. Have tried different USB drives, AX88U nuclear resets...no change in that. What I've learnt to do, unmount the USB drive, and physically remove it. Then power up AX88U, 5GHz is enabled, after like 10mins then install the USB drive.
2). Tabs NTP Daemon, Speedtest, Help & Support were still missing after the dirty upgrade, and also the power off/on (all my actions in #1). Did a reboot of the AX88U, and those tabs restored again.

1596480879092.png
 
Last edited:

Hawk

Senior Member
Does anyone who is using RT-AX88U notice behavior with 384.19 that router power off on its own. I specifically notice twice with alpha version.

Just want to see if there is something on my end only.
 

Treadler

Very Senior Member
Does anyone who is using RT-AX88U notice behavior with 384.19 that router power off on its own. I specifically notice twice with alpha version.

Just want to see if there is something on my end only.
Hasn‘t happened here.
 

RMerlin

Asuswrt-Merlin dev
Does anyone who is using RT-AX88U notice behavior with 384.19 that router power off on its own. I specifically notice twice with alpha version.

Just want to see if there is something on my end only.
I use an RT-AX88U as my main router. No problem here
 

RMerlin

Asuswrt-Merlin dev
Maybe the issue is on my side. I'm running a openvpn server on this new beta.
I had to change proto tcp-client to proto tcp in order to connect with the openvnp client on IOS.
Changed where? Client or server?
 

Luizlp10

Occasional Visitor
I've just updated to 384.19 Beta 1 and got lucky to read Merlin's advice to backup JFFS2 partition on the AC86U because updating the firmware made me lose a lot of configs, including vpn clients certs, DHCP reservation, Diversion(was able to recover previous config option after reinstalling it), etc. Past very little time but everything seems to be working just fine after updating firmware, restoring JFFS, reinstalling Diversion with previous config option(swap file got wiped after FW update) and a reboot from GUI.

JFFS2 Backup is a must if you use AC86U.
 

FLA_NL

Regular Contributor
Dirty flashed from 384.19_alpha4 to 384.19_beta1 and lost my internet connection. Dirty flashed back to 384.19_alpha4 and my internet connection was available again. Bit short on time now to look at the logs. Router model RT-AC86U.
 

Hawk

Senior Member
Eric, I get error message that my jffs partition is almost full, which is not the case since it was unmounted. However this message disappear once router mount jffs partition, usually after reboot.

00.PNG
01.PNG
 

immi803

Regular Contributor
@RMerlin
Tried updated AC68U from 18 to 19 beta and twice it returned with 18, checked md5 etc, everything looks fine but didn't update :(
Is it jffs and custom scripts can be the stoppage ?
Any ideas!
 

pirx73

Regular Contributor
Regarding this:
UPDATED: Merged GPL 384_81992 for mainline models.
Where i can check ASUS GPL to see what is changed/fixed/updated in 384_81992?
 

New2This

Regular Contributor
Does anyone who is using RT-AX88U notice behavior with 384.19 that router power off on its own. I specifically notice twice with alpha version.

Just want to see if there is something on my end only.
I have 2 of them running, never have noticed this happening
 

JemTheWire

Senior Member
@RMerlin
Tried updated AC68U from 18 to 19 beta and twice it returned with 18, checked md5 etc, everything looks fine but didn't update :(
Is it jffs and custom scripts can be the stoppage ?
Any ideas!
Are you sure you download the correct FW? And not the one for AC86U?
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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