[Release] Asuswrt-Merlin 380.65 is now available

[hjohan13]

The same is true for my AC66U

Same for my AC5300. Best build ever...

 

[Igor]

If there are other specific scenario where they occur, I have never seen them.

The scenario is simple:
Network Map -> MAC and IP address Binding -> Apply.

https://www.snbforums.com/threads/r...-65-is-now-available.37295/page-6#post-306579

 

[Andreas Beth]

Hi, I'm new here and sorry about my English.
I have buy an RT-Ac5300 and installed was the original .4180 from Asus. After a few little Problems i installed today the 380.65 over the 4180 on my AC5300 an now I see at the Administration Site a Warning that JFFS is enabled.
Ok, JFFS is an Filesystem but what will it say for me?

 

[Naftali Oziel]

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
• 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

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:

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.

Hi Merlin, I upgraded my AC68U that is in AP mode from 380.64_2 to 380.65. I noticed my NVRAM jump from 48468 to 49166, while am not in any danger zone, why the increase if my configuration did not change. Your thoughts? Do you think I should at some point reset to default and reconfigure from scratch?

 

[eddiez]

Hi Merlin, I upgraded my AC68U that is in AP mode from 380.64_2 to 380.65. I noticed my NVRAM jump from 48468 to 49166, while am not in any danger zone, why the increase if my configuration did not change. Your thoughts? Do you think I should at some point reset to default and reconfigure from scratch?

Why should you? Unless at the critical limit there's no gain nor does it remedy anything...

 

[Naftali Oziel]

Why should you? Unless at the critical limit there's no gain nor does it remedy anything...

Appreciate the feedback, question remains, why the increase, if no changes have made made to the configuration? Is this normal and by design. Simply trying to understand.

 

[Wutikorn]

Appreciate the feedback, question remains, why the increase, if no changes have made made to the configuration? Is this normal and by design. Simply trying to understand.

Not sure if that is where system log is located or not. If it is, then that may partially explain why there is an increase in size.

Hi, I'm new here and sorry about my English.
I have buy an RT-Ac5300 and installed was the original .4180 from Asus. After a few little Problems i installed today the 380.65 over the 4180 on my AC5300 an now I see at the Administration Site a Warning that JFFS is enabled.
Ok, JFFS is an Filesystem but what will it say for me?

What do you mean by "what will it say for me"? If you don't change any JFFS setting, you should be fine.

 

[Naftali Oziel]

Not sure if that is where system log is located or not. If it is, then that may partially explain why there is an increase in size.

What do you mean by "what will it say for me"? If you don't change any JFFS setting, you should be fine.

NVRAM is for configuration storage. This is why am simply wondering why it would increase regardless of it's incremental size when no changes were made. Is this going to continue as I further apply fimrware upgrades to the device?

 

[john9527]

NVRAM is for configuration storage. This is why am simply wondering why it would increase regardless of it's incremental size when no changes were made. Is this going to continue as I further apply fimrware upgrades to the device?

Possibly.....you need to remember a few things
- It's not only your user configuration info that is kept in nvram, but some system level parameters as well. Whenever Merlin does a merge with ASUS, things can change or get added.
- As features are added (or prework for future features), new nvram settings can be added even if you don't see them yet or are using them. For example, in the move you made, support for OpenVPN 2.4.0 added some new settings that are initialized.
- Status information is also constantly updated in nvram (actually in a shadow kept in ram...that's why there is an 'nvram commit' command if you make a manual change to actually write the change to flash). So the usage can change just during normal running.

 

[Dimitris19]

Just replaced my RT-N66U with RT-AC88U and install 380.65 firmware on it.
Everything is working great so far but sometimes i have to disable IPv6 because it slows down web surfing.

With the same firmware, IPv6 on RT-N66U works flawlessly.

Also i got this message on System Log : kernel warning 'vsftpd' uses 32-bit capabilities (legacy support in use)
What it means?

Thanks in advance

 

[Naftali Oziel]

Possibly.....you need to remember a few things
- It's not only your user configuration info that is kept in nvram, but some system level parameters as well. Whenever Merlin does a merge with ASUS, things can change or get added.
- As features are added (or prework for future features), new nvram settings can be added even if you don't see them yet or are using them. For example, in the move you made, support for OpenVPN 2.4.0 added some new settings that are initialized.
- Status information is also constantly updated in nvram (actually in a shadow kept in ram...that's why there is an 'nvram commit' command if you make a manual change to actually write the change to flash). So the usage can change just during normal running.

Thank you that makes sense. I forgot about the fact new features taking up some space regardless am in AP mode. Appreciate the info.

 

[BrianWhite]

Can someone confirm me the TRX file's CRC for me ?

I just tried to go to the new 380_65, from a few versions ago (380_62 think), and it got stuck in a boot loop, couldnt factory the router or connect to it.

I got it in to Recovery and planted the default latest ASUS firmware, which is like 38MB in size, but the Merlin 380_65 is only 33MB in size.

CRC32 - 0298B938 Can anyone confirm this CRC for 380_65 ? (Faulty download perhaps ?)

 

[hggomes]

Smaller size on 380.65 FW is normal.

APP="nolocaldm" (5MB less .ipk files)

 

[BrianWhite]

Smaller size on 380.65 FW is normal.

APP="nolocaldm" (5MB less .ipk files)

Okies, thanks for that. Anyway, From the 380_4164 (Asus) I have now flashed Merlin's 380_65 and its working again.

[edit] I found the cause.

ENTWARE and AB-Solution were installed on an EXT3 stick, which was still plugged in, and the update rebooted the router, the router cracked the shirts (Wish I knew that before going back to the ASUS firmware).

Dunno why, but that was the cause, because I put the USB stick in again, and the new firmware crashed (again). Took it out, and it was happy and rebooted.

 

[PetrKKK]

DLNA is broken after upload through Samba on RT-AC66U (380.65)
Whenever when I upload a new file into MediaServer folder, DLNA get stucked. After upload it is not possible to connect to MediaServer/DLNA. No issue in SysLog.
When this issue occur I need to shout down MediaServer and start it up again. After the MediaServer reboot everything is OK again .... till the next upload
This issue is related to 380.65_0, this issue is NOT in 380.64_2.

Thanks.

 

[Bartman]

DLNA is broken after upload through Samba on RT-AC66U (380.65)
Whenever when I upload a new file into MediaServer folder, DLNA get stucked. After upload it is not possible to connect to MediaServer/DLNA. No issue in SysLog.
When this issue occur I need to shout down MediaServer and start it up again. After the MediaServer reboot everything is OK again .... till the next upload
This issue is related to 380.65_0, this issue is NOT in 380.64_2.

Thanks.

How are you uploading the file as I cannot reproduce it when sending an .mkv via the home network.

Regards

 

[Diamond67]

I cannot reproduce it when sending an .mkv via the home network.

Agree. No such problems here either.

 

[gimla]

Today i tried upgrade from 380.64_2 to 380.65. Unfortunately my router wasn't able correctly start(I saw only simple page where were buttons for upload firmware, reset NVRAM to default and reboot ) and I had to use factory reset.
I have: RT-AC87U

Now I'm back on version 380.64_2

 

[fiasko]

AC66U (AP), AC87U (AP) and AC88U (main router) all updated succesfully today.

 

[seanr22a]

Have been running 380.65 for a week now on all units listed in my sig. No issues at all.