hjohan13
Regular Contributor
The same is true for my AC66U
Same for my AC5300. Best build ever...
The same is true for my AC66U
The scenario is simple:If there are other specific scenario where they occur, I have never seen them.
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:
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.
Why should you? Unless at the critical limit there's no gain nor does it remedy anything...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...
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.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.
What do you mean by "what will it say for me"? If you don't change any JFFS setting, you should be fine.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?
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.
Possibly.....you need to remember a few thingsNVRAM 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.
Smaller size on 380.65 FW is normal.
APP="nolocaldm" (5MB less .ipk files)
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.
Agree. No such problems here either.I cannot reproduce it when sending an .mkv via the home network.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!