What's new

[Release] Asuswrt-Merlin 380.65 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

RMerlin

Asuswrt-Merlin dev
Asuswrt-Merlin 380.65 is now available for all supported models.

This release introduces a number of important changes, which is why it went through a longer development cycle than usual (in addition to the issues involved with testing the GPL 4180 code, which had to be reverted).

  • Upgraded to OpenVPN 2.4.0, and implemented support for various new features introduced with this major release. Asuswrt-Merlin fully supports the new GCM ciphers, negotiated ciphers, tls-crypt and more. This probably makes Asuswrt-Merlin one of the first to implement support for it :cool:
  • Numerous issues related to OpenVPN were resolved.
  • Updated Busybox to 1.25.1. This component provides a lot of the tools used by the router's shell environment.
  • Other component updates include openssl, tor and nano which were updated to their latest versions.
  • Some portions of Asus's 380_4180 GPL were merged. The rest wasn't, due to numerous issues introduced in this GPL release.
  • Fix to IPv6 for newer router models, which were using an invalid MAC when requesting for a prefix.
  • Various fixes to the Network Services Firewall
  • Fixed rendering under Chrome 56
  • Many other fixes and changes, please read the changelog for the complete list

Update - March 30th:
380.65_4 was uploaded, fixing two bugs.

Code:
   - FIXED: Various LAN/WAN issues with the RT-AC3200 due to
            incorrect GMAC state checks (Asus bug) (patch
            by john9527)
   - FIXED: Some models would sometime randomly fail to start one
            of their wifi radio, possibly due to a hardware design
            issue.  Partly revert the 380.65 changes that removed
            the automatic reboot if one radio was disabled at boot
            time, but reduced the maximum number of reboots to 1.


Update - March 10th:
380.65_2 was uploaded, fixing two CVE security issues and two minor webui bugs.

Code:
   - FIXED: CVE-2017-6549 (implemented temporary workaround,
            until a proper fix from Asus)
   - FIXED: CVE-2017-6548 (backport from GPL 7266)
   - FIXED: WOL page fails to load if adding a client with a
            quote in its name.
   - FIXED: Couldn't add a DHCP reservation client if its name
            contained a quote


More info on OpenVPN 2.4.0:

OpenVPN 2.4.0 is a major update over 2.3.x. The new GCM ciphers should in theory be a bit more efficient, by reducing the overhead of individual packets.

The new negotiation protocol (NCP) allow you to specify a list of supported ciphers, and both ends will communicate together to select the best matching cipher. If one of the two ends is still using an older version of OpenVPN, then the 2.4.0 end will fallback to using the former "cipher" parameter. This automatic fallback behaviour can be enabled/disabled through the webui.

Note that having a mixture of 2.3 and 2.4 endpoints, or using the legacy fallback might cause some warnings about inconsistent settings to show in your log, as your server will try to establish whether to use NCP or the old cipher operand. These warnings can safely be ignored.

2.4.0 also adds support for LZ4 compression, which should be more efficient than LZ0. This requires that both ends run 2.4.x.

tls-crypt is a new security layer that will allow OpenVPN to encrypt the content of the TLS control channel, helping in further obfuscating the protocol (potentially allowing it to go through firewalls blocking OpenVPN usage). The encryption is done using a static key, just like static authentication. Use the Static Key field to paste the key, which must be generated by OpenVPN itself (not by OpenSSL/easy-rsa.) Please consult the OpenVPN manual for more information on how to generate your own key.

If you enable server settings that are incompatible with a 2.4.0 client, you will be warned. In general you shouldn't need to re-export a new config file for your older clients provided you do not change your existing configuration.

A few parameters have been deprecated/removed in 2.4.0, so you might need to adjust any existing "custom" settings. Please refer to the OpenVPN manual.

One potential new issue seem to be specific to MIPS models (RT-N66U/RT-AC66U) and their older kernel. Starting with 2.4.0, OpenVPN expects the tun interface to support IPv6. That doesn't seem the case on this older kernel, so VPN servers that push back an ifconfig-ipv6 or route-ipv6 parameters might fail to connect. I haven't been able to test it myself (as I don't have a tunnel provider account), but I'd suggest trying to add these to your custom configuration if your client fail to connect with thhe system log reporting a failure on an "ip -6" command:

Code:
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

This is another sign that it might be time to retire these older models...


As usual, please try to keep posts in this thread specifically to this version. I strongly suggest starting a new thread if you have a configuration question.

Downloads are here.
Changelog is here.
 
Last edited:
Q merlin m8, those that are on Beta4 would jumping to final 380.65 be needed ? or should we skip this release build :) - RT_AC88U
 
Is it by design that your new check for update feature seems to be "either" / "or". If I have check for beta checked, it won't tell me about stable releases. Only when I unchecked check for beta, does it tell me a release is available. (this is with me click check for update manually each time)

Shouldn't checking the beta box inform a user of stable AND beta?
 
Last edited:
Upgraded, but VPN stopped working. I have checked keys etc and everything is fine but I got on VPN configuration such info:
"Certification Authentication / Server certification / Server Key field error!

Please check the Keys and Certification contents on the Advanced Settings page."

I have once again pasted my certificates, but it does not work. In logs I have information:
Feb 3 14:42:48 openvpn[2850]: XXXX OpenSSL: error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length
Feb 3 14:42:48 openvpn[2850]: XXXX EVP set key size
Feb 3 14:42:48 openvpn[2850]: XXXX Exiting due to fatal error
Feb 3 14:42:48 openvpn[2850]: XXXX Closing TUN/TAP interface


Before upgrade it worked fine. I cannot connect using any of my devices.

UDATE: after changing "Cipher Negotiation" to Disabled, everything works fine. Enable with fallback didnt worked, and OpenVPN server didnt started at all. What is specific to my configuration I was using tls-auth
https://openvpn.net/index.php/open-source/documentation/howto.html
 
Last edited:
nice info for new firmware...
Code:
Feb  3 09:55:41 crond[495]: time disparity of 795415 minutes detected
Feb  3 09:56:33 watchdog: New firmware version 380.65_0 is available.
Feb  3 10:00:30 disk_monitor: Got SIGALRM...
 
Is it by design that your new check for update feature seems to be "either" / "or". If I have check for beta checked, it won't tell me about stable releases. Only when I unchecked check for beta, does it tell me a release is available.

Shouldn't checking the beta box inform a user of stable AND beta?
He mentioned somewhere that the beta button will only check for beta firmware not stable. But I'm not sure why it works that way.
I didn't have beta checked and I wasn't informed about the stable release either.
--
bc
Should it be that quick? The router checks for new firmware every 48hours, so that might be the reason.
 
He mentioned somewhere that the beta button will only check for beta firmware not stable. But I'm not sure why it works that way.

Should it be that quick? The router checks for new firmware every 48hours, so that might be the reason.
I set up two routers for update notification e-mail, and I received notification e-mail for 1 of 2. It is all dependent on when the 48 hour check triggers.
 
FIXED: Webui layout was broken under Chrome 56. <- this isn't fixed, there is a bar at the top is shifted to the right, since last version..
 
FIXED: Webui layout was broken under Chrome 56. <- this isn't fixed, there is a bar at the top is shifted to the right, since last version..

Works for me, on all three computers where Chrome was updated to the latest version.
 
Is it by design that your new check for update feature seems to be "either" / "or". If I have check for beta checked, it won't tell me about stable releases. Only when I unchecked check for beta, does it tell me a release is available. (this is with me click check for update manually each time)

Shouldn't checking the beta box inform a user of stable AND beta?

The automated check will always check for stable. The manual check will always check for what you selected on that page.

Changing this behaviour would be complex, so I kept what Asus implemented.
 
Q merlin m8, those that are on Beta4 would jumping to final 380.65 be needed ? or should we skip this release build :) - RT_AC88U

Upgrade.
 
RT-AC5300 the signature update doesn't work.
Thanks,
 

Attachments

  • Capture-1.PNG
    Capture-1.PNG
    247.4 KB · Views: 1,389
RT-AC5300 the signature update doesn't work.
Thanks,

Seems to be on Asus's end, I get a 404 when trying to access the 1146 signature file on their server, while 1142 is there.
 
How do I test the email notification as I set it up with the same details I use on my UPS network card, I didn't get an email even though the firmware notification was flashing.
I can't see any logs related to it either.
 
Signature update failing on 88, also.
Other "vanilla" settings working well, except my temp is always set to "C"anadian & won't set to "F"oreigner ;)
 
i havnt done a build in about a week (just before the revert)
i removed the whole dir and did a fresh pull
and its failing dont think its anything my end

Code:
ndr_notify.c:(.text.ndr_pull_notify_entry+0x38): undefined reference to `ndr_pull_server_id'
collect2: ld returned 1 exit status
make[5]: *** [bin/samba_multicall] Error 1
make[5]: Leaving directory `/home/shonk/asuswrt-merlin/release/src/router/samba36/source3'
make[4]: *** [apps] Error 2
make[4]: Leaving directory `/home/shonk/asuswrt-merlin/release/src/router/samba36'
make[3]: *** [samba36] Error 2
make[3]: Leaving directory `/home/shonk/asuswrt-merlin/release/src/router'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/shonk/asuswrt-merlin/release/src-rt-7.14.114.x/src'
make[1]: *** [bin] Error 2
make[1]: Leaving directory `/home/shonk/asuswrt-merlin/release/src-rt-7.14.114.x/src'
make: *** [rt-ac88u] Error 2

edit here's the last time i did a build
Mon Jan 16 01:26:16 UTC 2017 shonk@125414c
 
Seems to be on Asus's end, I get a 404 when trying to access the 1146 signature file on their server, while 1142 is there.
Confirmed with my DSL-AC68U running stock firmware 3.0.0.4.380_4162, same problem here.
 
RT-AC5300 the signature update doesn't work.
Thanks,
Seems to be on Asus's end, I get a 404 when trying to access the 1146 signature file on their server, while 1142 is there.

Same here, on 1142, but server problems Asus end :(

Apart from that, all OK on my 5300 :)

Thank you
 

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